Hello,
A small voice from the distant past here.
I have a custom system using LinuxBIOS V1. Yes! 1! This is a PIII/440BX based system.
We have found that we can boot 2.6.23-17, but can not boot 2.6.24. Investigation using characters posted on the serial port suggest that we are starting the kernel and getting to about the point where the clock speed of the CPU and then it just stops as far as we can tell.
We've found that if we put in more output to the serial port, it dies earlier in the code. We can't be sure, bit it appears that it might be some sort of a time based problem. It dies after a certain amount of time and if we use that time by polling characters out the serial port, then we don't get as far through the code before death.
One thought that almost fits the facts is that a interrupt might be occurring and not handled properly. But it happens that the CPU clock speed code disables interrupts and this is where it is dying.
There seems to have been a number of changes in 2.6.24 to support booting kernels in virtual machines and to merge ia64 and ia32 under x86. Some notes were added about 32 bit boot loaders that reference LinuxBIOS. However, we've been unable to find what it is that we are doing wrong. We have grep'ed the internet and browsed through the CoreBoot email archives, but failed to find anything that might have been in either "place".
Anyone out there have any suggestions or know what happened during 2.6.24 development that might have changed the requirements for successfully starting a kernel?
Thanks! Ty
Welcome back, Tyson!
On 1/29/10 9:08 PM, Tyson Sawyer wrote:
Hello,
A small voice from the distant past here.
I have a custom system using LinuxBIOS V1. Yes! 1! This is a PIII/440BX based system.
We have found that we can boot 2.6.23-17, but can not boot 2.6.24. Investigation using characters posted on the serial port suggest that we are starting the kernel and getting to about the point where the clock speed of the CPU and then it just stops as far as we can tell.
Could you provide a log of the boot with each kernel? It might help getting an idea of what could be going wrong.
We've found that if we put in more output to the serial port, it dies earlier in the code. We can't be sure, bit it appears that it might be some sort of a time based problem. It dies after a certain amount of time and if we use that time by polling characters out the serial port, then we don't get as far through the code before death.
How early in the code can you get it to die? I wonder whether some watchdog driver could cause the trouble?
One thought that almost fits the facts is that a interrupt might be occurring and not handled properly. But it happens that the CPU clock speed code disables interrupts and this is where it is dying.
Knowing a bit more about the hardware and kernel configuration would certainly help.
There seems to have been a number of changes in 2.6.24 to support booting kernels in virtual machines and to merge ia64 and ia32 under x86. Some notes were added about 32 bit boot loaders that reference LinuxBIOS. However, we've been unable to find what it is that we are doing wrong. We have grep'ed the internet and browsed through the CoreBoot email archives, but failed to find anything that might have been in either "place".
Worst case you could diff between 2.6.23-17 and 2.6.24 and do a binary search over the differences until you find the culprit. But maybe there is a higher level approach that wants to be taken first.
Best regards, Stefan
Stefan Reinauer wrote:
Worst case you could diff between 2.6.23-17 and 2.6.24 and do a binary search over the differences until you find the culprit.
Or try to use git bisect to do it.
//Peter
Stefan Reinauer wrote:
Welcome back, Tyson!
Thanks! ...I guess. ;-)
On 1/29/10 9:08 PM, Tyson Sawyer wrote:
Hello,
A small voice from the distant past here.
I have a custom system using LinuxBIOS V1. Yes! 1! This is a PIII/440BX based system.
We have found that we can boot 2.6.23-17, but can not boot 2.6.24. Investigation using characters posted on the serial port suggest that we are starting the kernel and getting to about the point where the clock speed of the CPU and then it just stops as far as we can tell.
Could you provide a log of the boot with each kernel? It might help getting an idea of what could be going wrong.
The kernel provides no output what at all. The early printk option also provides nothing. It dies too early for that. I had the guy working on it (I sent the email to coreboot because he just went on a week vacation) put in some low level code to write directly to the serial port (copied from the code I have in Linuxbios) so that we would have some sort of output, even if just a single character.
We've found that if we put in more output to the serial port, it dies earlier in the code. We can't be sure, bit it appears that it might be some sort of a time based problem. It dies after a certain amount of time and if we use that time by polling characters out the serial port, then we don't get as far through the code before death.
How early in the code can you get it to die? I wonder whether some watchdog driver could cause the trouble?
I don't think there are any, but I could look into that. The hardware is our own that we've been using since I as previously involved with Linuxbios and V1 was state of the art. There is no watchdog hardware, but we could look for a driver that might do something silly? Seems like a long shot, but worth a look.
One thought that almost fits the facts is that a interrupt might be occurring and not handled properly. But it happens that the CPU clock speed code disables interrupts and this is where it is dying.
Knowing a bit more about the hardware and kernel configuration would certainly help.
I'm not sure where to start there, esp. since it is custom hardware except to say that there is nothing exotic.
There seems to have been a number of changes in 2.6.24 to support booting kernels in virtual machines and to merge ia64 and ia32 under x86. Some notes were added about 32 bit boot loaders that reference LinuxBIOS. However, we've been unable to find what it is that we are doing wrong. We have grep'ed the internet and browsed through the CoreBoot email archives, but failed to find anything that might have been in either "place".
Worst case you could diff between 2.6.23-17 and 2.6.24 and do a binary search over the differences until you find the culprit. But maybe there is a higher level approach that wants to be taken first.
Yeah... that. I was hoping that the easy way out would be that I mention 2.6.24 and everyone jumps up and down and tells me about the well known change for 32 bit loaders that we need to make. ;-)
Best regards, Stefan
Thanks! Ty
Hi Tyson,
On 29.01.2010 21:08, Tyson Sawyer wrote:
A small voice from the distant past here.
Nice to hear from you again.
I have a custom system using LinuxBIOS V1. Yes! 1! This is a PIII/440BX based system.
We have found that we can boot 2.6.23-17, but can not boot 2.6.24. Investigation using characters posted on the serial port suggest that we are starting the kernel and getting to about the point where the clock speed of the CPU and then it just stops as far as we can tell.
This may or may not be an option, but have you thought about coreboot v2? AFAIK it should work well on PIII/i440BX systems.
Regards, Carl-Daniel
On 01/30/2010 08:51 AM, Carl-Daniel Hailfinger wrote:
Hi Tyson,
On 29.01.2010 21:08, Tyson Sawyer wrote:
A small voice from the distant past here.
Nice to hear from you again.
I have a custom system using LinuxBIOS V1. Yes! 1! This is a PIII/440BX based system.
We have found that we can boot 2.6.23-17, but can not boot 2.6.24. Investigation using characters posted on the serial port suggest that we are starting the kernel and getting to about the point where the clock speed of the CPU and then it just stops as far as we can tell.
This may or may not be an option, but have you thought about coreboot v2? AFAIK it should work well on PIII/i440BX systems.
Hello Tyson, coreboot v2 i440bx code should work for you. I was looking at the code last night for someone else and it appears alot of the code is hardcoded. It is a good starting point, but the i440bx still needs some work. Hope that helps.
P.S. - I am local to the area and I know one of your co-workers :-)
Joseph Smith wrote:
On 01/30/2010 08:51 AM, Carl-Daniel Hailfinger wrote:
Hi Tyson,
On 29.01.2010 21:08, Tyson Sawyer wrote:
A small voice from the distant past here.
Nice to hear from you again.
I have a custom system using LinuxBIOS V1. Yes! 1! This is a PIII/440BX based system.
We have found that we can boot 2.6.23-17, but can not boot 2.6.24. Investigation using characters posted on the serial port suggest that we are starting the kernel and getting to about the point where the clock speed of the CPU and then it just stops as far as we can tell.
This may or may not be an option, but have you thought about coreboot v2? AFAIK it should work well on PIII/i440BX systems.
Hello Tyson, coreboot v2 i440bx code should work for you. I was looking at the code last night for someone else and it appears alot of the code is hardcoded. It is a good starting point, but the i440bx still needs some work. Hope that helps.
Geesh... I hope that hard coded stuff isn't still the stuff I contributed back in V1?!
I doubt that an upgrade to Coreboot V2 (V4 now?) is an option for me right now. We may have solved our immediate problem, thus delaying any need to upgrade the kernel. However, I hate being locked into old kernels so I am trying to get this fixed anyway. ...while being locked in to an old bios? ;-)
Thanks! Ty
-
Carl-Daniel Hailfinger -
Joseph Smith -
Peter Stuge -
Stefan Reinauer -
Tyson Sawyer