I seem to have gotten myself stuck. I can load an elf image out of ROM but can't jump to it. I _can't_ load an elf image off of the drive at all.
The output of a boot using BOOT_ROM=1 and having the natsemi.elf at 0xc000 is attached.
If I try BOOT_IDE=1 the only difference is that it doesn't find an elf candidate (it never tries to access the HDD).
The end goal is to load the kernel off of CompactFlash on IDE0 master. I (think I) know how to place the kernel on the HDD and adjust the IDE_OFFSET in the config but I'm not even getting that far.
From the attached serial output you can see that it finds the natsemi.elf and
that it is declared valid. If I examine code at 0x400000 it seems to be correct, meaning that it did copy the code over there.
The processor never gets up there though. From tracing through the image it seems that the adjustment for Linuxbios' image in high memory is all messed up.
After editing loglevel.h to allow "spew" level printks, the following is visible (I could see it throught the bochs debugger, but this just verifies that I'm not totally crazy. :-)
Loaded segments verified segments closed down stream Jumping to boot code at 0x400000 entry = 0x00400000 lb_start = 0x00004000 lb_size = 0x0004e2d0 adjust = 0x3fbadd30 buffer = 0x3fb63a60 elf_boot_notes = 0x0000bc40 adjusted_boot_notes = 0x3fbb9970
now adjust and buffer are both waaaaaaaaaaaaaay beyond normal memory space... Is this normal or did I just fail to initialize something correctly?
the objdump output for the natsemi.elf is also attached. From what I can tell it's nothing unusual.
Regards, Andrew
Greetings,
The bounce buffer is normally allocated at the top of ram - 2* the size of the LinuxBIOS ram segment. It would appear that its got the wrong idea about the size of ram in this case.
G'day, sjames
On Sun, 24 Nov 2002, Andrew Kohlsmith wrote:
I seem to have gotten myself stuck. I can load an elf image out of ROM but can't jump to it. I _can't_ load an elf image off of the drive at all.
The output of a boot using BOOT_ROM=1 and having the natsemi.elf at 0xc000 is attached.
If I try BOOT_IDE=1 the only difference is that it doesn't find an elf candidate (it never tries to access the HDD).
The end goal is to load the kernel off of CompactFlash on IDE0 master. I (think I) know how to place the kernel on the HDD and adjust the IDE_OFFSET in the config but I'm not even getting that far.
From the attached serial output you can see that it finds the natsemi.elf and
that it is declared valid. If I examine code at 0x400000 it seems to be correct, meaning that it did copy the code over there.
The processor never gets up there though. From tracing through the image it seems that the adjustment for Linuxbios' image in high memory is all messed up.
After editing loglevel.h to allow "spew" level printks, the following is visible (I could see it throught the bochs debugger, but this just verifies that I'm not totally crazy. :-)
Loaded segments verified segments closed down stream Jumping to boot code at 0x400000 entry = 0x00400000 lb_start = 0x00004000 lb_size = 0x0004e2d0 adjust = 0x3fbadd30 buffer = 0x3fb63a60 elf_boot_notes = 0x0000bc40 adjusted_boot_notes = 0x3fbb9970
now adjust and buffer are both waaaaaaaaaaaaaay beyond normal memory space... Is this normal or did I just fail to initialize something correctly?
the objdump output for the natsemi.elf is also attached. From what I can tell it's nothing unusual.
Regards, Andrew
The bounce buffer is normally allocated at the top of ram - 2* the size of the LinuxBIOS ram segment. It would appear that its got the wrong idea about the size of ram in this case.
totalram: 1020M
I think you're absolutely correct. :-) Damn I never saw that line before you brought it to my attention. Now I know where to look.
Any thoughts on getting BOOT_IDE to work? With the option enabled I saw absolutely no change in the elfboot operation. changing BOOT_ROM to 0 was similarly uneventful. I don't _think_ it has anything to do with the PIRQ routing table having bad CRCs for entries (how did that happen anyway, it was generated by the appropriate utility). I'll do some more investigation but thank you for pointing me off to the memory issue.
Regards, Andrew
Andrew Kohlsmith akohlsmith-linuxbios@benshaw.com writes:
The bounce buffer is normally allocated at the top of ram - 2* the size of the LinuxBIOS ram segment. It would appear that its got the wrong idea about the size of ram in this case.
totalram: 1020M
I think you're absolutely correct. :-) Damn I never saw that line before you brought it to my attention. Now I know where to look.
Any thoughts on getting BOOT_IDE to work? With the option enabled I saw absolutely no change in the elfboot operation. changing BOOT_ROM to 0 was similarly uneventful. I don't _think_ it has anything to do with the PIRQ routing table having bad CRCs for entries (how did that happen anyway, it was generated by the appropriate utility). I'll do some more investigation but thank you for pointing me off to the memory issue.
Nothing in etherboot uses interrupts, so the pirq table is definitely ruled out.
Eric
The bounce buffer is normally allocated at the top of ram - 2* the size of the LinuxBIOS ram segment. It would appear that its got the wrong idea about the size of ram in this case.
One thing I have determined from going through the 430tx raminit.inc is that raminit sets up 64M of memory, then 128M. It is _not_ autodetected, and does _not_ use SPD. This is contrary to what I had read, but it was admittedly for another mainboard.
In other news, I managed to get BOOT_IDE to work, and managed to actually boot a kernel!
Regards, Andrew
On Mon, 25 Nov 2002, Andrew Kohlsmith wrote:
One thing I have determined from going through the 430tx raminit.inc is that raminit sets up 64M of memory, then 128M. It is _not_ autodetected, and does _not_ use SPD. This is contrary to what I had read, but it was admittedly for another mainboard.
sorry about that. That 430tx was such a mess that once we got it to work at all we stopped.
It should not be hard to fix that problem, however.
ron