Hi Andre, On Tue, 13 Aug 2024 at 06:35, Andre Przywara <andre.przyw...@arm.com> wrote: > > On Tue, 13 Aug 2024 06:17:17 -0600 > Simon Glass <s...@chromium.org> wrote: > > Hi Simon, > > I had a bit deeper look yesterday.
Thanks for digging into this. > > > Hi Andre, > > > > On Mon, 12 Aug 2024 at 10:00, Andre Przywara <andre.przyw...@arm.com> wrote: > > > > > > On Wed, 7 Aug 2024 14:50:26 -0600 > > > Simon Glass <s...@chromium.org> wrote: > > > > > > Hey Simon, > > > > > > > This series attempts to migrate all sunxi boards to use standard boot, > > > > along with a text environment. > > > > > > Ah, many thanks for that! I figured that we need a bootmeth for FEL, but > > > never got around to have a closer look. > > > On a coarse glance, this looks roughly OK, and doing a super quick boot > > > test on one board, it seems to still work(TM), though the priority of the > > > FEL boot is not right? > > > > Does it need to be the top priority, perhaps? > > Yes, please. It should only trigger when you a) do FEL booting and b) > upload a boot script via FEL, in which case you surely want to execute > that before anything else. From what I see the global EFI bootmeth is first > in the list, but I couldn't find an easy way to fix this in the source > file. Would that go through a platform specific bootmeths env variable? We can just rename the bootmeth to be before the EFI mgr one. > > > > And I guess ditching the old kernel support might be a bit controversial. > > > I think this is about the vendor kernels, which some people still rely on? > > > > OK, perhaps it is. It might be a little tricky to handle it, but I > > suspect another bootmeth might be enough. > > Well, I had a look, and it looks like CONFIG_OLD_SUNXI_KERNEL_COMPAT > covers multiple things: > - it sets up some clocks slightly differently > - it enters the kernel (stays?) in secure mode > - it provides a custom boot script > > I think the latter can be replaced quite easily with something custom, and > I guess it's the only one biting you? So I am OK with that going, but I > think we should keep the first two features (and thus the Kconfig symbol). Yes the script is the only issue and actually it doesn't affect standard boot. So I can just convert it. I was just hoping to remove some old code! > > > Another thing I discovered: we lose USB support with patch 3/6. The reason > is that USB support is enabled by having DISTRO_DEFAULTS. Just replacing > that with BOOTSTD_DEFAULTS didn't work, though, I get a (ridiculous) splat > about a circular Kconfig dependency. My hunch is that's something else not > right in Kconfig, but I need to have a closer look. Oh yes that is nasty. The problem goes back to BLK being selected by various things, while BOOTSTD depends on it. I eventually found a solution so will include that in v2. Regards, Simon
