19.03.2020 12:25, Russell King - ARM Linux admin пишет: > On Thu, Mar 19, 2020 at 04:11:00AM +0300, Dmitry Osipenko wrote: >> 25.02.2020 14:40, Geert Uytterhoeven пишет: >>> Hi Marek, >>> >>> On Tue, Feb 25, 2020 at 12:24 PM Marek Szyprowski >>> <m.szyprowski@xxxxxxxxxxx> wrote: >>>> On 27.01.2020 15:07, Geert Uytterhoeven wrote: >>>>> Currently, the start address of physical memory is obtained by masking >>>>> the program counter with a fixed mask of 0xf8000000. This mask value >>>>> was chosen as a balance between the requirements of different platforms. >>>>> However, this does require that the start address of physical memory is >>>>> a multiple of 128 MiB, precluding booting Linux on platforms where this >>>>> requirement is not fulfilled. >>>>> >>>>> Fix this limitation by obtaining the start address from the DTB instead, >>>>> if available (either explicitly passed, or appended to the kernel). >>>>> Fall back to the traditional method when needed. >>>>> >>>>> This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM >>>>> on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space), >>>>> i.e. not at a multiple of 128 MiB. >>>>> >>>>> Suggested-by: Nicolas Pitre <nico@xxxxxxxxxxx> >>>>> Signed-off-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx> >>>>> Reviewed-by: Nicolas Pitre <nico@xxxxxxxxxxx> >>>>> --- >>>>> Against arm/for-next. >>>> >>>> This patch landed recently in linux-next. It breaks legacy booting from >>>> the zImage + appended DT + cmdline/memory info provided via ATAGs. I >>>> will debug it further once I find some spare time. What I noticed so >>>> far, the cmdline/memory info is not read from the ATAGs, only the values >>>> provided via appended DT are used. >>> >>> Oops, something happening like this was one of my biggest worries when >>> posting this patch... Sorry for the breakage. >>> >>> IIUIC, the kernel still boots, but just doesn't use the info passed by ATAGs? >>> >>> I'll have a closer look later today. >>> In the mean time, I've sent some debug code I used when developing >>> this patch, which may be useful, hopefully. >> >> Hello, >> >> NVIDIA Tegra is also affected by this patch. A week ago an updated >> version of the patch was pushed into linux-next and now machine doesn't >> boot at all. >> >> I couldn't find v3 on the ML, so replying to the v2. Please take a look >> and fix the problem, or revert/drop the offending patch, thanks in advance. > > I'll drop the patch. It's clear that this is going to be difficult, > so I would ask you to test the next version, rather than waiting for > it to appear in linux-next. Thank you very much! I'll be happy to try v4, please feel free to CC me.
