Fridel Fainshtein wrote:
I compared to etherboot and it works there. In Etherboot there are 2 set of bswap functions:
- little
- big
In FILO there is only one bswap set
Which one to choose?
no idea. but please cc the list with stuff like this so someone else can help.
-corey
On Nov 15, 2007 8:41 AM, Corey Osgood corey.osgood@gmail.com wrote:
Fridel Fainshtein wrote:
Hello all,
It seams that the USB code was taken from the previous version of FILO but never have been tested.
Since noone else piped up, here's what I've figured out: Older versions of FILO (<0.5) don't have any USB support. The original author(s) of FILO's USB stack were from LinuxLabs. I don't know what the story is, but it was probably written under contract for someone (in a case where it did work), and they simply don't have the time to provide support for it. I've heard that it was originally merged from Etherboot, where it may have worked, but I can't confirm that. In any case, it doesn't seem to have been really touched since the initial import to the svn repository, according to the svn logs.
Some symptoms are
malloc_diag: alloc: 4208 bytes (8 blocks), free: 61320 bytes (1 blocks) malloc_check: sizes mismatch: 0xa1 vs 0x0 at 00132670 2) dma_to_td: can not find td
Is this using an OHCI controller? I've tried several times with UHCI and seen a different error:
malloc_diag: alloc: xxxx bytes ([x] blocks), free: xxxx bytes (2 blocks) init_framelist: frame_list is at 13[n]000 dump_link: frame_list_link: addr: 001233[n+1]0 dump_link: frame_list_link: raw addr: 1bfd40[n*2]0 dump_link: frame_list_link: terminate: 0 dump_link: frame_list_link: queue: 1 dump_link: frame_list_link: depth: 0 (repeated half a dozen or so times) Out of heap space
Trying to debug it, I discovered the following piece of code:
void *allot2(size_t size, unsigned int alignment) { void *addr; unsigned long addrval; addr=malloc(2*size);
addrval=(unsigned long)addr; addrval+=alignment+1; // 0x12345600 + 0xff + 1 addrval&=~alignment; // 0x12345700 *(void * *)(addrval-sizeof(unsigned long))=addr; return (void *)addrval;}
void forget2(void *mem) { unsigned long addr=(unsigned long)mem;
addr-=sizeof(unsigned long); free((void *)(*(unsigned long *)addr));}
I have 2 questions: if size = 8 and alignment=256, it writes outside malloc allocation, isn't it? What was the meaning of the code?
Thanks
No idea. This does sound like something worth taking a look at, you might want to investigate how Etherboot does malloc/allot and also see if USB really does work there.
Good luck! Corey
Right Sorry
On Nov 15, 2007 5:38 PM, Corey Osgood corey.osgood@gmail.com wrote:
Fridel Fainshtein wrote:
I compared to etherboot and it works there. In Etherboot there are 2 set of bswap functions:
- little
- big
In FILO there is only one bswap set
Which one to choose?
no idea. but please cc the list with stuff like this so someone else can help.
-corey
On Nov 15, 2007 8:41 AM, Corey Osgood corey.osgood@gmail.com wrote:
Fridel Fainshtein wrote:
Hello all,
It seams that the USB code was taken from the previous version of FILO but never have been tested.
Since noone else piped up, here's what I've figured out: Older versions of FILO (<0.5) don't have any USB support. The original author(s) of FILO's USB stack were from LinuxLabs. I don't know what the story is, but it was probably written under contract for someone (in a case where it did work), and they simply don't have the time to provide support for it. I've heard that it was originally merged from Etherboot, where it may have worked, but I can't confirm that. In any case, it doesn't seem to have been really touched since the initial import to the svn repository, according to the svn logs.
Some symptoms are
malloc_diag: alloc: 4208 bytes (8 blocks), free: 61320 bytes (1 blocks) malloc_check: sizes mismatch: 0xa1 vs 0x0 at 00132670 2) dma_to_td: can not find td
Is this using an OHCI controller? I've tried several times with UHCI and seen a different error:
malloc_diag: alloc: xxxx bytes ([x] blocks), free: xxxx bytes (2 blocks) init_framelist: frame_list is at 13[n]000 dump_link: frame_list_link: addr: 001233[n+1]0 dump_link: frame_list_link: raw addr: 1bfd40[n*2]0 dump_link: frame_list_link: terminate: 0 dump_link: frame_list_link: queue: 1 dump_link: frame_list_link: depth: 0 (repeated half a dozen or so times) Out of heap space
Trying to debug it, I discovered the following piece of code:
void *allot2(size_t size, unsigned int alignment) { void *addr; unsigned long addrval; addr=malloc(2*size);
addrval=(unsigned long)addr; addrval+=alignment+1; // 0x12345600 + 0xff + 1 addrval&=~alignment; // 0x12345700 *(void * *)(addrval-sizeof(unsigned long))=addr; return (void *)addrval;}
void forget2(void *mem) { unsigned long addr=(unsigned long)mem;
addr-=sizeof(unsigned long); free((void *)(*(unsigned long *)addr));}
I have 2 questions: if size = 8 and alignment=256, it writes outside malloc allocation, isn't it? What was the meaning of the code?
Thanks
No idea. This does sound like something worth taking a look at, you might want to investigate how Etherboot does malloc/allot and also see if USB really does work there.
Good luck! Corey
On Nov 15, 2007 7:38 AM, Corey Osgood corey.osgood@gmail.com wrote:
Fridel Fainshtein wrote:
I compared to etherboot and it works there. In Etherboot there are 2 set of bswap functions:
- little
- big
so any reason for not using etherboot with filo or kernel loader?
YH
* yhlu yinghailu@gmail.com [071116 06:31]:
On Nov 15, 2007 7:38 AM, Corey Osgood corey.osgood@gmail.com wrote:
Fridel Fainshtein wrote:
I compared to etherboot and it works there. In Etherboot there are 2 set of bswap functions:
- little
- big
so any reason for not using etherboot with filo or kernel loader?
It uses an oooold version of FILO.. ;-)
Etherboot does not work with gcc 4. At least filo part. As I remember, I found a few strange things like #if 0 <-- original #define isdigit(c) ((c & 0x04) != 0) #define islower(c) ((c & 0x02) != 0) //#define isspace(c) ((c & 0x20) != 0) #define isupper(c) ((c & 0x01) != 0) #else <-- not optimized correction #define isdigit(c) (c >= '0' && c <= '9') #define islower(c) (c >= 'a' && c <= 'z') #define isupper(c) (c >= 'A' && c <= 'Z') #endif
These strange things caused FILO in ETHERBOOT not to work. I"ve never tested but does FILO in ETHERBOOT work if it is compiled with gcc 3?
Not optimized suggestion for allot2: void *allot2(size_t size, unsigned int alignment) { void *addr; unsigned long addrval; int pSize = sizeof(unsigned long);
if(((alignment + 1) & alignment) != 0) return (void *)0;
addr=malloc(size + alignment + /*2**/pSize);
addrval=(unsigned long)addr/* + pSize*/; addrval+=alignment+1; // 0x12345600 + 0xff + 1 addrval&=~alignment; // 0x12345700 *(unsigned long *)(addrval-sizeof(unsigned long))=addr; return (void *)addrval; }
dma_to_td still appears, but "malloc_check: sizes mismatch" disappeared and I can see a led blinking on my USB
On Nov 16, 2007 7:31 AM, yhlu yinghailu@gmail.com wrote:
On Nov 15, 2007 7:38 AM, Corey Osgood corey.osgood@gmail.com wrote:
Fridel Fainshtein wrote:
I compared to etherboot and it works there. In Etherboot there are 2 set of bswap functions:
- little
- big
so any reason for not using etherboot with filo or kernel loader?
YH
On Nov 16, 2007 4:42 AM, Fridel Fainshtein fainshf@gmail.com wrote:
Etherboot does not work with gcc 4. At least filo part. As I remember, I found a few strange things like #if 0 <-- original #define isdigit(c) ((c & 0x04) != 0) #define islower(c) ((c & 0x02) != 0) //#define isspace(c) ((c & 0x20) != 0) #define isupper(c) ((c & 0x01) != 0) #else <-- not optimized correction #define isdigit(c) (c >= '0' && c <= '9') #define islower(c) (c >= 'a' && c <= 'z') #define isupper(c) (c >= 'A' && c <= 'Z') #endif
These strange things caused FILO in ETHERBOOT not to work. I"ve never tested but does FILO in ETHERBOOT work if it is compiled with gcc 3?
the dev environment for that was RHEL 9 on 32bit laptop. OHCI was working Tyan s2885 or s2880.
what will your application be? why not use tiny kernel + kexec instead?
YH
Usb boot loader would be just a nice feature to have in an existent application.
Why should one use "tiny kernel + kexec", if there are such a wonderful things like linuxbios and filo?
On Nov 16, 2007 8:07 PM, yhlu yinghailu@gmail.com wrote:
On Nov 16, 2007 4:42 AM, Fridel Fainshtein fainshf@gmail.com wrote:
Etherboot does not work with gcc 4. At least filo part. As I remember, I found a few strange things like #if 0 <-- original #define isdigit(c) ((c & 0x04) != 0) #define islower(c) ((c & 0x02) != 0) //#define isspace(c) ((c & 0x20) != 0) #define isupper(c) ((c & 0x01) != 0) #else <-- not optimized correction #define isdigit(c) (c >= '0' && c <= '9') #define islower(c) (c >= 'a' && c <= 'z') #define isupper(c) (c >= 'A' && c <= 'Z') #endif
These strange things caused FILO in ETHERBOOT not to work. I"ve never tested but does FILO in ETHERBOOT work if it is compiled with gcc 3?
the dev environment for that was RHEL 9 on 32bit laptop. OHCI was working Tyan s2885 or s2880.
what will your application be? why not use tiny kernel + kexec instead?
YH
On 17/11/07 00:09 +0200, Fridel Fainshtein wrote:
Usb boot loader would be just a nice feature to have in an existent application.
Why should one use "tiny kernel + kexec", if there are such a wonderful things like linuxbios and filo?
Well, first and foremost, because the tiny kernel already knows how to do everything we need - it understands the devices, it can talk the protocols, it can grok the filesystems - it would take man years (decades even) to accomplish that level of support in any other payloads we might have a fancy to write.
Don't get me wrong - FILO and GRUB2 and all the other payloads are great. But they are built for a specific task - and if a feature you want isn't there, then you should look elsewhere. Nothing can compete with a LAB solution to "get it working now".
Jordan
Jordan Crouse wrote:
Well, first and foremost, because the tiny kernel already knows how to do
I'm sorry, can someone enlighten me as to what a "tiny kernel" is? Is that anything similar to this? http://www.selenic.com/linux-tiny/
Steve
On 16/11/07 14:58 -0800, Steve Isaacs wrote:
Jordan Crouse wrote:
Well, first and foremost, because the tiny kernel already knows how to do
I'm sorry, can someone enlighten me as to what a "tiny kernel" is? Is that anything similar to this? http://www.selenic.com/linux-tiny/
Well, typically, its any kernel that is small enough to fit on the ROM, with small filesystem to accompany it. And strangely enough, many people do use the linux-tiny patches to help make said kernel small enough.
But generally, we use the term "tiny kernel" to differentiate between the kernel on the ROM, and the fully featured kernel that you would normally use to run your system (i.e - the kernel that is loaded by kexec from the media of your choice).
Jordan
VxWorks "bootrom" is an example of such a tiny-kernel as well as I understand.
But in my case LAB's solution is the only way. So, debug is the only way in the nearest future.
... and then the tiny-kernel
And whether the linuxbios would have AMD K10 support the world would be perfect and smiling again.
On Nov 17, 2007 1:12 AM, Jordan Crouse jordan.crouse@amd.com wrote:
On 16/11/07 14:58 -0800, Steve Isaacs wrote:
Jordan Crouse wrote:
Well, first and foremost, because the tiny kernel already knows how to do
I'm sorry, can someone enlighten me as to what a "tiny kernel" is? Is that anything similar to this? http://www.selenic.com/linux-tiny/
Well, typically, its any kernel that is small enough to fit on the ROM, with small filesystem to accompany it. And strangely enough, many people do use the linux-tiny patches to help make said kernel small enough.
But generally, we use the term "tiny kernel" to differentiate between the kernel on the ROM, and the fully featured kernel that you would normally use to run your system (i.e - the kernel that is loaded by kexec from the media of your choice).
Jordan
-- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc.
On Sat, Nov 17, 2007 at 01:27:12AM +0200, Fridel Fainshtein wrote:
VxWorks "bootrom" is an example of such a tiny-kernel as well as I understand.
But in my case LAB's solution is the only way. So, debug is the only way in the nearest future.
... and then the tiny-kernel
Look at buildrom. We have a working LAB setup there for the Gigabyte m57sli-s4, Tyan s2882 and Tyan s2891 boards.
What board are you working on? Consider adding it to buildrom if it is not there yet; we'll be happy to take a patch.
Thanks, Ward.
OK,
supposing FILO USB works How do I submit the corrections?
On Nov 17, 2007 2:56 AM, Ward Vandewege ward@gnu.org wrote:
On Sat, Nov 17, 2007 at 01:27:12AM +0200, Fridel Fainshtein wrote:
VxWorks "bootrom" is an example of such a tiny-kernel as well as I understand.
But in my case LAB's solution is the only way. So, debug is the only way in the nearest future.
... and then the tiny-kernel
OK,
supposing FILO-USB works How do I submit the corrections for humanity use?
Look at buildrom. We have a working LAB setup there for the Gigabyte m57sli-s4, Tyan s2882 and Tyan s2891 boards.
What board are you working on? Consider adding it to buildrom if it is not there yet; we'll be happy to take a patch.
Thanks, Ward.
-- Ward Vandewege ward@fsf.org Free Software Foundation - Senior System Administrator
Fridel Fainshtein wrote:
OK,
supposing FILO USB works How do I submit the corrections?
http://www.linuxbios.org/Development_Guidelines#How_to_contribute
In short form: 1) cd to the filo-0.5/ folder 2) svn add * -R (if you've created any new files, be sure to move files you don't want added first) 3) svn diff > clever_patchname.patch 4) edit the patch, add a short description of what the patch does (which goes into the svn commit log) and a Signed-off-by: line, per the guidelines linked to above.
Thanks! -Corey
OK, thank you. My employer approved the submission. I"ll do it soon.
On Nov 26, 2007 1:24 AM, Corey Osgood corey.osgood@gmail.com wrote:
Fridel Fainshtein wrote:
OK,
supposing FILO USB works How do I submit the corrections?
http://www.linuxbios.org/Development_Guidelines#How_to_contribute
In short form:
- cd to the filo-0.5/ folder
- svn add * -R (if you've created any new files, be sure to move files
you don't want added first) 3) svn diff > clever_patchname.patch 4) edit the patch, add a short description of what the patch does (which goes into the svn commit log) and a Signed-off-by: line, per the guidelines linked to above.
Thanks! -Corey
Fridel Fainshtein wrote:
OK, thank you. My employer approved the submission. I"ll do it soon.
It will be very appreciated, I can assure you of that ;) I look forward to seeing it, and I'll be happy to test.
Thanks, Corey
On Nov 26, 2007 1:24 AM, Corey Osgood <corey.osgood@gmail.com mailto:corey.osgood@gmail.com> wrote:
Fridel Fainshtein wrote: > OK, > > supposing FILO USB works > How do I submit the corrections? > http://www.linuxbios.org/Development_Guidelines#How_to_contribute In short form: 1) cd to the filo-0.5/ folder 2) svn add * -R (if you've created any new files, be sure to move files you don't want added first) 3) svn diff > clever_patchname.patch 4) edit the patch, add a short description of what the patch does (which goes into the svn commit log) and a Signed-off-by: line, per the guidelines linked to above. Thanks! -Corey
Jordan Crouse wrote:
On 16/11/07 14:58 -0800, Steve Isaacs wrote:
Jordan Crouse wrote:
Well, first and foremost, because the tiny kernel already knows how to do
I'm sorry, can someone enlighten me as to what a "tiny kernel" is? Is that anything similar to this? http://www.selenic.com/linux-tiny/
Well, typically, its any kernel that is small enough to fit on the ROM, with small filesystem to accompany it. And strangely enough, many people do use the linux-tiny patches to help make said kernel small enough.
The problem with the current tiny-kernel approach is that, it can't get nearly as tiny as filo. And when you have legacy systems like i440bx with only 256kb flash, then tiny-kernel becomes a definite no go, which make filo the only viable solution.
What we really need is a stripped down tiny-kernel. IOW, a single-proc kernel-stub with its sole purpose to provide access to the large linux driver pool. Later, this could conceivably be inlined with the LinuxBIOS code-base, making LinuxBIOS really a BIOS that makes use of linux.
Thanks!
-- Al
Al Boldi wrote:
The problem with the current tiny-kernel approach is that, it can't get nearly as tiny as filo. And when you have legacy systems like i440bx with only 256kb flash, then tiny-kernel becomes a definite no go, which make filo the only viable solution.
What we really need is a stripped down tiny-kernel. IOW, a single-proc kernel-stub with its sole purpose to provide access to the large linux driver pool. Later, this could conceivably be inlined with the LinuxBIOS code-base, making LinuxBIOS really a BIOS that makes use of linux.
I don't have good memories on this approach: MILO, the Alpha Linux bootloader, did exactly that. Been there, done that. I made such a stub for Kernels 2.2 and 2.4.
The one disadvantage of all Linux as Bootloader approaches is that you can not really fit any decent amount of drivers into any existing system flash. Yes it has been done as a proof-of-concept but as far as I know Linux-as-bootloader never made it into any product (that I know of)
Ripping the scheduler out of Linux will get us space for another half to full driver ... But creating a flexible ROM that allows to use all SCSI controllers and boot a number of operating systems, will always fail. The SCSI drivers of Linux alone are more than 30MByte. Even with 128MBit parts we don't come anywhere close.
Don't get me wrong. I do like the L-A-B approach. It's just not the solution to all problems.
Stefan
Stefan Reinauer wrote:
Al Boldi wrote:
The problem with the current tiny-kernel approach is that, it can't get nearly as tiny as filo. And when you have legacy systems like i440bx with only 256kb flash, then tiny-kernel becomes a definite no go, which make filo the only viable solution.
What we really need is a stripped down tiny-kernel. IOW, a single-proc kernel-stub with its sole purpose to provide access to the large linux driver pool. Later, this could conceivably be inlined with the LinuxBIOS code-base, making LinuxBIOS really a BIOS that makes use of linux.
I don't have good memories on this approach: MILO, the Alpha Linux bootloader, did exactly that. Been there, done that. I made such a stub for Kernels 2.2 and 2.4.
How big did the stub turn out to be?
The one disadvantage of all Linux as Bootloader approaches is that you can not really fit any decent amount of drivers into any existing system flash. Yes it has been done as a proof-of-concept but as far as I know Linux-as-bootloader never made it into any product (that I know of)
Ripping the scheduler out of Linux will get us space for another half to full driver ... But creating a flexible ROM that allows to use all SCSI controllers and boot a number of operating systems, will always fail. The SCSI drivers of Linux alone are more than 30MByte. Even with 128MBit parts we don't come anywhere close.
You wouldn't want to compile all drivers in. Just the ones to boot the system, and then kexec the real kernel.
Don't get me wrong. I do like the L-A-B approach. It's just not the solution to all problems.
Agreed.
Thanks!
-- Al
--- Stefan Reinauer stepan@coresystems.de wrote:
Yes it has been done as a proof-of-concept but as far as I know Linux-as-bootloader never made it into any product (that I know of)
There are at least two "super-BIOS" implementations that rely on a tiny Linux kernel loaded from Flash ROM:
1) SplashTop by ASUS (http://SplashTop.com) Source code, including kernel patches, are downloadable: http://www.phoronix.com/scan.php?page=article&item=915&num=1
2) Hyperspace by Phoenix Technologies: http://www.informationweek.com/blog/main/archives/2007/11/phoenixs_hypers.ht...
Both of these run X.org, so I'm sure we'd need even less flash storage for a text-mode interface.
The Linux-tiny project maintained by Sony also has patches to reduce kernel size: http://elinux.org/Linux_Tiny
Vlad
____________________________________________________________________________________ Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try it now. http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ
On Sat, Nov 17, 2007 at 01:39:33PM -0800, Vlad wrote:
There are at least two "super-BIOS" implementations that rely on a tiny Linux kernel loaded from Flash ROM:
Good point.
For LAB I believe Stefan wants to include more drivers in order to avoid having to rebuild/reflash the BIOS when the SCSI controller burns and the system needs to rescue-boot from something else.
//Peter
On Nov 17, 2007 5:40 PM, Peter Stuge peter@stuge.se wrote:
On Sat, Nov 17, 2007 at 01:39:33PM -0800, Vlad wrote:
There are at least two "super-BIOS" implementations that rely on a tiny Linux kernel loaded from Flash ROM:
Good point.
For LAB I believe Stefan wants to include more drivers in order to avoid having to rebuild/reflash the BIOS when the SCSI controller burns and the system needs to rescue-boot from something else.
you could update optionrom to have one driver module instead...
like current some addone cards have x86 option rom + FCode + EFI code.
YH
Al Boldi wrote:
Jordan Crouse wrote:
On 16/11/07 14:58 -0800, Steve Isaacs wrote:
Jordan Crouse wrote:
Well, first and foremost, because the tiny kernel already knows how to do
I'm sorry, can someone enlighten me as to what a "tiny kernel" is? Is that anything similar to this? http://www.selenic.com/linux-tiny/
Well, typically, its any kernel that is small enough to fit on the ROM, with small filesystem to accompany it. And strangely enough, many people do use the linux-tiny patches to help make said kernel small enough.
The problem with the current tiny-kernel approach is that, it can't get nearly as tiny as filo. And when you have legacy systems like i440bx with only 256kb flash, then tiny-kernel becomes a definite no go, which make filo the only viable solution.
The i440bx was released nearly 9 years ago. Why be concerned with a very small fraction of the potential LinuxBIOS applications?
Who is or will be designing anything with only 2Mb (256KB) of Flash? It's difficult to even find Flash under 4Mb (512KB) in high volume.
-Bari
bari wrote:
Who is or will be designing anything with only 2Mb (256KB) of Flash? It's difficult to even find Flash under 4Mb (512KB) in high volume.
Even with 512kb you run a pretty tight ship. And that's most boards today.
The idea here is to keep the LB-footprint as tiny as possible, and not to bloat unnecessarily. Just think about it for a second: A multi-tasking, multi-threaded kernel just to kexec. Wow, talk about bloat.
But, there is another way: Have LB read the payload in raw from USB.
Thanks!
-- Al
Al Boldi wrote:
bari wrote:
Who is or will be designing anything with only 2Mb (256KB) of Flash? It's difficult to even find Flash under 4Mb (512KB) in high volume.
Even with 512kb you run a pretty tight ship. And that's most boards today.
The idea here is to keep the LB-footprint as tiny as possible, and not to bloat unnecessarily. Just think about it for a second: A multi-tasking, multi-threaded kernel just to kexec. Wow, talk about bloat.
But, there is another way: Have LB read the payload in raw from USB.
Eric got some pretty good results in stripping the Tiny1 Linux kernel down a few years ago. 220K compressed and 371K uncompressed. http://lkml.org/lkml/2004/1/4/10
Removing all the error messages from the kernel removed about 300k from it alone.
Some recent projects that may be of interest:
Kernel Size Tuning Guide: http://elinux.org/Kernel_Size_Tuning_Guide
Open Test Lab of the CE Linux Forum - results of testing the size of the Linux kernel using different values for configuration options: http://testlab.celinuxforum.org/otlwiki/ConfigSizeTestResultsNutOct1
~3Mb (375KB) is about the smallest I've seen with recent kernels
I haven't even seen any ucLinux kernels striped down to this small a footprint.
Embedded Linux Wiki: http://elinux.org/Main_Page
-Bari
-
Al Boldi -
bari -
Corey Osgood -
Fridel Fainshtein -
Jordan Crouse -
Peter Stuge -
Stefan Reinauer -
Steve Isaacs -
Vlad -
Ward Vandewege -
yhlu