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 - legacy platforms - Installers vs pre-built images - What remaning OSS software needs to be ported to ARMv8 - Identifying common pain points Linaro could solve
Also, if you are interested in the session and didn't get an invite from me - just mail me and I'll add you to the meeting in zerista - or just pop up at the Platform hacking room in tuesday. The meeting might move somewhere else, but people in the room will be able to give the directions to the moved meeting.
Riku
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
- legacy platforms
- Installers vs pre-built images
we should eb using installers where ever possible.
- What remaning OSS software needs to be ported to ARMv8
- Identifying common pain points Linaro could solve
Also, if you are interested in the session and didn't get an invite from me - just mail me and I'll add you to the meeting in zerista - or just pop up at the Platform hacking room in tuesday. The meeting might move somewhere else, but people in the room will be able to give the directions to the moved meeting.
Seems like something I should attend but I will not be at linaro connect. If I had known about it sooner perhaps I could have made it. but a couple of days is not enough time to organise anything.
Denni
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. 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.
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.
That said, for AArch64 with EFI we will provide both installers and images (and tools to create your own images).
- What remaning OSS software needs to be ported to ARMv8
- Identifying common pain points Linaro could solve
Testing of upstream kernels. Especially in non-defconfig configurations where everything is a module. IIUC Linaro has automated testing for a good number of boards. It would be great if they could also test the upstream kernel - maybe in allmodconfig style configurations?
Also, if you are interested in the session and didn't get an invite from me - just mail me and I'll add you to the meeting in zerista - or just pop up at the Platform hacking room in tuesday. The meeting might move somewhere else, but people in the room will be able to give the directions to the moved meeting.
Seems like something I should attend but I will not be at linaro connect. If I had known about it sooner perhaps I could have made it. but a couple of days is not enough time to organise anything.
I won't be there either.
Alex
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.
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.
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.
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.
People are going to want both. Are there different issues around standardization for images?
That said, for AArch64 with EFI we will provide both installers and images (and tools to create your own images).
- What remaning OSS software needs to be ported to ARMv8
- Identifying common pain points Linaro could solve
Testing of upstream kernels. Especially in non-defconfig configurations where everything is a module. IIUC Linaro has automated testing for a good number of boards. It would be great if they could also test the upstream kernel - maybe in allmodconfig style configurations?
Really, it is Olof and Kevin Hilman doing most of the useful testing here, but I believe they are only boot testing various defconfigs. allmodconfig probably needs some work to actually boot on most platforms. It certainly needs some tweaks to not enable BE build for example.
Rob
Also, if you are interested in the session and didn't get an invite from me - just mail me and I'll add you to the meeting in zerista - or just pop up at the Platform hacking room in tuesday. The meeting might move somewhere else, but people in the room will be able to give the directions to the moved meeting.
Seems like something I should attend but I will not be at linaro connect. If I had known about it sooner perhaps I could have made it. but a couple of days is not enough time to organise anything.
I won't be there either.
Alex
cross-distro mailing list cross-distro@lists.linaro.org http://lists.linaro.org/mailman/listinfo/cross-distro
On 12.09.14 17:45, Rob Herring 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.
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 agree.
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.
Sounds reasonable. But keep in mind that there will be quite a significant transitioning phase.
Also, I think for AArch64 we're pretty much set on EFI by now I think.
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.
People are going to want both. Are there different issues around standardization for images?
I think standardization of images is a lot easier, because you don't have to put board specific knowledge into the (generic) installer.
IMHO for 32bit most of this is a lost cause - things are over and done. For AArch64 we'll get EFI and everything I've tested there so far works impressively well.
That said, for AArch64 with EFI we will provide both installers and images (and tools to create your own images).
- What remaning OSS software needs to be ported to ARMv8
- Identifying common pain points Linaro could solve
Testing of upstream kernels. Especially in non-defconfig configurations where everything is a module. IIUC Linaro has automated testing for a good number of boards. It would be great if they could also test the upstream kernel - maybe in allmodconfig style configurations?
Really, it is Olof and Kevin Hilman doing most of the useful testing here, but I believe they are only boot testing various defconfigs. allmodconfig probably needs some work to actually boot on most platforms. It certainly needs some tweaks to not enable BE build for example.
Well, there you have one more item on the list then :).
Alex
On Fri, Sep 12, 2014 at 10:50 AM, Alexander Graf agraf@suse.de wrote:
On 12.09.14 17:45, Rob Herring 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.
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 agree.
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.
Sounds reasonable. But keep in mind that there will be quite a significant transitioning phase.
Also, I think for AArch64 we're pretty much set on EFI by now I think.
For servers yes, but for other things not so much. I'm working on a aarch64 chip with u-boot right now. How much the distros care about non-server focused boards varies.
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.
People are going to want both. Are there different issues around standardization for images?
I think standardization of images is a lot easier, because you don't have to put board specific knowledge into the (generic) installer.
IMHO for 32bit most of this is a lost cause - things are over and done. For AArch64 we'll get EFI and everything I've tested there so far works impressively well.
Again, depends on the market. There's some silly people that think we'll still have 32-bit systems in 2038. ;)
Rob
-----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
Thanks for pulling this together.
I'll be there speaking for the Gentoo side of things.
On Fri, Sep 12, 2014 at 9:11 AM, 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
- legacy platforms
- Installers vs pre-built images
- What remaning OSS software needs to be ported to ARMv8
- Identifying common pain points Linaro could solve
Also, if you are interested in the session and didn't get an invite from me - just mail me and I'll add you to the meeting in zerista - or just pop up at the Platform hacking room in tuesday. The meeting might move somewhere else, but people in the room will be able to give the directions to the moved meeting.
Riku
cross-distro mailing list cross-distro@lists.linaro.org http://lists.linaro.org/mailman/listinfo/cross-distro
On 09/12/2014 07:11 AM, Riku Voipio 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 :)
Can this get added to the schedule? Many distro representatives will not be there in person. We've relied upon the remote participation option for years and would like to go on doing so. Thanks,
Agreed. Also, I selfishly suggest that Tue is particularly bad and favor Mon pm.
On September 12, 2014 1:51:47 PM EDT, Brendan Conoboy blc@redhat.com wrote:
On 09/12/2014 07:11 AM, Riku Voipio 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 :)
Can this get added to the schedule? Many distro representatives will not be there in person. We've relied upon the remote participation option for years and would like to go on doing so. Thanks,
-- Brendan Conoboy / Red Hat, Inc. / blc@redhat.com
cross-distro mailing list cross-distro@lists.linaro.org http://lists.linaro.org/mailman/listinfo/cross-distro
I'll have a chat with the powers that be to find a slot. Probably would push it out into the week a bit, like Thursday for instance.
On Fri, Sep 12, 2014 at 10:34 PM, Jon Masters jonathan@jonmasters.org wrote:
Agreed. Also, I selfishly suggest that Tue is particularly bad and favor Mon pm.
On September 12, 2014 1:51:47 PM EDT, Brendan Conoboy blc@redhat.com wrote:
On 09/12/2014 07:11 AM, Riku Voipio 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 :)
Can this get added to the schedule? Many distro representatives will not be there in person. We've relied upon the remote participation option for years and would like to go on doing so. Thanks,
-- Computer Architect | Sent from my #ARM Powered Mobile device
cross-distro mailing list cross-distro@lists.linaro.org http://lists.linaro.org/mailman/listinfo/cross-distro
On 13 September 2014 06:38, Tom Gall tom.gall@linaro.org wrote:
I'll have a chat with the powers that be to find a slot. Probably would push it out into the week a bit, like Thursday for instance.
Thanks, worth always asking.
Riku
Hi,
The meeting has been moved from hacking room to "Regency Ballroom A". Zerista managed to lose the attendee list while moving, so I had to create the list again, therefor some people may have been missing from the list. Feel free to pass information to ensure all distro people here know we are having the session.
For next connect, I'll make sure we have a proper scheduled slot with remote streaming - this time I was just too late, and the organizers understandably don't really appreciate last minute sessions...
Riku
-
Alexander Graf -
Brendan Conoboy -
Dennis Gilmore -
Jon Masters -
Riku Voipio -
Rob Herring -
Tom Gall