All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Osipenko <digetx@gmail.com>
To: Florian Fainelli <f.fainelli@gmail.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Ard Biesheuvel <ardb@kernel.org>
Cc: linux-tegra@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] ARM: tegra: Fix misplaced tegra_uart_config in decompressor
Date: Tue, 15 Dec 2020 21:56:51 +0300	[thread overview]
Message-ID: <604dd2ea-d813-fa3f-3e2f-4d66175162b3@gmail.com> (raw)
In-Reply-To: <b8de29b7-b0f6-5b2b-6ab2-f4399bc241fc@gmail.com>

15.12.2020 21:22, Florian Fainelli пишет:
> 
> 
> On 12/15/2020 8:53 AM, Dmitry Osipenko wrote:
>> 15.12.2020 19:40, Florian Fainelli пишет:
>>>
>>>
>>> On 12/15/2020 8:17 AM, Dmitry Osipenko wrote:
>>>> 15.12.2020 19:04, Florian Fainelli пишет:
>>>>>
>>>>>
>>>>> On 12/15/2020 5:52 AM, Dmitry Osipenko wrote:
>>>>>> The tegra_uart_config of the DEBUG_LL code is now placed right at the
>>>>>> start of the .text section after commit which enabled debug output in the
>>>>>> decompressor. Tegra devices are not booting anymore if DEBUG_LL is enabled
>>>>>> since tegra_uart_config data is executes as a code. Fix the misplaced
>>>>>> tegra_uart_config storage by embedding it into the code.
>>>>>>
>>>>>> Cc: stable@vger.kernel.org
>>>>>> Fixes: 2596a72d3384 ("ARM: 9009/1: uncompress: Enable debug in head.S")
>>>>>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
>>>>>> ---
>>>>>>  arch/arm/include/debug/tegra.S | 54 +++++++++++++++++-----------------
>>>>>>  1 file changed, 27 insertions(+), 27 deletions(-)
>>>>>
>>>>> Looks like arch/arm/include/debug/brcmstb.S would need the same
>>>>> treatment since the implementation was copied from tegra.S.
>>>>>
>>>>
>>>> Good catch, will you be able to test the brcm and make a patch?
>>>
>>> Yes, absolutely, building a kernel to test right now.
>>>
>>
>> Thank you.
>>
>> BTW, I noticed that the problem is more visible on a thumb2 kernel
>> build, i.e. you should get a more reliable hang on boot. On a non-thumb2
>> kernel the hanging behaviour seems depends on a device / bootloader. I
>> haven't tried to figure out what exactly makes the difference, perhaps
>> it should be a memory layout / state.
> 
> To build with a CONFIG_THUMB2_KERNEL I had to fetch:
> 
> https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9018/2
> 
> to avoid a build error, too bad this missed v5.10 final but hopefully it
> can make it soon.

The VFP fix was applied to the -next very recently, it should propagate
to v5.10 eventually.

> With CONFIG_THUMB2_KERNEL=y, I am not getting the head.S output where it
> prints the start/end of the compressed kernel:
> 
> C:0x420800C0-0x4321B0E0->0x4212AB00-0x432C5B20
> Uncompressing Linux... done, booting the kernel.
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 5.10.0-g148842c98a24
> (fainelli@fainelli-desktop) (arm-linux-gcc (GCC) 8.3.0, GNU ld (GNU
> Binutils) 2.32) #71 SMP Tue Dec 15 09:53:09 PST 2020
> 
> I am only getting:
> 
> Uncompressing Linux... done, booting the kernel.
> 
> Is that the same for you?

No, start/end are printed for both THUMB2 and ARM kernels here.

> Looking at the disassembly of head.o it definitively has
> brcmstb_uart_config in the .text section as the beginning just like you
> mentioned in your commit message.
> 
> Disassembly of section .text:
> 
> 00000000 <brcmstb_uart_config>:
>    0:   00000001        andeq   r0, r0, r1
>         ...
>    c:   467c            mov     r4, pc
>    e:   f004 4478       and.w   r4, r4, #4160749568     ; 0xf8000000
>   12:   f504 4400       add.w   r4, r4, #32768  ; 0x8000
>   16:   4678            mov     r0, pc
>   18:   42a0            cmp     r0, r4
>   1a:   bf3f            itttt   cc
>   1c:   48d4            ldrcc   r0, [pc, #848]  ; (370 <LC1+0x8>)
>   1e:   4478            addcc   r0, pc
>   20:   4284            cmpcc   r4, r0
>   22:   f044 0401       orrcc.w r4, r4, #1
>   26:   bf28            it      cs
>   28:   f000 f9aa       blcs    380 <cache_on>
> 
> however after applying a fix similar to yours, we do end-up with the
> expected data embedded within the code and given brcmstb.S would be
> subject to the same issue as tegra.S, it would not hurt.
> 

Have you checked whether start/end printed after applying the fix?

WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Osipenko <digetx@gmail.com>
To: Florian Fainelli <f.fainelli@gmail.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Ard Biesheuvel <ardb@kernel.org>
Cc: linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v1] ARM: tegra: Fix misplaced tegra_uart_config in decompressor
Date: Tue, 15 Dec 2020 21:56:51 +0300	[thread overview]
Message-ID: <604dd2ea-d813-fa3f-3e2f-4d66175162b3@gmail.com> (raw)
In-Reply-To: <b8de29b7-b0f6-5b2b-6ab2-f4399bc241fc@gmail.com>

