Backporting commits for generating rpi dtb symbols to stable

Backporting commits for generating rpi dtb symbols to stable

[Pali Rohár]

Hello,

I see that raspberry pi bootloader throws ton of warnings when supplied
DTB file does not contain /__symbols__/ node.

On RPI 1B rev1 it looks like this:

dterror: no symbols found
dterror: no symbols found
dterror: no symbols found
dterror: no symbols found
dterror: no symbols found
dterror: no symbols found
dterror: no symbols found
dterror: no symbols found
dterror: no symbols found
dterror: no symbols found

Bootloader also propagates these warnings to kernel via dtb property
chosen/user-warnings and they can be read by simple command:

$ cat /sys/firmware/devicetree/base/chosen/user-warnings
...

Upstream Linux kernel build process by default does not generate
/__symbols__/ node for DTB files, but DTB files provided by raspberrypi
foundation have them for a longer time.

I wanted to look at this issue, but I figured out that it is already
solved by just recent Aurelien's patches:

e925743edc0d ("arm: dts: bcm: Enable device-tree overlay support for RPi devices")
3cdba279c5e9 ("arm64: dts: broadcom: Enable device-tree overlay support for RPi devices")

My testing showed that /__symbols__/ node is required by rpi bootloader
for overlay support even when overlayed DTB file does not use any DTB
symbol (and reference everything via full node path). So seems that
/__symbols__/ node is crucial for rpi bootloader even when symbols from
them are not used at all.

So I would like to ask, would you consider backporting these two
raspberry pi specific patches to stable kernel trees? Upstream kernel
would get rid of those bootloader warnings and also allow users to use
overlayed dtbs...

(Btw, do you know if raspberry pi foundation or broadcom provides source
code of that bootloader? It would be interesting to understand it or
maybe also fix it...)

Re: Backporting commits for generating rpi dtb symbols to stable

[Greg KH]

On Sun, Jul 16, 2023 at 06:24:44PM +0200, Pali Rohár wrote:
> Hello,
> 
> I see that raspberry pi bootloader throws ton of warnings when supplied
> DTB file does not contain /__symbols__/ node.
> 
> On RPI 1B rev1 it looks like this:
> 
> dterror: no symbols found
> dterror: no symbols found
> dterror: no symbols found
> dterror: no symbols found
> dterror: no symbols found
> dterror: no symbols found
> dterror: no symbols found
> dterror: no symbols found
> dterror: no symbols found
> dterror: no symbols found
> 
> Bootloader also propagates these warnings to kernel via dtb property
> chosen/user-warnings and they can be read by simple command:
> 
> $ cat /sys/firmware/devicetree/base/chosen/user-warnings
> ...
> 
> Upstream Linux kernel build process by default does not generate
> /__symbols__/ node for DTB files, but DTB files provided by raspberrypi
> foundation have them for a longer time.
> 
> I wanted to look at this issue, but I figured out that it is already
> solved by just recent Aurelien's patches:
> 
> e925743edc0d ("arm: dts: bcm: Enable device-tree overlay support for RPi devices")
> 3cdba279c5e9 ("arm64: dts: broadcom: Enable device-tree overlay support for RPi devices")
> 
> My testing showed that /__symbols__/ node is required by rpi bootloader
> for overlay support even when overlayed DTB file does not use any DTB
> symbol (and reference everything via full node path). So seems that
> /__symbols__/ node is crucial for rpi bootloader even when symbols from
> them are not used at all.
> 
> So I would like to ask, would you consider backporting these two
> raspberry pi specific patches to stable kernel trees? Upstream kernel
> would get rid of those bootloader warnings and also allow users to use
> overlayed dtbs...

What kernel tree(s) should these be applied to?  What trees did you test
them for?

Also, adding dt-overlay support does not seem like a stable kernel fix,
as this isn't a bugfix from what I can tell, right?

thanks,

greg k-h

Re: Backporting commits for generating rpi dtb symbols to stable

[Pali Rohár]

