steven james pyro@linuxlabs.com writes:
Greetings,
Looks like I've trodden on an unused code path, and found a bug. In arch/i386/boot/boot.c: jmp_to_elf_entry, the idea is to copy all of the running code (linuxbios, or a baremetal payload) to a bounce buffer, jump into the copy there, copy the bounce buffer of the target elf into place, and call it. Upon return, the process is reversed, so that (in theory) jmp_to_elf_entry returns and further processing can happen.
For some reason, the lines that subtract the adjustment from EAX, then jump to move execution back to the proper place was failing. I've patched it in the copy kept in util/baremetal/lib so that instead, it loads the eventual jmp target into ecx, then saves it away on the stack.
I'm surely missing something here, but the original goes into space while the simple save off is working. I suppose that's just because we've never tried to return to LinuxBIOS from a payload before.
That sounds correct. It was there for completeness rather than a real need. And I never did test it.
The baremetal version also skips adjusting ESP since I'm moving the stack out of the way first.
Ignore the // debugging stuff, that was just to see where things were going wrong (I'll be getting rid of that).
Eric, since you wrote that part, I wanted to run this by you before making any changes in LinuxBIOS itself.
I would not be surprised to learn that the returning to LinuxBIOS was not working.
For LinuxBIOS itself all we can do is call hard_reset like we do for the other weird cases. But for the baremetal tool kit there we can definitely do something interesting.
I will have to look at what you are looking at stack wise but I certainly think we should have a stack that is out of the way as well, and we cannot have that in LinuxBIOS until we actually know our final memory size. And that information is not know until late.
There is one glitch in the LinuxBIOS code. After thinking and looking at things and see what works most reliably. We should be passing the address of the parameter block with the standard C calling conventions (and on x86 this is on the stack). I have modified etherboot to do this. I have not gotten back to the LinuxBIOS code.
With respect to memory maps. That is one piece of information that we should pass both ways. Both in the LinuxBIOS table, and in the parameter block we pass to the loaded image.
This allows someone to find the real memory usage as well as to find what the bootloader thinks about the current situation. A memory map is something fundamental enough that the memory allocation will always be changing.
I need to take my that specifies things about ELF booting and do another version. But I have not gotten quite that far yet.
Eric