On 26 November 2013 11:43, Olivier Martin <[email protected]> wrote:
> Hi Ryan/Leif, > > > > I was initially happy enough with the solution #4 and wanted to push your > change to SVN. And yes, I can only be agree on the fact the EFI stub is the > way we want to go to boot Linux kernel on a UEFI system. > > But I am not sure how the EFI stub will solve your problem. > > Even with the EFI stub, you will still need to change you Continuous > Integration Infrastructure to start the Linux kernel with different > parameters for Android/Ubuntu/OpenEmbedded > > > > So, it looks the only solution is #1. > > I do not mind to push your patch, but that will not help you in the future > neither. > I don't think ARM/BDS (and this patch) will be at all related to how the boards are booted by whatever LEG use in the future. I think the intention is that LEG provide something to *replace* ARM/BDS, not something that uses it. So I guess my patch is only relevant for those who use ARM/BDS. > > > Thanks, > > Olivier > > > > > > From: Ryan Harkin [mailto:[email protected]] > Sent: 19 November 2013 11:23 > To: Leif Lindholm > Cc: [email protected]; [email protected]; > Olivier Martin; Steven Kinney > Subject: Re: ARM/BDS: skip initrd if not found > > > > > > > > On 19 November 2013 10:34, Leif Lindholm <[email protected]> wrote: > > Hi Ryan, > > > On Tue, Nov 19, 2013 at 08:30:25AM +0000, Ryan Harkin wrote: > > Hi Olivier/Steve/Leif/whoever is interested, > > > > I have a problem I'm trying to solve and I don't think there is a proper > > solution using the current ARM BDS. > > > > > Basically, some of Linaro's releases are failing to boot "out of the > > box" due to incorrect default BDS config. The default assumes that > the > > > image has an initrd. > > > > Android (the main focus of our releases) and Ubuntu images use an initrd. > > OpenEmbedded images do not. > > > > I'd like a single UEFI binary that can work on all three without > > reconfiguration. > > > > The obvious solutions are: > > 1) there is no default config that always works and the user should > configure > > the board > > themselves each time they want to boot a different image type. > > Our LAVA automated test environment and people like myself who boot > test > > many images > > daily don't favour this option. > > > > 2) change OpenEmbedded to use an initrd > > It's not my image to change and the owners don't want to do that > because > > it's also wrong. > > > > 3) Have different UEFI binaries for each image type > > This isn't ideal because I (and LAVA) would be forever reflashing > UEFI. > > > > 4) Make BDS continue if it can't load the initrd > > This isn't ideal because if there is no initrd, it could be for a bad > > reason. By continuing, we > > aren't giving the user the change to immediately correct the config. > > However, the likelihood of the initrd being completely missing, whilst > a > > valid kernel and FDT > > is provided seems slim. If it is missing, it's most likely on > purpose. > > > > Of the options above, I prefer #4 and have provided a patch below for > > discussion. I suspect that if it's not going to cause other problems, it > could > > be like my other BDS hacks, fixes and improvements and only live in the > Linaro > > tree, which would be fine with me too. > > > > Opinions on a way forward and/or this patch? > > Medium-term, I would say that the correct thing to do will be to simply > use the UEFI stub loader version of the kernel image. But you may not > want to take on the tediousness of having to sync this not-yet-upstream > patchset across the various kernel branches things will build from for > each new release until this code does go upstream? > > > > I agree, moving to a proper boot solution is the end goal. But a lot of > that end-goal is out of my control/domain, so I'm hacking what I have to > make it more usable until the cool stuff hits mainline. > > > > I would say that the solution your patch introduces is wrong, but it is > less wrong than the current situation - so I have no fundamental > objection. > > > > I agree, it's not ideal, but as you say, it's less wrong. > > > > If we wanted to keep the built-in Linux loader, I would say that the > correct fix would be to add a "has initrd" property, or a NULL string > chack for the path. But we don't, so we shouldn't spend time trying to > to improve a way too old stop-gap solution. > > > > The initrd can be configured out in the default config, so UEFI does not > attempt to even load it. However, in that case, a single UEFI binary's > default config will fail to load an Android or Ubuntu image, because they > need an initrd. > > Really, I'm working around the fact that we cannot provide a config to BDS; > the config either has to be initialised by the UEFI binary or hand edited > by > the user. If we had that feature, each image (Android, Ubuntu, OE) could > provide a config that it knew would work. > > > > > / > Leif > > p.s. > The built-in Linux loader delenda est! > > > > Yes please :-) > > > _______________________________________________ > boot-architecture mailing list > [email protected] > http://lists.linaro.org/mailman/listinfo/boot-architecture > _______________________________________________ boot-architecture mailing list [email protected] http://lists.linaro.org/mailman/listinfo/boot-architecture
