Eric, Under 4G RAM linusbios_tables occupy 0x500-0xae0, cmos_util can find option_table even after rebooting. Under 6G RAM linuxbios_tables occupy 0x500-0xaf4, cmos_util can find option_table after power on but can not find it after rebooting.
The only difference should be that rebooting don't execute auto.c again.
Any advise.
Regards
Yingahi Lu
-----邮件原件----- 发件人: YhLu 发送时间: 2003年8月6日 17:11 收件人: ron minnich 抄送: 'ebiederman@lnxi.com'; 'Stefan Reinauer'; 'linuxbios@clustermatic.org' 主题: 答复: S2880
Ron,
I have verfied that if I disable the XIP... in old config tool, the image produced will make the option table not accessiable after reboot too.
Regards
Yinghai Lu
-----邮件原件----- 发件人: ron minnich [mailto:rminnich@lanl.gov] 发送时间: 2003年8月6日 15:51 收件人: YhLu 抄送: 'ebiederman@lnxi.com'; 'Stefan Reinauer'; 'linuxbios@clustermatic.org' 主题: Re: S2880
I will try to email you my latest tree, Stefan put them in last night.
ron _______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
I was looking at the 2.6.0-test2 kernel tree today and saw new menu choices under
"General Setup -> Remove Kernel Features (for embedded systems)" which looks like the beginings of an effort to strip out large though somewhat optional features. For instance, the current choices include:
Load all symbols for kernel debugging/ksysmoops Enable futex support Enable eventpoll support Anticipatory I/O Schedualer Deadline I/O Schedualer
It seems like pretty good news for the linux kernel as a bootloader route that effots are being made to get the kernel smaller when necessary.
- Adam Agnew
On Wed, 6 Aug 2003, Adam Agnew wrote:
It seems like pretty good news for the linux kernel as a bootloader route that effots are being made to get the kernel smaller when necessary.
good, because long term, that is still a preferred choice for me.
ron
ron minnich rminnich@lanl.gov writes:
On Wed, 6 Aug 2003, Adam Agnew wrote:
It seems like pretty good news for the linux kernel as a bootloader route that effots are being made to get the kernel smaller when necessary.
good, because long term, that is still a preferred choice for me.
Me as well. I think I want to see if I can get a 2.6.0 kernel to run on x86 without an mmu. Potentially that could be very nice size reduction wise.
And to really get it useful I need to put in the extra work to get kexec into the kernel. I'm almost there, but I am currently distracted with freebios2 and the Opteron port.
Now that there is a good general purpose solution to small 256KB ROMS. I don't feel bad about pursue a solution that is only useful for 512KB ROMS and above. A very compelling reason is that hardware is getting increasingly interesting, and needs more drivers etc.
Though given how things are going I am half tempted to do things like write a mini TCP stack that is closer to 10K than 100K.
Eric
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I was looking at the 2.6.0-test2 kernel tree today and saw new menu choices under
"General Setup -> Remove Kernel Features (for embedded systems)" which looks like the beginings of an effort to strip out large though somewhat optional features. For instance, the current choices include:
Ooh, I wish that existed in the 2.4.x tree... I am working on a 'linux as bootldr' project for ARM (iPAQ specifically). Presently, our zImages are at 480k, and we need to get them down to sub-256k (while still adding more features!) Out of curiousity, how small have you guys managed to build zImages for LinuxBIOS?
~joshua
- -- Joshua Wise | www.joshuawise.com GPG Key | 0xEA80E0B3 Quote | <lilo> I akilled *@* by mistake
On Wed, 6 Aug 2003, Joshua Wise wrote:
Ooh, I wish that existed in the 2.4.x tree... I am working on a 'linux as bootldr' project for ARM (iPAQ specifically). Presently, our zImages are at 480k, and we need to get them down to sub-256k (while still adding more features!) Out of curiousity, how small have you guys managed to build zImages for LinuxBIOS?
up until about 2.4.13, putting a kernel, small initrd, and linuxbios in 512KB was not that hard. Then it just balloned.
ron
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
up until about 2.4.13, putting a kernel, small initrd, and linuxbios in 512KB was not that hard. Then it just balloned.
Ouch. Was there specific bloat that happened after 2.4.13? After doing a preliminary look over the kernel code, much of the bloat seems to be in the filesystem code...
BTW, if you guys don't have serial console stuff yet (IIRC last I checked, there was no CLI for linuxbios - things may have changed since then, I've been rather out of the loop recently), we're working on extensible CLI stuff for ARM Linux As Bootloader that would probably be portable to LinuxBIOS.
/me wishes that the flash block that we put the bootloader in was bigger :(
~jw, who is very sleepy after having spent the previous night hacking till 0330, and hence probably won't respond to any more email tonight.
- -- Joshua Wise | www.joshuawise.com GPG Key | 0xEA80E0B3 Quote | <lilo> I akilled *@* by mistake
On Thu, 7 Aug 2003, Joshua Wise wrote:
Ouch. Was there specific bloat that happened after 2.4.13? After doing a preliminary look over the kernel code, much of the bloat seems to be in the filesystem code...
the dentry cache was not a cheap date. But the bloat seems to happen everywhere, which is why it's so hard to slice out.
BTW, if you guys don't have serial console stuff yet (IIRC last I checked, there was no CLI for linuxbios - things may have changed since then, I've been rather out of the loop recently), we're working on extensible CLI stuff for ARM Linux As Bootloader that would probably be portable to LinuxBIOS.
I'm interested. I assume this CLI is running as part of linux? Or is it the pre-linux stuff?
This looks like a good area for cooperation.
thanks
ron
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I'm interested. I assume this CLI is running as part of linux? Or is it the pre-linux stuff?
Presently, the CLI is running as part of the kernel - not as a seperate userland application (the reasoning being that we can use the kernel's driver architecture - I have created a drivers/bootldr subdirectory for things like that. for more, check out handhelds.org CVS - kernel 2.4, not 25 or 26.) more info tomorrow - until then, sleep! :)
This looks like a good area for cooperation.
yep, look forward to hearing from you!
thanks
ron
~j
- -- Joshua Wise | www.joshuawise.com GPG Key | 0xEA80E0B3 Quote | <lilo> I akilled *@* by mistake
On Thu, 7 Aug 2003, Joshua Wise wrote:
Presently, the CLI is running as part of the kernel - not as a seperate userland application (the reasoning being that we can use the kernel's driver architecture - I have created a drivers/bootldr subdirectory for things like that. for more, check out handhelds.org CVS - kernel 2.4, not 25 or 26.) more info tomorrow - until then, sleep! :)
OK, I am very interested in this. I'll take a look.
ron
I just built 2.6.0-test2 in 441kB with one IDE DMA driver and ext3. I have yet to try LinuxBIOS (waiting for some BIOS Saviors!), but it looks like I will be able to do quite a lot with my Tyan Tiger MPX (S2466N-4M) if I upgrade the BIOS chip to an 8mbit part.
Doing anything useful with the 4mbit chip may still be a lost cause, but it does look like 2.6.0 has lost some bloat. Perhaps if some of us contribute more "embedded fat-trimming" patches we can make linuxbios+linux+initrd fit easily in a half megabyte.
Jeff
Greetings,
It might be useful to switch to ext2 so the journaling code can be dropped. In general, a bootloader mostly needs read only access anyway.
Might also be interesting to see how much network/socket code can be chopped out of a kernel/bootloader.
G'day, sjames
On Thu, 7 Aug 2003, Jeff Noxon wrote:
I just built 2.6.0-test2 in 441kB with one IDE DMA driver and ext3. I have yet to try LinuxBIOS (waiting for some BIOS Saviors!), but it looks like I will be able to do quite a lot with my Tyan Tiger MPX (S2466N-4M) if I upgrade the BIOS chip to an 8mbit part.
Doing anything useful with the 4mbit chip may still be a lost cause, but it does look like 2.6.0 has lost some bloat. Perhaps if some of us contribute more "embedded fat-trimming" patches we can make linuxbios+linux+initrd fit easily in a half megabyte.
Jeff _______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Adam Agnew agnew@cs.umd.edu writes:
I was looking at the 2.6.0-test2 kernel tree today and saw new menu choices under
"General Setup -> Remove Kernel Features (for embedded systems)" which looks like the beginings of an effort to strip out large though somewhat optional features. For instance, the current choices include:
Load all symbols for kernel debugging/ksysmoops Enable futex support Enable eventpoll support Anticipatory I/O Schedualer Deadline I/O Schedualer
It seems like pretty good news for the linux kernel as a bootloader route that effots are being made to get the kernel smaller when necessary.
Currently this is running about 60K-100K larger than 2.4.x even with everything disabled. But patches to shrink this are welcome.
Eric
YhLu YhLu@tyan.com writes:
Eric, Under 4G RAM linusbios_tables occupy 0x500-0xae0, cmos_util can find option_table even after rebooting. Under 6G RAM linuxbios_tables occupy 0x500-0xaf4, cmos_util can find option_table after power on but can not find it after rebooting.
The only difference should be that rebooting don't execute auto.c again.
I am not really certain what is going on, but it doesn't sound good. Normally I just reset the board and that is probably the right solution. I am still struggling to get the new config tool usable, so I am a bit distracted.
We should be rewriting the table even during a reboot. So the fact that this doesn't work indicates there is some kind of problem. What I don't know.
I can positively report that I have seen this. If I don't start pushing my reset code into the tree in the next couple of days please bug me.
Eric
-
Adam Agnew -
ebiederman＠lnxi.com -
Jeff Noxon -
Joshua Wise -
ron minnich -
Ronald G. Minnich
-
steven james -
YhLu