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 :-)
------------------------------------------------------------------------------
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
