I've been working on adding support for the m57sli to buildrom. I'm almost there - particularly I've got filo and linux-as-a-bootloader (lab) going. Lab has a stripped down 2.6.22.2 kernel and a tiny initrd in a 1MB rom chip (25K to spare :), configured to kexec another kernel from disk. I need to do a bit more testing but I intend to have filo and lab fully functional, and hopefully I'll also have time to look at other payloads.
Now; before I post my patches to the list for review, I'd like to know what the current thinking is on the future of buildrom.
There are a couple of issues with buildrom as it stands today:
a) it's v2 only b) there is no standardized way to use a different initrd 'skeleton' for a specific board c) there is no standardized way to have different LinuxBIOS Config.lb files for a particular board, based on the payload
It looks like the kconfig setup for v3 will take over much (everything?) of what buildrom does now. If that is true, I think I might just add a few patches to fix b) and c) before I submit the m57sli patches.
Thoughts? Does that sound reasonable?
Thanks, Ward.
On 9/2/07, Ward Vandewege ward@gnu.org wrote:
Now; before I post my patches to the list for review, I'd like to know what the current thinking is on the future of buildrom.
it's pretty key to our future as far as I am concerned!
There are a couple of issues with buildrom as it stands today:
a) it's v2 only
we can fix that.
b) there is no standardized way to use a different initrd 'skeleton' for a specific board
Shouldn't we be moving to initramfs? If we do, will that make life easier?
c) there is no standardized way to have different LinuxBIOS Config.lb files for a particular board, based on the payload
that we will need to fix, again, this will be easier in V3, I hope ... so is the answer to get v3 working on hardware and let it solve this problem?
It looks like the kconfig setup for v3 will take over much (everything?) of what buildrom does now. If that is true, I think I might just add a few patches to fix b) and c) before I submit the m57sli patches.
I don't think the v3 kconfig is going to take over completely; we don't want to put busybox and kernel builds into v3. So, let's try to keep buildrom working.
This is great stuff, thanks for your work!
ron
On Sun, Sep 02, 2007 at 06:51:14PM -0700, ron minnich wrote:
On 9/2/07, Ward Vandewege ward@gnu.org wrote:
Now; before I post my patches to the list for review, I'd like to know what the current thinking is on the future of buildrom.
it's pretty key to our future as far as I am concerned!
ACK.
b) there is no standardized way to use a different initrd 'skeleton' for a specific board
Shouldn't we be moving to initramfs? If we do, will that make life easier?
Moving? The user should have the choice whether to use initramfs or not, IMO.
It looks like the kconfig setup for v3 will take over much (everything?) of what buildrom does now. If that is true, I think I might just add a few patches to fix b) and c) before I submit the m57sli patches.
I don't think the v3 kconfig is going to take over completely; we don't want to put busybox and kernel builds into v3. So, let's try to keep buildrom working.
I'm not so sure. Maybe it actually _is_ a good idea to integrate (parts of) buildrom in the v3 build process? It would sure make the "user experience" better. The question is how much work this will be. I guess we'd want to change quite a lot of buildrom's inner workings in that case (and v3's for that matter). If so, we should keep buildrom as a separate project in v2, but integrate it completely in v3.
Comments?
Uwe.
2007/9/16, Uwe Hermann uwe@hermann-uwe.de:
I'm not so sure. Maybe it actually _is_ a good idea to integrate (parts of) buildrom in the v3 build process? It would sure make the "user experience" better. The question is how much work this will be. I guess we'd want to change quite a lot of buildrom's inner workings in that case (and v3's for that matter). If so, we should keep buildrom as a separate project in v2, but integrate it completely in v3.
Comments?
I think this is a good idea. Currently the most hard work is not to compile LinuxBIOS, but it is compile and create an rootfs. I used buildroot to create the LBdistro (my dirt hack) and I think buildroot can be integrated as an option to compile a LAB (Linux As Bootloader but we can refer it also as Linux As Bios).
I think it can be checkbox option to call the buildroot and compile linux and all programs.
Uwe.
cheers,
Alan
On 16/09/07 15:08 -0300, Alan Carvalho de Assis wrote:
2007/9/16, Uwe Hermann uwe@hermann-uwe.de:
I'm not so sure. Maybe it actually _is_ a good idea to integrate (parts of) buildrom in the v3 build process? It would sure make the "user experience" better. The question is how much work this will be. I guess we'd want to change quite a lot of buildrom's inner workings in that case (and v3's for that matter). If so, we should keep buildrom as a separate project in v2, but integrate it completely in v3.
Comments?
I think this is a good idea. Currently the most hard work is not to compile LinuxBIOS, but it is compile and create an rootfs. I used buildroot to create the LBdistro (my dirt hack) and I think buildroot can be integrated as an option to compile a LAB (Linux As Bootloader but we can refer it also as Linux As Bios).
I do agree that we should figure out a way to transition building the LAB and initramfs images to buildroot (which is better suited for the process anyway).
I think it can be checkbox option to call the buildroot and compile linux and all programs.
I am a little worried if the multiple nested makefiles would be a strain on older machines. But we can give it a shot and see what happens. Do you have a buildroot default config we can use as an example?
Jordan
On Sun, Sep 16, 2007 at 04:53:54PM +0200, Uwe Hermann wrote:
we don't want to put busybox and kernel builds into v3.
I'm not so sure. Maybe it actually _is_ a good idea to integrate (parts of) buildrom in the v3 build process?
There's still a point in keeping the LB/v3 product.
But there's also a point in making a distinct product, more like a full-featured toolbox. Sounds like buildrom, no?
I think buildrom is good and an important product too.
I do think the two should be integrated - but the idea is to consider buildrom a solution and LB a technology if I understood Ron correctly. I like that thinking.
So the integration boils down to making it very natural to do whatever is neccessary for v3 as part of using buildrom to build a rom image.
//Peter
On 16/09/07 16:53 +0200, Uwe Hermann wrote:
I'm not so sure. Maybe it actually _is_ a good idea to integrate (parts of) buildrom in the v3 build process? It would sure make the "user experience" better. The question is how much work this will be. I guess we'd want to change quite a lot of buildrom's inner workings in that case (and v3's for that matter). If so, we should keep buildrom as a separate project in v2, but integrate it completely in v3.
I can see both sides of the argument. On one side, having a completely separate entity allows us to make changes to the build system and the payloads without forcing somebody to accept a new version of the LinuxBIOS code. It also allows us to choose different revisions for different platforms based on the stability of said platform. This to me is important for new users.
On the other hand, multiple steps are confusing, though ideally, if buildrom was good, you shouldn't be aware that there are multiple steps, it should be pretty smooth. It actually gets better with v3, since we no longer have to build the payload into the v2 process, we can build the payload and the ROM in separate and independent steps, and put them together with LAR later.
The thing about buildrom that I like the best, I think, is that we can script in all the knowledge we need for each individual platform (e.g. wgetting VSA or a video BIOS for a particular platform); this is something that I think would end up being pretty klunky within LinuxBIOS itself, and prone to error, especially if we tried to get generic with it.
I think what I need to do is polish up my v3 patches for buildrom and get them out there, so that we can evaluate apples to apples and see what needs to be done.
Jordan
On 02/09/07 15:39 -0400, Ward Vandewege wrote:
I've been working on adding support for the m57sli to buildrom. I'm almost there - particularly I've got filo and linux-as-a-bootloader (lab) going. Lab has a stripped down 2.6.22.2 kernel and a tiny initrd in a 1MB rom chip (25K to spare :), configured to kexec another kernel from disk. I need to do a bit more testing but I intend to have filo and lab fully functional, and hopefully I'll also have time to look at other payloads.
Now; before I post my patches to the list for review, I'd like to know what the current thinking is on the future of buildrom.
There are a couple of issues with buildrom as it stands today:
a) it's v2 only
We are working on this - by the time something real boots with V3, so will buildrom.. :)
b) there is no standardized way to use a different initrd 'skeleton' for a specific board
No, there really isn't. The LAB stuff has really fallen into disrepair since the fork from OLPC. If you are interested in beating it into shape, then please, by all means.
c) there is no standardized way to have different LinuxBIOS Config.lb files for a particular board, based on the payload
Not sure what you mean by this. Do you have an example?
Jordan
Ward Vandewege schrieb:
Now; before I post my patches to the list for review, I'd like to know what the current thinking is on the future of buildrom.
There are a couple of issues with buildrom as it stands today:
a) it's v2 only b) there is no standardized way to use a different initrd 'skeleton' for a specific board c) there is no standardized way to have different LinuxBIOS Config.lb files for a particular board, based on the payload
Thoughts? Does that sound reasonable?
my view: whatever gets us closer to a feasible live-Linux-CDROM that is bootable on GA M57-SLI as well as ASUS A8N-E (the desktop flagships 30 - 80€ in cost) and has binaries to flash on those targets is well supportable. we need binaries for early adopters to download and flash into their mobos and save that in wiki. --Q
-- New Mexico: it's not new, and it isn't it Mexico. The Fed: "There is nothing federal about the federal reserve system, and there are no reserves." (Prof. Bill Still)
Also, can someone put instructions on where-to-buy on the wiki for these boards and systems?
thanks
ron
On Tue, Sep 04, 2007 at 10:16:17AM -0700, ron minnich wrote:
Also, can someone put instructions on where-to-buy on the wiki for these boards and systems?
Some are listed here, but the prices and availability keeps changing pretty quickly, so I'm not sure how useful this is.
Uwe.
-
Alan Carvalho de Assis -
Jordan Crouse -
Peter Stuge -
Quux -
ron minnich -
Uwe Hermann -
Ward Vandewege