Hi there
flash-kernel is this place where we add support for a lot of weird boards of various architectures. "flash-kernel" because it used to just write a kernel to Flash memory, but that's not always true anymore. Because it's integrated in d-i and with initramfs-tools / linux packages, it is the easiest way to add support for one new board.
But flash-kernel isn't in the happiest state right now, as new boards were added by copy-pasting the installation logic of other boards over and over. Also, Ubuntu added more and more boards and features to its flash-kernel package, and the delta is really big now (I will take part of the blame for allowing this to happen).
In the light of this situation, and because I think Debian and derivatives will support more and more boards via flash-kernel in the future (for instance modern ARM boards in the armel/armhf ports), I'm interested in improving flash-kernel's code, architecture and scalability (in fact, I started working on it [1]).
I'm at the Emdebian sprint in Cambridge this week and I wanted to pursue work on flash-kernel this week, but a lot of people here would like to have a discussion on this work, and other people seem to be interested in solving the same problems in flash-kernel. So in the interest of avoiding work duplication and in the hope to come up with a good roadmap and target architecture for flash-kernel, I'll be hosting a discussion on flash-kernel development tomorrow morning at 11am UK time. (Sorry for the late notice!) If you're interested in flash-kernel, if you have ideas, patches, etc. consider dialing in! Of course, email works too. I'll work on a wiki page summarizing tomorrow's discussion and the plans around flash-kernel.
Dial-in details: Access code: 52386 86884#
UK Local +44 207 630 2405 UK Freephone 0800 026 0166 US Local +1 781 761 9450 US Toll Free 1 866 352 2709 Brazil 0800 881 0038 Canada 1 866 352 2710 Finland 800 523 103 France 0 805 980 044 Germany 800 589 0993 New Zealand 800 452 290 Taiwan 0800 265 855 China (North) 10 800 152 1873 China (South) 10 800 852 1873 India 000 800 100 7944 Poland 800 331 1398
Anybody is welcome to dial-in. I'd welcome if you would notify me of your presence so that we can expect you on the call. We'll be using #emdebian as back-channel.
Cheers,
[1] branch at http://git.debian.org/?p=users/lool/d-i/flash-kernel.git * adds a testsuite * consolidates code into functions * moves board support data into a database (currently inline for convenience of testing, but will be split out in its own file)
On Tue, Feb 22, 2011 at 3:59 PM, Loïc Minier loic.minier@linaro.org wrote:
[1] branch at http://git.debian.org/?p=users/lool/d-i/flash-kernel.git * adds a testsuite * consolidates code into functions * moves board support data into a database (currently inline for convenience of testing, but will be split out in its own file)
Does it make sense to move this 'database' out to /etc/boards/ ?
On Tue, Feb 22, 2011, Amit Kucheria wrote:
On Tue, Feb 22, 2011 at 3:59 PM, Loïc Minier loic.minier@linaro.org wrote:
* moves board support data into a database (currently inline for convenience of testing, but will be split out in its own file)
Does it make sense to move this 'database' out to /etc/boards/ ?
Sure; it will eventually be a collection of files, which I'd prefer seeing in /usr/share/flash-kernel rather than /etc (but maybe we should also allow for files in /etc/flash-kernel). It's just something I'm deferring while working on the code because it's a bit easier to work on a single file at the moment.
On Tue, 22 Feb 2011 14:59:05 +0100, Loïc Minier loic.minier@linaro.org wrote:
[1] branch at http://git.debian.org/?p=users/lool/d-i/flash-kernel.git
- adds a testsuite
- consolidates code into functions
- moves board support data into a database (currently inline for convenience of testing, but will be split out in its own file)
I ask mostly from a position of ignorance, but is the information in this database related to the information linaro-media-create keeps about each board? If so, could it be shared somehow?
Cheers, mwh
On Wed, Feb 23, 2011, Michael Hudson-Doyle wrote:
I ask mostly from a position of ignorance, but is the information in this database related to the information linaro-media-create keeps about each board? If so, could it be shared somehow?
It's completely related and I envisioned we could share it some time ago: http://www.mail-archive.com/linaro-dev@lists.linaro.org/msg00254.html even before linaro-image-tools existed ;-)
But thanks for bringing this up, it's a good thing to put on the goals for the rework: that the data be usage-agnostic and self-contained as to allow reuse in other places.
On 02/22/2011 09:54 PM, Somebody in the thread at some point said:
Hi -
I ask mostly from a position of ignorance, but is the information in this database related to the information linaro-media-create keeps about each board? If so, could it be shared somehow?
It's completely related and I envisioned we could share it some time ago: http://www.mail-archive.com/linaro-dev@lists.linaro.org/msg00254.html even before linaro-image-tools existed ;-)
But thanks for bringing this up, it's a good thing to put on the goals for the rework: that the data be usage-agnostic and self-contained as to allow reuse in other places.
Since we discuss this later today going to throw my thoughts out there.
Over the longer term I think it could be possible to arrange things that
- hwpacks as they are
- initrds, and
- Qemu requirement for image composition, maybe whole l-m-c
could in most or all cases be dispensed with. In that situation l-m-c itself would ideally disappear into composition-host-runnable scripts down /etc/board-specific.d or /usr/share/whatever.d for hosts that have a concept of external bootloader and / or kernel composition (ie, not shoving it in local NAND but SD card). So, at what used to be l-m-c time you run on the composition host the same scripts that the native device uses for bootloader and kernel install from the composed rootfs itself, with suitable abstraction of device names and so on.
Any scripting config left from kernel package install could be batched and deferred until first boot where it runs natively.
Another kinda-related simplification that would pay dividends is to enable taking advantage of multi-board kernels within the same arch that are possible, by having the same deal in terms of multi-board bootloaders within the same arch. Currently X-loader and U-Boot take a compile-time config approach that forces them to emit ultra-specific bootloader binaries.
If that was fixed then it'd be possible to have, eg, a single Omap4 kernel package and a single Omap4 bootloader package that worked on all supported Omap4 boards and so on.
-Andy
On Wed, Feb 23, 2011, Andy Green wrote:
Over the longer term I think it could be possible to arrange things that
- hwpacks as they are
- initrds, and
- Qemu requirement for image composition, maybe whole l-m-c
could in most or all cases be dispensed with. In that situation l-m-c itself would ideally disappear into composition-host-runnable scripts down /etc/board-specific.d or /usr/share/whatever.d for hosts that have a concept of external bootloader and / or kernel composition (ie, not shoving it in local NAND but SD card). So, at what used to be l-m-c time you run on the composition host the same scripts that the native device uses for bootloader and kernel install from the composed rootfs itself, with suitable abstraction of device names and so on.
Any scripting config left from kernel package install could be batched and deferred until first boot where it runs natively.
Hmm this is a bit too far-looking for me
Another kinda-related simplification that would pay dividends is to enable taking advantage of multi-board kernels within the same arch that are possible, by having the same deal in terms of multi-board bootloaders within the same arch. Currently X-loader and U-Boot take a compile-time config approach that forces them to emit ultra-specific bootloader binaries.
If that was fixed then it'd be possible to have, eg, a single Omap4 kernel package and a single Omap4 bootloader package that worked on all supported Omap4 boards and so on.
So John Rigby had proposed a similar approach, but Steve Sakoman had suggested that it's really hard to identify the board you're running on safely. And you need the information of the exact board relatively early because you need to setup DDR, access the MMC and serial console etc.
On 02/23/2011 10:28 AM, Somebody in the thread at some point said:
Hi -
Any scripting config left from kernel package install could be batched and deferred until first boot where it runs natively.
Hmm this is a bit too far-looking for me
I mention it because kernel post-install scriptlets was flagged as a reason for needing a native environment for kernel install action in linaro-media-create; by reserving those post-install actions to run at the first boot that'd no longer be a problem.
If that was fixed then it'd be possible to have, eg, a single Omap4 kernel package and a single Omap4 bootloader package that worked on all supported Omap4 boards and so on.
So John Rigby had proposed a similar approach, but Steve Sakoman had suggested that it's really hard to identify the board you're running on safely. And you need the information of the exact board relatively early because you need to setup DDR, access the MMC and serial console etc.
Well:
1) You only need to identify between boards of the same arch.
2) If the boards are so similar they can't be told apart, then from the bootloader's perspective of just needing to init a minimum of assets to "load and boot" Linux, then typically there will zero differences and we don't actually care, or one difference that matters, the particular SDRAM chips being used.
3) Things than can contribute to fingerprinting include JEDEC IDs in NAND and NOR, SPI or I2C id codes and version, detection of default pin state for pins wired differently.
Maybe Steve Sakoman can suggest some example boards that will be difficult to tell apart at runtime, but it matters?
-Andy
On Wed, Feb 23, 2011 at 04:45:25PM +0000, Andy Green wrote:
Maybe Steve Sakoman can suggest some example boards that will be difficult to tell apart at runtime, but it matters?
Here's one example: the Seagate DockStar is very similar to the Marvell Sheevaplug (same Kirkwood SoC), but has a different amount of SDRAM, different GPIOs, UART, etc. Many of the other systems based on this chip ("plug computers") would be similarly difficult to distinguish at runtime.
On 02/23/2011 06:21 PM, Somebody in the thread at some point said:
On Wed, Feb 23, 2011 at 04:45:25PM +0000, Andy Green wrote:
Maybe Steve Sakoman can suggest some example boards that will be difficult to tell apart at runtime, but it matters?
Here's one example: the Seagate DockStar is very similar to the Marvell Sheevaplug (same Kirkwood SoC), but has a different amount of SDRAM, different GPIOs, UART, etc. Many of the other systems based on this chip ("plug computers") would be similarly difficult to distinguish at runtime.
Well saying that it's very similar, then listing differences like GPIOs that could easily be runtime-detectable, doesn't really pin down whether that's a problem or not.
What does "different amount of UART" mean when it is the "same Kirkwood SoC"?
-Andy
On Thu, Feb 24, 2011 at 07:09:51AM +0000, Andy Green wrote:
Well saying that it's very similar, then listing differences like GPIOs that could easily be runtime-detectable, doesn't really pin down whether that's a problem or not.
See the arch/arm/mach-kirkwood directory in the Linux tree. All the *-setup.c files declare different sets of GPIOs in static structures. If you know a way to "easily" detect them at runtime, that could unify a lot of this code. I'm sure a patch would be welcome.
What does "different amount of UART" mean when it is the "same Kirkwood SoC"?
(Note that I didn't say what you quoted.) But it was a brain slip; I was just remembering a difference in the physical connectors for the serial ports.
On Tue, 22 Feb 2011 22:54:38 +0100, Loïc Minier loic.minier@linaro.org wrote:
On Wed, Feb 23, 2011, Michael Hudson-Doyle wrote:
I ask mostly from a position of ignorance, but is the information in this database related to the information linaro-media-create keeps about each board? If so, could it be shared somehow?
It's completely related and I envisioned we could share it some time ago: http://www.mail-archive.com/linaro-dev@lists.linaro.org/msg00254.html even before linaro-image-tools existed ;-)
But thanks for bringing this up, it's a good thing to put on the goals for the rework: that the data be usage-agnostic and self-contained as to allow reuse in other places.
How would this interact with the proposal for storing some of this information in hwpacks?
Does it imply that hwpacks aren't quite the right place for this? Should they instead just contain an indication of which boards are supported and information about the contents (such as the u-boot path), and the rest of the information lives outside of the hwpack?
Thanks,
James
On Wed, Feb 23, 2011, James Westby wrote:
How would this interact with the proposal for storing some of this information in hwpacks?
This came up; basically linaro-image-tools + hwpacks are one of the many copies of this information which we have around. It will take some time to share this stuff across debian-cd, debian-installer, flash-kernel, linaro-image-tools + hwpacks etc.
Basically, we want all these tools to separate code and data, and we'd like data to be shared. Right now, linaro-image-tools has both code and data, and moving the board-specific data to hwpacks would be a win. Eventually we could generate the hardware pack from this common data, or we might change linaro-image-tools to read the common data from where it lives, but it seems further away.
So there's a long-term/short-term tradeoff: hwpack v2 seems possible in a couple of weeks, common data package with the right semantics to expose ot the world -- might take longer.
Does it imply that hwpacks aren't quite the right place for this? Should they instead just contain an indication of which boards are supported and information about the contents (such as the u-boot path), and the rest of the information lives outside of the hwpack?
I'm not sure; for instance consider the case of data which changes with the distro over time; let's say linaro-image-tools depends on that data and combines the data + 1 hwpack + 1 rootfs to create an image. Then the data changes, and you want to support an older hwpack + rootfs, but the new data is not compatible with them (ttyS2/ttyO2 example). If the data is contained in the hwpack in some way, then it's not an issue anymore. I'm pretty sure there are examples the other way around though, and I don't like having caches of the data which might be stale.
Also, some data should perhaps be shipped by packages like the kernel or by u-boot; for instance a device tree, or the information about the kernel features (for instance maybe ttyO2 is a kernel feature we can infer from the config). Hwpacks seem like a convenient vehicle for grouping these things together in a daily build which you can download and verify easily.
On Wed, 23 Feb 2011 15:57:31 +0100, Loïc Minier loic.minier@linaro.org wrote:
I'm not sure; for instance consider the case of data which changes with the distro over time; let's say linaro-image-tools depends on that data and combines the data + 1 hwpack + 1 rootfs to create an image. Then the data changes, and you want to support an older hwpack + rootfs, but the new data is not compatible with them (ttyS2/ttyO2 example). If the data is contained in the hwpack in some way, then it's not an issue anymore. I'm pretty sure there are examples the other way around though, and I don't like having caches of the data which might be stale.
So longer term we should be thinking of having the hwpack generation read some information from the common files corresponding to the versions it is building for (e.g. grab the package containing the common files and look for the one with a specific name and take some info from there).
That would allow us to share the data, while not worrying about having different versions of that data at hwpack-install time.
I still think we should consider cases where the information refers to the rootfs when we come to do this, and not include that in the hwpack, instead reading it from the rootfs we are installing the hwpack in to.
Thanks,
James
On Wed, Feb 23, 2011, James Westby wrote:
So longer term we should be thinking of having the hwpack generation read some information from the common files corresponding to the versions it is building for (e.g. grab the package containing the common files and look for the one with a specific name and take some info from there).
That would allow us to share the data, while not worrying about having different versions of that data at hwpack-install time.
Yup
I still think we should consider cases where the information refers to the rootfs when we come to do this, and not include that in the hwpack, instead reading it from the rootfs we are installing the hwpack in to.
That's sensible; there is much less stuff relevant in the rootfs, but maybe pieces of kernel cmdline (cmdline would be built from rootfs part + hwpack part + linaro-image-tools computer part + user specified part).
Did you have something specific in mind?
On Wed, 23 Feb 2011 18:32:29 +0100, Loïc Minier loic.minier@linaro.org wrote:
Did you have something specific in mind?
Nope.
Thanks,
James
On Wed, 23 Feb 2011 15:57:31 +0100, Loïc Minier loic.minier@linaro.org wrote:
On Wed, Feb 23, 2011, James Westby wrote:
How would this interact with the proposal for storing some of this information in hwpacks?
This came up; basically linaro-image-tools + hwpacks are one of the many copies of this information which we have around. It will take some time to share this stuff across debian-cd, debian-installer, flash-kernel, linaro-image-tools + hwpacks etc.
Basically, we want all these tools to separate code and data, and we'd like data to be shared. Right now, linaro-image-tools has both code and data, and moving the board-specific data to hwpacks would be a win. Eventually we could generate the hardware pack from this common data, or we might change linaro-image-tools to read the common data from where it lives, but it seems further away.
One of the issues here I guess is: do we know what all the data required is? My impression (from a step removed, admittedly) is that adding support for new boards to l-m-c still tends to require code changes and not just data changes. Hopefully this will stabilize over time though.
Cheers, mwh
On Thu, Feb 24, 2011, Michael Hudson-Doyle wrote:
One of the issues here I guess is: do we know what all the data required is? My impression (from a step removed, admittedly) is that adding support for new boards to l-m-c still tends to require code changes and not just data changes. Hopefully this will stabilize over time though.
That's fair; I don't think we can be future proof to whatever the world is going to come up with, but we can try to be good at adapting to the type of changes which we've seen so far ;-)
If we end up doing 90% of the changes in the data and 10% in the code, I still call that a win over doing 100% of the changes in the code+data piece!
-
Amit Kucheria -
Andy Green -
Eric Cooper -
James Westby -
Loïc Minier -
Michael Hudson-Doyle