coreboot June 2004

coreboot@coreboot.org

43 participants
102 discussions

Re: [PROPOSAL] extended payload handling
by Stefan Reinauer 09 Jun '04

09 Jun '04

* Mathieu Deschamps <mdeschamps(a)mangrove-systems.com> [040608 16:20]: > > I don't exactly get the problem. Etherboot would probably be the end of > > the in-rom payload chain, since it does not return from execution but > > pass control to Linux, which is not stored in ROM in the above scenario. > Ok we agree, I try to be clearer, i redo: > > you said in above LinuxBIOS should allow payload chains, ie. executing > multiple payloads one after the other. > Isn't it already was it can with the chain we're describing in here ? > Or are you considering that it is not since it passes control up to a > certain constant point ? Not really. It works because the payload you use is a bootloader. This is a very hard restriction, as PCI resource allocation, or testbios are no bootloaders, and thus do not need and should really not have an ELF loader like LinuxBIOS itself has. Bootloaders are always the end of the chain. > > But possibly ADLO could be moved to ROM before Etherboot is > > started. > > Really ? but if ADLO, as you underlined it, is out-rom is it > for a good reason : a lack of inrom space. So logically it must be > filled to the top and got no bytes left The space left depends really very much on the flash device you use. Optimistically, LinuxBIOS itself, without PCI resource allocation should only eat up around 32k with some fiddling. Compared to 256 or 512kbyte flash devices there is plenty of room for additions. If not ADLO then something else. I am not arguing that ADLO should go to rom or should not. What I am trying to say is, that * if we decide, that having FILO inside of LinuxBIOS is a break in design, we should be consequent and split everything but DRAM init and ELF loader out, including * if there is enough space in rom, any payload should be able to receive and give back control. The payload view of things is nice, but either do it right or have a way around it if needed. * payloads should be able to leave information in the LinuxBIOS table, so that following payloads don't have to do the same work over and over. I see a certain point in not having function callbacks, even if I think it's a dubious one in a full open source environment, but I am not going to argue about this. It's not really needed, EOD. > How could we move it to ROM in such condition ? Oh I catch it : > LinuxBios does return from execution nor Etherboot, that IS space > on to write is it what you mean ? My proposal does not care for anything after code is loaded from IDE. It should not, since, as Eric pointed out, this is bloat. And it is, since either one loads a kernel from a raw device, which is not solid enough for productive use, or one has to include filesystems and whatever. This code belongs out of the LinuxBIOS core, as does PCI resource allocation. Stefan

2 2

The 'help me!' form on http://www.linuxbios.org/help/index.html is broken
by Erik Smit 08 Jun '04

08 Jun '04

Hi People, Just like the subject says: the form at http://www.linuxbios.org/help/index.html gives a really cute 404. Should I therefore mail my request for help to the mailing list or should I wait until the form gets back working? Regards, Erik Smit

6 27

答复: [PROPOSAL] extended payload handling
by YhLu 08 Jun '04

08 Jun '04

