On 26 November 2013 11:43, Olivier Martin <olivier.mar...@arm.com> 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:ryan.har...@linaro.org]
> Sent: 19 November 2013 11:23
> To: Leif Lindholm
> Cc: boot-architect...@lists.linaro.org; edk2-devel@lists.sourceforge.net;
> Olivier Martin; Steven Kinney
> Subject: Re: ARM/BDS: skip initrd if not found
>
>
>
>
>
>
>
> On 19 November 2013 10:34, Leif Lindholm <leif.lindh...@linaro.org> 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
> boot-architect...@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/boot-architecture
>
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