On Sunday 16 July 2023 18:32:42 Greg KH wrote:
> On Sun, Jul 16, 2023 at 06:24:44PM +0200, Pali Rohár wrote:
> > Hello,
> > 
> > I see that raspberry pi bootloader throws ton of warnings when supplied
> > DTB file does not contain /__symbols__/ node.
> > 
> > On RPI 1B rev1 it looks like this:
> > 
> > dterror: no symbols found
> > dterror: no symbols found
> > dterror: no symbols found
> > dterror: no symbols found
> > dterror: no symbols found
> > dterror: no symbols found
> > dterror: no symbols found
> > dterror: no symbols found
> > dterror: no symbols found
> > dterror: no symbols found
> > 
> > Bootloader also propagates these warnings to kernel via dtb property
> > chosen/user-warnings and they can be read by simple command:
> > 
> > $ cat /sys/firmware/devicetree/base/chosen/user-warnings
> > ...
> > 
> > Upstream Linux kernel build process by default does not generate
> > /__symbols__/ node for DTB files, but DTB files provided by raspberrypi
> > foundation have them for a longer time.
> > 
> > I wanted to look at this issue, but I figured out that it is already
> > solved by just recent Aurelien's patches:
> > 
> > e925743edc0d ("arm: dts: bcm: Enable device-tree overlay support for RPi devices")
> > 3cdba279c5e9 ("arm64: dts: broadcom: Enable device-tree overlay support for RPi devices")
> > 
> > My testing showed that /__symbols__/ node is required by rpi bootloader
> > for overlay support even when overlayed DTB file does not use any DTB
> > symbol (and reference everything via full node path). So seems that
> > /__symbols__/ node is crucial for rpi bootloader even when symbols from
> > them are not used at all.
> > 
> > So I would like to ask, would you consider backporting these two
> > raspberry pi specific patches to stable kernel trees? Upstream kernel
> > would get rid of those bootloader warnings and also allow users to use
> > overlayed dtbs...
> 
> What kernel tree(s) should these be applied to?  What trees did you test
> them for?
> 
> Also, adding dt-overlay support does not seem like a stable kernel fix,
> as this isn't a bugfix from what I can tell, right?
> 
> thanks,
> 
> greg k-h

I wanted to discuss what do you think about it. As I wrote my motivation
was to understood and get rid of those warnings "dterror: no symbols
found" from bootloader when using DTB files from mainline kernel (as
opposite of the DTB files from rpi foundation). And fix for it was just
to generate DTB files from kernel via dtc's -@ parameter, same what are
doing those mentioned patches (but they describe different problem for
which is same fix). I thought that fixing those bootloader warnings is a
bugfix.

Re: Backporting commits for generating rpi dtb symbols to stable

[Greg KH]