Can you explain deailed about the difference between uboot and Linuxbios? YH -----邮件原件----- 发件人: Frank [mailto:frannk_m1@yahoo.com] 发送时间: 2004年6月8日 10:58 收件人: Richard Smith 抄送: Greg Watson; Stefan Reinauer; LinuxBIOS 主题: Re: [PROPOSAL] extended payload handling You missed the point as well! I was not complaining or whining as you put it about not having support for the PPC. I was complaining about the lack of support for new users to use it for the X86 platform. Leave the "other" processor alone and focus on what you do best, the X86 platform. As far as I'm concerned you will _never_ have as much support for the PPC as u-boot does and u-boot will never have the support for the X86 as LinuxBios does. But it speaks volumes about the readability of the code when someone switches directions just so they don't have to go thru the pain of trying understand your code base. I am not a novice, I have been doing this for over 20 years. I have ported or written bootloaders for just about every platform out there. The trick is to use the bootloader for a particular processor that has the most traction for a particular architecture. --- Richard Smith <rsmith(a)bitworks.com> wrote: > Frank wrote: > > > Hopefully by the time we decide to do cost reduced version, > > LinuxBios will be usable for the masses and not just for an > > elite group of people who assume everybody else uses the x86 > for > > everyday use.:-( > > I think the above is a little harsh. > > As long as I've been on this list LinuxBIOS has always been > about > getting dirty with the code and making it to do what you need > it to do > for your specific applicaiton. Along the way many good people > have put > a _lot_ of effort into trying to take all these individual > needs and > produce some sort of API that could be re-useable by the next > person. > But at this level that's really hard. > > We've always known the level of documentation sucks. If you > ask we will > tell you it sucks. Just none of the people who really know > the core > have time to pull off and re-hash it. > > From what it started with and considering the odds stacked > against it > LB has make _huge_ advancements. It x86 specific becuse > that's what all > the core developers use. For LinuxBios to make the jump to > multi-platform it will take an investment of developers such > as yourself > getting dirty in the core and makeing it happen. I don't > think any of > the developers just "assume" the world uses x86. x86 just > happens to be > most of what thier world is right now. > > I understand your time requirements prevented you from jumping > in on > this project but until _someone_ takes the initiative and > brings LB > forward on non-x86 platforms it won't ever meet your "masses" > criteria. > > So I'd suggest that if you really wanted LB available with all > the extra > features for your platform you should revise your tone a bit. > Whiners > don't get the best of support from coders. > > __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

2 1

答复: [COMMIT] romcc 0.63 and some fixes...
by YhLu 08 Jun '04

08 Jun '04

I wonder it get bigger. Just change the print_debug to printo_debug. Because call printo_debug is bigger than inline print_debug, or the __attirbute__ (noinline) doesn't take effective.?? YH -----邮件原件----- 发件人: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] 发送时间: 2004年6月8日 13:39 收件人: YhLu 抄送: LinuxBIOS 主题: Re: [COMMIT] romcc 0.63 and some fixes... YhLu <YhLu(a)tyan.com> writes: > linuxbios image is 71069 bytes; only 65536 allowed > > after change some print_debug to printo_debug, it gets bigger. Before that > it about 68000. Ouch. I guess it must be some of the missed opportunities for optimization. Or the increase in moving values around in registers. So in theory it works, but we are having a hard time applying it :( Do you have any significant size regression with just switching to the new romcc. Eric

2 1

re: [COMMIT] romcc 0.63 and some fixes...
by YhLu 08 Jun '04

08 Jun '04

linuxbios image is 71069 bytes; only 65536 allowed after change some print_debug to printo_debug, it gets bigger. Before that it about 68000. Regards YH -----邮件原件----- 发件人: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] 发送时间: 2004年6月7日 14:19 收件人: YhLu 抄送: LinuxBIOS 主题: Re: 答复: 答复: [COMMIT] romcc 0.63 and some fixes... YhLu <YhLu(a)tyan.com> writes: > I see. The code is getting larger. Not quite. There is less generated code, but it requires extra registers to hold the return addresses so the register pressure is higher. Some of that extra register pressure may be artificial and go away when this bug is fixed. Some of it may result from poor choices of the register allocator, and may be remedied by enhancing the register allocator. There is hope of remedies as the kind of code presented to the register allocator is very different when code is not inlined. > Also the reboot in OS can not work. Hmm. At least with reboot=hard that should work on the Opterons. I have not tested that lately though. Eric

2 1

答复: [PROPOSAL] extended payload handling
by YhLu 08 Jun '04

08 Jun '04

