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@xxxxxxxxxx> 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
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
