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