-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 12 Sep 2014 10:45:53 -0500 Rob Herring robherring2@gmail.com wrote:
On Fri, Sep 12, 2014 at 10:18 AM, Alexander Graf agraf@suse.de wrote:
On 12.09.14 17:05, Dennis Gilmore wrote:
On Fri, 12 Sep 2014 17:11:30 +0300 Riku Voipio riku.voipio@linaro.org wrote:
Hi,
I've just invited a bunch of attendees at linaro connect for cross-distribution meeting in the next connect. Sadly it's not officially on the scheduled talks, so there is no remote participation this time. However you still have a change to reply here and add items to our agenda :)
Draft agenda:
- Review status of various distributions ARMv7 and ARMv8 support
- Discuss boot environment standardization (U-Boot/UEFI/GRUB..)
- uEnv.txt
armv7 should all be standardising on extlinux.conf u-boot is rapidly adopting it as the standard way for distros to boot, and have a stable know interface between the distro and u-boot
I'm personally not quite as passionate here. My main concern is that I want things to be consistent across the board at least inside of openSUSE.
I want things to be consistent across distros. Making life simpler for us all.
But the problem is vendors need clear instructions for how to configure their u-boot correctly for distros. Having per distro instructions is not going to work as they will ignore the distros they don't care about at the time. They may not care about any distro either, so we have to make it trivial to enable or default.
I am working on updating the docs so that its simple for vendors to get it right. Vendors using old forked trees only really need to reevaluate what they are doing, but that is a different conversation.
There are platforms out there that simply load a boot.scr from SD card, so that's a mechanism I have to support anyway.
That said, I wouldn't mind to provide another u-boot binary for that particular platform, boot into it and then have that one check for an extlinux.conf.
There's probably 2 categories here:
- No extlinux support -> needs a new u-boot build
- extlinux support, but not the right env or boot scripts -> use
boot.scr/uEnv.txt to fixup the environment.
yes, but everytime you need to do something special and different for a system takes it one step closer to being unmanageable.
I do strongly feel that we need to work with hardware vendors to ensure all devices have onboard storage for u-boot or uefi. Talking to the guys doing the cubox-i one day I felt their reasons for not providing storage were not valid. it also makes things like mass deployment much more difficult. an example, take 1000 cubietrucks. as long as they have a good u-boot on them (not always the case today) to deploy you could just turn them all on. they would pxe boot and network install, if you used something like kickstart you do not need to do any intervention and away you go. you oculd have them all up, running and configured in no time. to do the same with 1000 cubox-i's you would need to install u-boot onto 1000 sdcards plug themin and turn on. it is much more labour intensive and hands on.
But whatever happens, it really has to be consistent across the board, and preferably still work with older downstream u-boot forks.
- legacy platforms
- Installers vs pre-built images
we should eb using installers where ever possible.
Why? For most use cases the image based approach is nicer.
I would like to understand why you think that.
People are going to want both. Are there different issues around standardization for images?
There are cases for images. In Fedora we have tools to run some configuration on first boot. but many use cases running an automated install is exactly what you need.
That said, for AArch64 with EFI we will provide both installers and images (and tools to create your own images).
aarch64 the first thing we will use is an installer, images will be created by the installer, though at the moment I think the only plans for images are use in cloud environments.
I do not profess to know how long 32 bit arm hardware will be viable for use, but we should do all we can to make that experience the best possible for the end users. I think linaro could go a long way to working with hardware vendors to get them onboard with standardising a minimal amount of hardware that they install. making sure systems have a battery backed hw rtc clock would be good also. and not the confusing mess of the cubox-i they added a second one that's battery backed so /dev/rtc0 is the soc rtc and has no battery backup and /dev/rtc1 is an added rtc that is battery backed. it makes it harder than need be to work out what rtc to read from and set the system time on boot
Dennis