Maybe someone can port the Etherboot to powerpc. And it should be some easy. Regards YH -----邮件原件----- 发件人: Frank [mailto:frannk_m1@yahoo.com] 发送时间: 2004年6月8日 10:00 收件人: Greg Watson; Stefan Reinauer 抄送: LinuxBIOS 主题: Re: [PROPOSAL] extended payload handling Finally, someone has recognized the lack of support with LinuxBios. About 6 months ago we decide to do an x86 based project but abandoned it because of the lack of support for this bootloader. The code is disorganized and in disarray as far as I'm concerend. We were on a tight schedule and didn't have the luxury of spending a lot of time trying to understand the code layout. This was due in part to the lack of badly needed documentation and code organization. We decided to base our design on a powerpc and go with u-boot. Hopefully by the time we decide to do cost reduced version, LinuxBios will be usable for the masses and not just for an elite group of people who assume everybody else uses the x86 for everyday use.:-( --- Greg Watson <gwatson(a)lanl.gov> wrote: > > On Jun 8, 2004, at 7:59 AM, Stefan Reinauer wrote: > > > * Greg Watson <gwatson(a)lanl.gov> [040608 15:22]: > >> I think this is a reasonable idea, particularly your > suggestion of > >> making linuxbios more modular. One of my main beefs with > the payload > >> strategy is that each payload has to provide it's own set > of, > >> potentially buggy, driver code. If we have 5 payloads then > we have 5 > >> sets of drivers that all do the same thing slightly > differently. If > >> the > >> drivers were modular enough so that a payload could call > them > >> directly, > >> then this would go a long way to addressing these concerns. > > > > As far as I can tell the only drivers involved would be > output drivers, > > ie. video output and serial output. There the extensible > LinuxBIOS > > table > > could come into play. The video driver could store a pointer > to the > > framebuffer, the resolution and maybe even a font, to save > duplicates. > > Serial is only a kilobyte or so of a driver i think. > > > > Have I forgotten something? > > > > PCI device code and resource information should be available > for > payloads to use. A payload should not have to re-probe for > devices on > the PCI bus. > > Greg > > _______________________________________________ > Linuxbios mailing list > Linuxbios(a)clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

1 0

Bootloaders and LinuxBIOS
by ebiederman＠lnxi.com 08 Jun '04

08 Jun '04

As the freebiosv1 tree grew and developed we had a lot of disagreement about bootloaders. What should linuxbios do in condition X. It was clear that there was no way that in the linuxbios tree itself we could satisfy all of the developers. You can see remnants of this in the freebios1 tree in src/lib/linuxbiosmain.c Coming into this confusion I proposed a truce, that would give us greater flexibility and allow a single LinuxBIOS source tree for everyone. That was to have a really stupid bootloader in LinuxBIOS that was smart enough to load a real bootloader. That is where elfboot comes from. To prove my concept I ported etherboot to run under LinuxBIOS as that was the only bootloader I could find that actually had real hardware drivers. In this scenario the fact that etherboot well with my style of booting was no longer a threat because people were free to use their own code. Etherboot was also choosen because of it's strong core team of maintainers and you can all see the results of that decision today. Out of this concept we had additional bootloaders written or ported: ADLO, FILO, OpenBIOS, baremetal, linux kernel, etc. So from everything I can see this concept has been a success. I have seen no complaints. We don't have more because it is not the easiest thing to write standalone code to the bare metal. But this is something time and starting to catch up on our LinuxBIOS ports has been overcoming. One of the large reasons I was a great proponet of the simple/stupid bootloader in LinuxBIOS to load a real one is that draws a line around what functionality LinuxBIOS shall provide. Anything over that line is code bloat. Several months ago as I was involved in other things Yhlu noted that FILO had been added to LinuxBIOS without a word. The way he described it I thought it was as a driver to elfboot. I expressed my concerns at that time, but I really have not had time to do anything. And if it was a driver it was seriously pushing the line I had drawn against feature bloat, and really coming close to starting another bootloader feature war but it was perhaps ok. Later I finally had time to start syncing my code with the main LinuxBIOS and I saw what that code actually was, and I was shocked. This code had crossed the line, it had broken the truce, it was feature bloat. Not to talk about how useless a disk based bootloader is without a configuration file. From that moment on I have not seen a reasonable solution besides deleting that code from LinuxBIOS. Last time we had this conversation 2 problems were mentioned that this code solves. 1) People have a hard time setting up an external payload. 2) There are not any bootloaders for the ppc that run under LinuxBIOS. To the problem of setting up an external payload I propose we can include FILO into the tree like baremetal and simply make it the default payload. If you don't change anything it will get built. That solves the problem without breaking the design. To the problem of there not being any bootloaders for the ppc that run under LinuxBIOS. I respond that one of the x86 based bootloaders would not be hard to port, or better yet we can just use a kernel with kexec built in. Although I would strongly be with the amount of embedded activity that happens with the ppc if none of the native ppc bootloaders could not be easily adopted. In addition I have seen noone except the guys at LANL who are even interested in the built in FILO. I have a few additional technical objections as well. Just like when someone tried to include etherboot the code in the LinuxBIOS tree has languished, and is much less capable a solution. Having to support bootloaders places an additional burden upon the LinuxBIOS code that must be considered when the code must be refactored or cleaned up. And we have not even succeed in a sufficiently clean and stable API that we are willing to freeze the core interfaces and make stable releases from the LinuxBIOS tree, only adding new ports or extensions to the existing API that cannot possibly break old ports. So does someone have a reason to keep the built-in FILO besides being lazy slobs who want something-for-nothing and are not willing to put in the work to make production quality solutions? Eric

