[fedora-arm] F21 disk image idea

[Hans de Goede]

Hi,

On 01/09/2014 07:02 PM, Dennis Gilmore wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> El Wed, 08 Jan 2014 14:16:55 -0800
> Brendan Conoboy <blc at redhat.com> escribió:
>> Hi everybody,
>>
>> There are two significant issues with the disk images in F20 that I
>> would like to address in F21:
>>
>> 1. Duplicate disk images with and without a VFAT partition.  This
>> doubles QA load and can confuse end users.
>
> I agree we need to drop the double images
>
>> 2. Unlike x86 spins, images aren't always ready to be used after
>> they're written to storage.  Instead, uboot bits need to be copied
>> into place using a specific method.  This is unintuitive and prone to
>> user error.
>
> This all needs to be wrapped in a tool to do the image customisation.
> we had a good start to it previously. We need someone interested to
> pick it up and run with it. the handling of setting up the card needs
> to happen for the user. I think I fixed the bug causing extlinux.conf
> to not be generated. I may need to build the fix. This is a great
> opportunity for someone to work on something.

I'm willing to help any volunteer willing to pick this up and run with
it. I'm reluctant to volunteer myself because my sunxi work for F-21
already is quite a bit of work (almost all happening upstream atm, so
somewhat invisible to people on this list, but that does not make it
cost any less time).

> I think your ideas for images are inherently horrible and should not be
> persued.  For one any content on the boot partition is not in the rpm
> database at all, two it would need for a whole new set of composing
> tools to be written. We would need to produce a massive list of
> image combinations to be used. the images we produce should work out
> of the box on any system that provides u-boot.  however some vendors
> have horribly different setups in their on board u-boot binaries

I would not use the word horrible, but otherwise I agree.

> We do have an issue of sorts by installing bot the unified kernal and
> the LPAE kernel in the images. I would like to propose we drop the LPAE
> kernel, if you need it you need to do an anaconda install.
>
> I plan to do work so that we use MLO in raw space and make sure the MLO
> on omap understands ext4 to load u-boot.img from. then we drop the vfat
> images all together.
>
> we need work and effort spent on making it better.  I think the only
> other viable option is to only produce a minimal image and have it
> pre-configured to work on a board. Which is basically what all other
> distros do. but even that will require a bit of work to do.

Ugh no, that way lies insanity. As I said before my allwinner respin
currently supports 52 boards. That number will drop a bit with F-21 as
I can only create dts files for boards I actually have (or community
members submit) but then we will still end up with quite a few, and that
is just Allwinnner.

Allwinner needs a separate u-boot binary (separate spl to be specific)
per board, as the soc has a very minimal bootload in ROM, and the initial
spl code needs to init the dram which is very board specific.

So unless we've some tool to turn a generic image into one for board
foo, that means 52 images (and that number is still growing all the time)
for Allwinner alone.

> We need to make it easier for the users.

+1  Have you seen my little select-board.sh hack / config script on
the Allwinner images? I'm not saying it is pretty code wise, but I
like how it works from a user pov. I would like to see F-21 have something
similar spanning a much wider range of devices.

If you've not seen it I'll give you a 1 minute demo in Brno, and we
should definitely discuss this further in Brno.

Regards,

Hans