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.
adam
Best regards,
Tim