On Sun, Jul 16, 2023 at 06:38:52PM +0200, Pali Rohár wrote:
> On Sunday 16 July 2023 18:32:42 Greg KH wrote:
> > On Sun, Jul 16, 2023 at 06:24:44PM +0200, Pali Rohár wrote:
> > > Hello,
> > > 
> > > I see that raspberry pi bootloader throws ton of warnings when supplied
> > > DTB file does not contain /__symbols__/ node.
> > > 
> > > On RPI 1B rev1 it looks like this:
> > > 
> > > dterror: no symbols found
> > > dterror: no symbols found
> > > dterror: no symbols found
> > > dterror: no symbols found
> > > dterror: no symbols found
> > > dterror: no symbols found
> > > dterror: no symbols found
> > > dterror: no symbols found
> > > dterror: no symbols found
> > > dterror: no symbols found
> > > 
> > > Bootloader also propagates these warnings to kernel via dtb property
> > > chosen/user-warnings and they can be read by simple command:
> > > 
> > > $ cat /sys/firmware/devicetree/base/chosen/user-warnings
> > > ...
> > > 
> > > Upstream Linux kernel build process by default does not generate
> > > /__symbols__/ node for DTB files, but DTB files provided by raspberrypi
> > > foundation have them for a longer time.
> > > 
> > > I wanted to look at this issue, but I figured out that it is already
> > > solved by just recent Aurelien's patches:
> > > 
> > > e925743edc0d ("arm: dts: bcm: Enable device-tree overlay support for RPi devices")
> > > 3cdba279c5e9 ("arm64: dts: broadcom: Enable device-tree overlay support for RPi devices")
> > > 
> > > My testing showed that /__symbols__/ node is required by rpi bootloader
> > > for overlay support even when overlayed DTB file does not use any DTB
> > > symbol (and reference everything via full node path). So seems that
> > > /__symbols__/ node is crucial for rpi bootloader even when symbols from
> > > them are not used at all.
> > > 
> > > So I would like to ask, would you consider backporting these two
> > > raspberry pi specific patches to stable kernel trees? Upstream kernel
> > > would get rid of those bootloader warnings and also allow users to use
> > > overlayed dtbs...
> > 
> > What kernel tree(s) should these be applied to?  What trees did you test
> > them for?
> > 
> > Also, adding dt-overlay support does not seem like a stable kernel fix,
> > as this isn't a bugfix from what I can tell, right?
> > 
> > thanks,
> > 
> > greg k-h
> 
> I wanted to discuss what do you think about it. As I wrote my motivation
> was to understood and get rid of those warnings "dterror: no symbols
> found" from bootloader when using DTB files from mainline kernel (as
> opposite of the DTB files from rpi foundation). And fix for it was just
> to generate DTB files from kernel via dtc's -@ parameter, same what are
> doing those mentioned patches (but they describe different problem for
> which is same fix). I thought that fixing those bootloader warnings is a
> bugfix.

Why not just use the next kernel version instead?  What's forcing you to
use an older stable kernel that didn't have dt-overlay support?

thanks,

greg k-h

Re: Backporting commits for generating rpi dtb symbols to stable

[Aurelien Jarno]

Hi,

On 2023-07-16 18:24, Pali Rohár wrote:
> Hello,
> 
> I see that raspberry pi bootloader throws ton of warnings when supplied
> DTB file does not contain /__symbols__/ node.
> 
> On RPI 1B rev1 it looks like this:
> 
> dterror: no symbols found
> dterror: no symbols found
> dterror: no symbols found
> dterror: no symbols found
> dterror: no symbols found
> dterror: no symbols found
> dterror: no symbols found
> dterror: no symbols found
> dterror: no symbols found
> dterror: no symbols found

Do you have those errors with the default configuration? On a RPI 4,
this only happens when setting uart_2ndstage to 1 in config.txt.
According to the documentation, this option enables diagnostic
information from the main firmware.

Unless this is different on RPI 1B, this means we are talking about a
warning that happens when enabling diagnostic information, so I am not
sure it warrants a change to stable kernels.

Regards
Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                     http://aurel32.net

Re: Backporting commits for generating rpi dtb symbols to stable

[Pali Rohár]