2 1

Re: Tool Versions
by ebiederman＠lnxi.com 08 Jun '04

08 Jun '04

"Jay Miller" <jmiller(a)actuality-systems.com> writes: > I'm still having trouble building etherboot .zelf images. It appears > that the file size in the elf header is corrupt, and someone here > suggested that I may have a buggy version of Perl. Here are the > versions in my toolchain: > > Red Hat 9.0 box with: > > Gcc 3.3.3 > Python 2.2.2 > Perl 5.8.4 (latest & greatest) > Binutils-2.15 > > Any thoughts? What is lang set to? If it is not a byte encoding that is likely the issue. I don't quite know why that makes a difference but it seems to. Eric

1 0

Re: Intel Chipset support in V2
by YhLu 07 Jun '04

07 Jun '04

Which chipsets are you working on? Regards YH -----邮件原件----- 发件人: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] 发送时间: 2004年6月7日 13:22 收件人: YhLu 抄送: ron minnich; LinuxBIOS 主题: Re: Intel Chipset support in V2 YhLu <YhLu(a)tyan.com> writes: > Ron, > > Any plan to move the intel chipset support from V1 to V2? I mean E750x and > 82801xx. Right now implementing the newer intel chipsets in v2 is taking with the code I am working on. Eric

2 1

答复: 答复: [COMMIT] romcc 0.63 and some fixes...
by YhLu 07 Jun '04

07 Jun '04

I see. The code is getting larger. Also the reboot in OS can not work. Regards YH -----邮件原件----- 发件人: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] 发送时间: 2004年6月7日 13:29 收件人: YhLu; LinuxBIOS 主题: Re: 答复: [COMMIT] romcc 0.63 and some fixes... ebiederman(a)lnxi.com (Eric W. Biederman) writes: > YhLu <YhLu(a)tyan.com> writes: > > > Just sent out the core. > > Thanks. I have done the basic tracking. And it is clearly a code > bug. With the bug fix in place I am seeing what looks like another bug. For the moment you can avoid this by removing the printo_debug from generate_row. That still runs out of registers but the compiler does not crash. I would dearly love to see a version of this code that works when you do broad changes, like you did. At the moment the code does work well enough that if you change a couple of functions at a time, you get some benefit. Eric

2 1

← Newer
1
2
3
4
5
6
7
8
9
10
11
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot June 2004