From: Alex G. <mr.nuke.me@gmail.com>
To: u-boot@lists.denx.de
Subject: [PATCH] Revert "spl: Drop bd_info in the data section"
Date: Sun, 18 Apr 2021 21:26:21 -0500 [thread overview]
Message-ID: <6df20855-ac32-ef46-3b54-7a76041f5a53@gmail.com> (raw)
In-Reply-To: <CAHCN7xJoe06OWs5RVoWSSvWhSk14X4a4vEENm1q3kn_3TZeEnw@mail.gmail.com>
On 4/16/21 6:16 PM, Adam Ford wrote:
> On Fri, Apr 16, 2021 at 3:41 PM Tim Harvey <tharvey@gateworks.com> wrote:
>>
>> On Mon, Apr 12, 2021 at 11:44 AM Simon Glass <sjg@chromium.org> wrote:
>>>
>>> Hi Tom,
>>>
>>> On Tue, 13 Apr 2021 at 06:38, Tom Rini <trini@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@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.
Alex
next prev parent reply other threads:[~2021-04-19 2:26 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-08 16:56 [PATCH] Revert "spl: Drop bd_info in the data section" Alexandru Gagniuc
2021-04-08 23:55 ` Simon Glass
2021-04-09 19:20 ` Alex G.
2021-04-09 20:24 ` Adam Ford
2021-04-09 20:53 ` Tom Rini
2021-04-10 0:29 ` Tim Harvey
2021-04-12 13:25 ` Tom Rini
2021-04-12 13:51 ` Alex G.
2021-04-12 14:40 ` Tom Rini
2021-04-12 15:21 ` Alex G.
2021-04-12 16:26 ` Tom Rini
2021-04-12 17:49 ` Simon Glass
2021-04-12 18:18 ` Tom Rini
2021-04-12 18:26 ` Simon Glass
2021-04-12 18:38 ` Tom Rini
2021-04-12 18:44 ` Simon Glass
2021-04-16 20:40 ` Tim Harvey
2021-04-16 23:16 ` Adam Ford
2021-04-19 2:26 ` Alex G. [this message]
2021-04-19 15:32 ` Tom Rini
2021-04-19 17:33 ` Tom Rini
-- strict thread matches above, loose matches on Subject: below --
2021-04-20 14:17 xiaobo
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=6df20855-ac32-ef46-3b54-7a76041f5a53@gmail.com \
--to=mr.nuke.me@gmail.com \
--cc=u-boot@lists.denx.de \
/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.