19.03.2020 11:18, Geert Uytterhoeven пишет: > Hi Dmitry, > > On Thu, Mar 19, 2020 at 2:11 AM Dmitry Osipenko <digetx@xxxxxxxxx> wrote: >> 25.02.2020 14:40, Geert Uytterhoeven пишет: >>> 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. >> >> 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'm sorry to hear that. > > Did v2 work for you? Same as it was for Marek. > Are you sure this updated version is the culprit? There are several other > recent changes to head.S in arm/for-next. Yes > Do you boot a separate DTB or an appended DTB? Appended > Do you use ATAGS? Yes >> 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. > > V3 is v2 combined with "[PATCH] ARM: boot: Fix ATAGs with appended DTB" > (https://lore.kernel.org/linux-renesas-soc/20200225144749.19815-1-geert+renesas@xxxxxxxxx/). Thank you for the clarification. I recalled that CONFIG_THUMB2_KERNEL=y is set in my kernel's config and disabling thumb2 build fixes the problem. Please correct it in the next version of the patch, thanks in advance.
