Hi again,
I just tried the romimage - It didn't work! Well, the LinuxBIOS booted and everything looked OK up until the same point as I have seen before from my builds; elfboot is started, but the payload seems completely dead... :-( Since I saw the payload in the romimage was etherboot, I also hooked up the ethernet and started sniffing it with ethereal, but no packets were ever sent on the ethernet. I have also checked that nothing comes out on the VGA console. My conclusion is that the Etherboot payload either never is reached, or crashes at an early stage.
Well, I guess this anyway gives me lots of hints by ruling out all the doubts I had about my config and build process; now I guess there must be something different between our Smartcore-P5 based hardwares...
Could I please ask you to check what cardtype/revision you're using? My HW config looks as follows: DigitalLogic MSM-P5SEN, V3.9, Rev A. It's also marked 03.04 which I guess is the manufacturing date(?) This card has a SmartCore-P5 module clocked at 166MHz. There is only one Revision label on this module, but it has no revision mark on it... The MSM-P5SEN variant comes without VGA cirquitry, but I have also tried LinuxBIOS on the VGA-equipped variant we have around here with the same result. The onboard Flash is a Winbond 29C020CP (i.e 256kB), but LinuxBIOS boots equally well also from 128kB and 512kB flashes I've tried in the socket. The card has one SDRAM slot, which we have equipped with a 128MB large module.
Looking for simple answers; could you possibly be using a different size (larger) RAM, and could the elfboot for this platform have some code fragments not checking the detected RAM size so that it relocates the payload out inito the void?
On Fri, 20 May 2005, Kjell Svensson wrote:
Well, the LinuxBIOS booted and everything looked OK up until the same point as I have seen before from my builds; elfboot is started, but the payload seems completely dead... :-(
most likely this is a memory programming issue then. We've had lots of trouble with the tiny DIMMS used on these cards -- the fuctory bios programs them very conservatively, or linuxbios gets something wrong, or some combination of the two, and result is what you are seeing.
Recommend you get memtest86.
Also, the memory that has worked well for us is Apacer. What I have on my SC520 is the Apacer 128MB UBN PC133 CL3 memory.
ron
Hi again, I've left the lab for the week now, so I can't check what DIMM type we're using until Monday. But I do now for sure they work well using the factory BIOS settings, we have several hundred units shipped running Linux well on them without customer complaints.
I'm not sure I understand what I could use memtest86 for at this point? Since I'm not able to start any payloads from LinuxBIOS, I wouldn't be able to run memtest from that? Or do you mean I should run memtest86 started from the route factory BIOS -> GRUB -> memtest86? If so, what is it I should look for??
Are there any special linuxbios memory settings you believe I could try with more conservative settings? But if it's a DRAM issue, wouldn't then the LinuxBIOS itself crash then? Isn't LinuxBIOS relocating itself into the DRAM during startup?
Cheers, /Kjell
On 20 maj 2005, at 17:32, Ronald G. Minnich wrote:
On Fri, 20 May 2005, Kjell Svensson wrote:
Well, the LinuxBIOS booted and everything looked OK up until the same point as I have seen before from my builds; elfboot is started, but the payload seems completely dead... :-(
most likely this is a memory programming issue then. We've had lots of trouble with the tiny DIMMS used on these cards -- the fuctory bios programs them very conservatively, or linuxbios gets something wrong, or some combination of the two, and result is what you are seeing.
Recommend you get memtest86.
Also, the memory that has worked well for us is Apacer. What I have on my SC520 is the Apacer 128MB UBN PC133 CL3 memory.
ron
LinuxBIOS mailing list LinuxBIOS@openbios.org http://www.openbios.org/mailman/listinfo/linuxbios
I've been able to run memtest at times when I could not run a real payload.
I am pretty sure this is memory timing, I just don't see why or how.
I'll try to think on this over the weekend.
ron