On Sunday 16 July 2023 21:08:38 Greg KH wrote:
> On Sun, Jul 16, 2023 at 06:38:52PM +0200, Pali Rohár wrote:
> > On Sunday 16 July 2023 18:32:42 Greg KH wrote:
> > > On Sun, Jul 16, 2023 at 06:24:44PM +0200, Pali Rohár wrote:
> > > > Hello,
> > > > 
> > > > I see that raspberry pi bootloader throws ton of warnings when supplied
> > > > DTB file does not contain /__symbols__/ node.
> > > > 
> > > > On RPI 1B rev1 it looks like this:
> > > > 
> > > > dterror: no symbols found
> > > > dterror: no symbols found
> > > > dterror: no symbols found
> > > > dterror: no symbols found
> > > > dterror: no symbols found
> > > > dterror: no symbols found
> > > > dterror: no symbols found
> > > > dterror: no symbols found
> > > > dterror: no symbols found
> > > > dterror: no symbols found
> > > > 
> > > > Bootloader also propagates these warnings to kernel via dtb property
> > > > chosen/user-warnings and they can be read by simple command:
> > > > 
> > > > $ cat /sys/firmware/devicetree/base/chosen/user-warnings
> > > > ...
> > > > 
> > > > Upstream Linux kernel build process by default does not generate
> > > > /__symbols__/ node for DTB files, but DTB files provided by raspberrypi
> > > > foundation have them for a longer time.
> > > > 
> > > > I wanted to look at this issue, but I figured out that it is already
> > > > solved by just recent Aurelien's patches:
> > > > 
> > > > e925743edc0d ("arm: dts: bcm: Enable device-tree overlay support for RPi devices")
> > > > 3cdba279c5e9 ("arm64: dts: broadcom: Enable device-tree overlay support for RPi devices")
> > > > 
> > > > My testing showed that /__symbols__/ node is required by rpi bootloader
> > > > for overlay support even when overlayed DTB file does not use any DTB
> > > > symbol (and reference everything via full node path). So seems that
> > > > /__symbols__/ node is crucial for rpi bootloader even when symbols from
> > > > them are not used at all.
> > > > 
> > > > So I would like to ask, would you consider backporting these two
> > > > raspberry pi specific patches to stable kernel trees? Upstream kernel
> > > > would get rid of those bootloader warnings and also allow users to use
> > > > overlayed dtbs...
> > > 
> > > What kernel tree(s) should these be applied to?  What trees did you test
> > > them for?
> > > 
> > > Also, adding dt-overlay support does not seem like a stable kernel fix,
> > > as this isn't a bugfix from what I can tell, right?
> > > 
> > > thanks,
> > > 
> > > greg k-h
> > 
> > I wanted to discuss what do you think about it. As I wrote my motivation
> > was to understood and get rid of those warnings "dterror: no symbols
> > found" from bootloader when using DTB files from mainline kernel (as
> > opposite of the DTB files from rpi foundation). And fix for it was just
> > to generate DTB files from kernel via dtc's -@ parameter, same what are
> > doing those mentioned patches (but they describe different problem for
> > which is same fix). I thought that fixing those bootloader warnings is a
> > bugfix.
> 
> Why not just use the next kernel version instead?  What's forcing you to
> use an older stable kernel that didn't have dt-overlay support?
> 
> thanks,
> 
> greg k-h

Why not use the next kernel? It is pretty simple, next is the
development tree, not for production. And as I wrote in previous email,
I do not need here dt-overlay support. I wanted to get rid off that
warning messages.

Re: Backporting commits for generating rpi dtb symbols to stable

[Pali Rohár]

On Sunday 16 July 2023 21:47:54 Aurelien Jarno wrote:
> Hi,
> 
> On 2023-07-16 18:24, Pali Rohár wrote:
> > Hello,
> > 
> > I see that raspberry pi bootloader throws ton of warnings when supplied
> > DTB file does not contain /__symbols__/ node.
> > 
> > On RPI 1B rev1 it looks like this:
> > 
> > dterror: no symbols found
> > dterror: no symbols found
> > dterror: no symbols found
> > dterror: no symbols found
> > dterror: no symbols found
> > dterror: no symbols found
> > dterror: no symbols found
> > dterror: no symbols found
> > dterror: no symbols found
> > dterror: no symbols found
> 
> Do you have those errors with the default configuration? On a RPI 4,
> this only happens when setting uart_2ndstage to 1 in config.txt.
> According to the documentation, this option enables diagnostic
> information from the main firmware.

Yes, I have it with default configuration. And I really do not know why
it is happening, I just described observations and that dtc -@ fixes
this issue. Note that this is about 1b rev1 (the first revision); so the
older HW, so maybe this can be a reason?

> Unless this is different on RPI 1B, this means we are talking about a
> warning that happens when enabling diagnostic information, so I am not
> sure it warrants a change to stable kernels.

Well, that is why I asked, if it is something for stable or not.

> Regards
> Aurelien
> 
> -- 
> Aurelien Jarno                          GPG: 4096R/1DDD8C9B
> aurelien@aurel32.net                     http://aurel32.net

Re: Backporting commits for generating rpi dtb symbols to stable

[Florian Fainelli]

[-- Attachment #1: Type: text/plain, Size: 3793 bytes --]



On 7/16/2023 9:51 PM, Pali Rohár wrote:
> On Sunday 16 July 2023 21:08:38 Greg KH wrote:
>> On Sun, Jul 16, 2023 at 06:38:52PM +0200, Pali Rohár wrote:
>>> On Sunday 16 July 2023 18:32:42 Greg KH wrote:
>>>> On Sun, Jul 16, 2023 at 06:24:44PM +0200, Pali Rohár wrote:
>>>>> Hello,
>>>>>
>>>>> I see that raspberry pi bootloader throws ton of warnings when supplied
>>>>> DTB file does not contain /__symbols__/ node.
>>>>>
>>>>> On RPI 1B rev1 it looks like this:
>>>>>
>>>>> dterror: no symbols found
>>>>> dterror: no symbols found
>>>>> dterror: no symbols found
>>>>> dterror: no symbols found
>>>>> dterror: no symbols found
>>>>> dterror: no symbols found
>>>>> dterror: no symbols found
>>>>> dterror: no symbols found
>>>>> dterror: no symbols found
>>>>> dterror: no symbols found
>>>>>
>>>>> Bootloader also propagates these warnings to kernel via dtb property
>>>>> chosen/user-warnings and they can be read by simple command:
>>>>>
>>>>> $ cat /sys/firmware/devicetree/base/chosen/user-warnings
>>>>> ...
>>>>>
>>>>> Upstream Linux kernel build process by default does not generate
>>>>> /__symbols__/ node for DTB files, but DTB files provided by raspberrypi
>>>>> foundation have them for a longer time.
>>>>>
>>>>> I wanted to look at this issue, but I figured out that it is already
>>>>> solved by just recent Aurelien's patches:
>>>>>
>>>>> e925743edc0d ("arm: dts: bcm: Enable device-tree overlay support for RPi devices")
>>>>> 3cdba279c5e9 ("arm64: dts: broadcom: Enable device-tree overlay support for RPi devices")
>>>>>
>>>>> My testing showed that /__symbols__/ node is required by rpi bootloader
>>>>> for overlay support even when overlayed DTB file does not use any DTB
>>>>> symbol (and reference everything via full node path). So seems that
>>>>> /__symbols__/ node is crucial for rpi bootloader even when symbols from
>>>>> them are not used at all.
>>>>>
>>>>> So I would like to ask, would you consider backporting these two
>>>>> raspberry pi specific patches to stable kernel trees? Upstream kernel
>>>>> would get rid of those bootloader warnings and also allow users to use
>>>>> overlayed dtbs...
>>>>
>>>> What kernel tree(s) should these be applied to?  What trees did you test
>>>> them for?
>>>>
>>>> Also, adding dt-overlay support does not seem like a stable kernel fix,
>>>> as this isn't a bugfix from what I can tell, right?
>>>>
>>>> thanks,
>>>>
>>>> greg k-h
>>>
>>> I wanted to discuss what do you think about it. As I wrote my motivation
>>> was to understood and get rid of those warnings "dterror: no symbols
>>> found" from bootloader when using DTB files from mainline kernel (as
>>> opposite of the DTB files from rpi foundation). And fix for it was just
>>> to generate DTB files from kernel via dtc's -@ parameter, same what are
>>> doing those mentioned patches (but they describe different problem for
>>> which is same fix). I thought that fixing those bootloader warnings is a
>>> bugfix.
>>
>> Why not just use the next kernel version instead?  What's forcing you to
>> use an older stable kernel that didn't have dt-overlay support?
>>
>> thanks,
>>
>> greg k-h
> 
> Why not use the next kernel? It is pretty simple, next is the
> development tree, not for production.

Maybe "next" should have not been taken as designating linux-next, but 
whichever kernel version you are currently using wait for 6.5 final and 
use it since it does contains Aurelien's commits.

> And as I wrote in previous email,
> I do not need here dt-overlay support. I wanted to get rid off that
> warning messages.

The motivation does not seem appropriate to warrant a stable backport, 
besides as noted in the commit message including relocation information 
inflates the resulting .dtb files, which could be seen as a regression.
-- 
Florian

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4221 bytes --]