15.12.2020 21:22, Florian Fainelli пишет:
> 
> 
> On 12/15/2020 8:53 AM, Dmitry Osipenko wrote:
>> 15.12.2020 19:40, Florian Fainelli пишет:
>>>
>>>
>>> On 12/15/2020 8:17 AM, Dmitry Osipenko wrote:
>>>> 15.12.2020 19:04, Florian Fainelli пишет:
>>>>>
>>>>>
>>>>> On 12/15/2020 5:52 AM, Dmitry Osipenko wrote:
>>>>>> The tegra_uart_config of the DEBUG_LL code is now placed right at the
>>>>>> start of the .text section after commit which enabled debug output in the
>>>>>> decompressor. Tegra devices are not booting anymore if DEBUG_LL is enabled
>>>>>> since tegra_uart_config data is executes as a code. Fix the misplaced
>>>>>> tegra_uart_config storage by embedding it into the code.
>>>>>>
>>>>>> Cc: stable@vger.kernel.org
>>>>>> Fixes: 2596a72d3384 ("ARM: 9009/1: uncompress: Enable debug in head.S")
>>>>>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
>>>>>> ---
>>>>>>  arch/arm/include/debug/tegra.S | 54 +++++++++++++++++-----------------
>>>>>>  1 file changed, 27 insertions(+), 27 deletions(-)
>>>>>
>>>>> Looks like arch/arm/include/debug/brcmstb.S would need the same
>>>>> treatment since the implementation was copied from tegra.S.
>>>>>
>>>>
>>>> Good catch, will you be able to test the brcm and make a patch?
>>>
>>> Yes, absolutely, building a kernel to test right now.
>>>
>>
>> Thank you.
>>
>> BTW, I noticed that the problem is more visible on a thumb2 kernel
>> build, i.e. you should get a more reliable hang on boot. On a non-thumb2
>> kernel the hanging behaviour seems depends on a device / bootloader. I
>> haven't tried to figure out what exactly makes the difference, perhaps
>> it should be a memory layout / state.
> 
> To build with a CONFIG_THUMB2_KERNEL I had to fetch:
> 
> https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9018/2
> 
> to avoid a build error, too bad this missed v5.10 final but hopefully it
> can make it soon.

The VFP fix was applied to the -next very recently, it should propagate
to v5.10 eventually.

> With CONFIG_THUMB2_KERNEL=y, I am not getting the head.S output where it
> prints the start/end of the compressed kernel:
> 
> C:0x420800C0-0x4321B0E0->0x4212AB00-0x432C5B20
> Uncompressing Linux... done, booting the kernel.
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 5.10.0-g148842c98a24
> (fainelli@fainelli-desktop) (arm-linux-gcc (GCC) 8.3.0, GNU ld (GNU
> Binutils) 2.32) #71 SMP Tue Dec 15 09:53:09 PST 2020
> 
> I am only getting:
> 
> Uncompressing Linux... done, booting the kernel.
> 
> Is that the same for you?

No, start/end are printed for both THUMB2 and ARM kernels here.

> Looking at the disassembly of head.o it definitively has
> brcmstb_uart_config in the .text section as the beginning just like you
> mentioned in your commit message.
> 
> Disassembly of section .text:
> 
> 00000000 <brcmstb_uart_config>:
>    0:   00000001        andeq   r0, r0, r1
>         ...
>    c:   467c            mov     r4, pc
>    e:   f004 4478       and.w   r4, r4, #4160749568     ; 0xf8000000
>   12:   f504 4400       add.w   r4, r4, #32768  ; 0x8000
>   16:   4678            mov     r0, pc
>   18:   42a0            cmp     r0, r4
>   1a:   bf3f            itttt   cc
>   1c:   48d4            ldrcc   r0, [pc, #848]  ; (370 <LC1+0x8>)
>   1e:   4478            addcc   r0, pc
>   20:   4284            cmpcc   r4, r0
>   22:   f044 0401       orrcc.w r4, r4, #1
>   26:   bf28            it      cs
>   28:   f000 f9aa       blcs    380 <cache_on>
> 
> however after applying a fix similar to yours, we do end-up with the
> expected data embedded within the code and given brcmstb.S would be
> subject to the same issue as tegra.S, it would not hurt.
> 

Have you checked whether start/end printed after applying the fix?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-12-15 18:57 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-15 13:52 [PATCH v1] ARM: tegra: Fix misplaced tegra_uart_config in decompressor Dmitry Osipenko
2020-12-15 13:52 ` Dmitry Osipenko
2020-12-15 14:28 ` Linus Walleij
2020-12-15 14:28   ` Linus Walleij
2020-12-15 15:20   ` Dmitry Osipenko
2020-12-15 15:20     ` Dmitry Osipenko
2020-12-15 16:04 ` Florian Fainelli
2020-12-15 16:04   ` Florian Fainelli
2020-12-15 16:17   ` Dmitry Osipenko
2020-12-15 16:17     ` Dmitry Osipenko
2020-12-15 16:40     ` Florian Fainelli
2020-12-15 16:40       ` Florian Fainelli
2020-12-15 16:53       ` Dmitry Osipenko
2020-12-15 16:53         ` Dmitry Osipenko
2020-12-15 18:22         ` Florian Fainelli
2020-12-15 18:22           ` Florian Fainelli
2020-12-15 18:56           ` Dmitry Osipenko [this message]
2020-12-15 18:56             ` Dmitry Osipenko
2020-12-15 19:20             ` Florian Fainelli
2020-12-15 19:20               ` Florian Fainelli
2020-12-15 19:47               ` Dmitry Osipenko
2020-12-15 19:47                 ` Dmitry Osipenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=604dd2ea-d813-fa3f-3e2f-4d66175162b3@gmail.com \
    --to=digetx@gmail.com \
    --cc=ardb@kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=jonathanh@nvidia.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=thierry.reding@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.