On 01/09/2014 10:02 AM, Dennis Gilmore wrote:
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.
Sure, a tool to do image customization is very desirable and it sounds like Hans is willing to do more in this area. My suggestion is that we run it on both ends- and distribute the deltas it produces.
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,
It doesn't have to be- the tool works with the image produced by standard tooling.
> two it would need for a whole new set of composing
tools to be written.
Yep, no magic switch is currently available. It also means distributing a class of file we haven't distributed before. And updating documentation.
> We would need to produce a massive list of
image combinations to be used.
We're already shipping more than 100 dtbs. Isn't it time we start formally lining these up with the uboots you are producing?
> 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
Yep.
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.
As long as we produce dtbs for the systems that are currently only present in the LPAE kernel that's fine by me.
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.
Disagree with dropping vfat- it will limit our ability to work on new boards which require it. We should drop the non-vfat images and pursue more installation options.
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.
That's almost what I'm suggesting, except the idea is to split the OS from the board support.
We need to make it easier for the users. Id also like to have installer images for f21, something similar to boot.iso on x86. but even on many systems you need to setup something extra to have it boot. esentially this all boils down to a lack of standards for booting arm systems and vendors saving a few dollars by not putting onboard nand, spi, etc flashes that can be used to hold the u-boot.
Yes. -- Brendan Conoboy / Red Hat, Inc. / blc@xxxxxxxxxx _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
