[PATCH] Revert "spl: Drop bd_info in the data section"

Alex G. mr.nuke.me at gmail.com
Mon Apr 19 04:26:21 CEST 2021

On 4/16/21 6:16 PM, Adam Ford wrote:
> On Fri, Apr 16, 2021 at 3:41 PM Tim Harvey <tharvey at gateworks.com> wrote:
>> On Mon, Apr 12, 2021 at 11:44 AM Simon Glass <sjg at chromium.org> wrote:
>>> Hi Tom,
>>> On Tue, 13 Apr 2021 at 06:38, Tom Rini <trini at konsulko.com> wrote:
>>>> On Tue, Apr 13, 2021 at 06:26:08AM +1200, Simon Glass wrote:
>>>>> Hi Tom,
>>>>> On Tue, 13 Apr 2021 at 06:18, Tom Rini <trini at konsulko.com> wrote:
>>>>>> On Tue, Apr 13, 2021 at 05:49:19AM +1200, Simon Glass wrote:
>>>> [snip]
>>>>>>> As to a weak function, what would the default behaviour be? If we can
>>>>>>> define that, then it would be better IMO.
>>>>>>> When we try to refactor things, weak functions and undefined (or
>>>>>>> arch-specific behaviour) can really make things tough.
>>>>>> Well, what was the problem you were trying to solve here?  I assumed
>>>>>> there was a case where things actively broke, with the previous design,
>>>>>> and it's not just the 64byte savings in some cases.  But is it?
>>>>> Yes the region of memory is not writable, so must be allocated at runtime.
>>>> Where, on x86?  Some ARM cases?  That's one of the other things to sort
>>>> out here.
>>> Yes, on coral and likely newer things to come...For ARM I don't know
>>> of any such problems.
>> I'm not sure I understand if there is agreement on a solution to this
>> patch breaking several or many boards? I count 58 IMX6 boards using
>> SPL and none of them currently define CONFIG_SPL_ALLOC_BD=y. It sounds
>> like Adam said OMAP boards were broken as well and I'm not clear if
>> those boards are fixed yet either.
> I have already submitted a patch for the OMAP boards that I maintain
> to address the issue.  I wonder if it would make sense to make these
> architectures select CONFIG_SPL_ALLOC_BD automatically instead of
> having a bunch of individual boards enable it.  I have not checked any
> of the IMX8M or IMX6 boards that I maintain, but I am watching this
> thread.  I can test the CONFIG_SPL_ALLOC_BD on my boards if people
> think there is value.

I've been thinking about what Simon said -- that the memory region is 
not writable on x86. But that memory is in .data, which should be 
writable. It doesn't make sense.


More information about the U-Boot mailing list