Re: [PATCH v2] ARM: boot: Obtain start of physical memory from DTB

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [ARM Kernel]     [Linux ARM]     [Linux ARM MSM]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux