-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 12 Sep 2014 10:45:53 -0500 Rob Herring <robherri...@gmail.com> wrote:
> On Fri, Sep 12, 2014 at 10:18 AM, Alexander Graf <ag...@suse.de> > wrote: > > > > > > On 12.09.14 17:05, Dennis Gilmore wrote: > >> On Fri, 12 Sep 2014 17:11:30 +0300 > >> Riku Voipio <riku.voi...@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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUE1tkAAoJEH7ltONmPFDRyVkQALwwWZdkWphe1ZbBV7I0r6GN wmzY2og1ZS1FaYdOcHs9xXs0S+GpT6k9a9mnJp/d6P5ug35yK4R7Noik/7fuqwOA 4dv44m6mk+kIrce4g5WUOUAcXtEy8xJuUnzgtKtr0T6p9cndNYs5voVsG28hrK3k XFEBuboZeFQc+DuI0/YPxdtYVVYqmsUJ3C2XYLVEvly1w2fdPEkXqgXrWEGlzwjW icfkx0jNoTO3B/eBPVoJfPGZRy9HjaG/u+KaxBsKNbuZjvDrRtutcAEO+tN160+b i8V6rKvsF05T0sN3SDyXk8HpvJ5Y9k4HkE7peNvjJkEVwvBk9k/O7QFcvAqyLOJd IMqSZTrGyh1uTLU3gBZPP6H7wHo1PsXiuB9eO6fxIcBJcjiGBWJDNrlRa7KW0Twr sG0lfyTvkJ7CD+5m5ibE9r0OfWvVGjYPeGwt48JoexGHk9LaCtz2sARHrMuvavpm 5IuKauv9QhBHeBzjFUIYKV+wDD6onNq39pXAL7XGSODQqCNv7MjxkJa3jN4+PAKH tNVUUeh1euMtr/FVx+sQ2/iAfBQH0WHMNjsffWrgf3ubxtMMFaUB3d1aSd1OAtZ9 pe1F0jX1juGAx0kOZCHkqJOK8kX8z0tuZ64A+5mJfcudTkoEZptG6tqejAqzl9xD /h2wGWA9H+baDgdDVC2r =xGDZ -----END PGP SIGNATURE----- _______________________________________________ cross-distro mailing list cross-distro@lists.linaro.org http://lists.linaro.org/mailman/listinfo/cross-distro
