====== Differences ====== This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
|
soc:2008:dverkamp:journal:week8 [2008/07/17 09:41] drv created |
soc:2008:dverkamp:journal:week8 [2008/07/18 08:41] (current) drv |
||
|---|---|---|---|
| Line 9: | Line 9: | ||
| * After a conversation with mcb30 last Thursday on how to fix the problems with COM32 stack overwrites during image loading, I've implemented his suggestions. This resulted in a 3-day debugging marathon until I switched to a simpler test case and just single stepped through the entire image execution process... and finally noticed (thanks to the Intel-syntax Bochs debugger) that I had written a constant as 12 instead of $12 (AT&T syntax strikes again :-)). But the upshot of all this is that COM32 programs using "Run kernel image" work totally correctly now, without any hack to limit the stack size, and I can say without reservation that menu.c32 is working perfectly fine now (given the configuration filename via the command line); it can load itself numerous times (until there is no more memory left to load the image again) as well as other image types without any problems now. I plan to start doing further testing on real hardware with various booting scenarios now, but so far, everything looks good. | * After a conversation with mcb30 last Thursday on how to fix the problems with COM32 stack overwrites during image loading, I've implemented his suggestions. This resulted in a 3-day debugging marathon until I switched to a simpler test case and just single stepped through the entire image execution process... and finally noticed (thanks to the Intel-syntax Bochs debugger) that I had written a constant as 12 instead of $12 (AT&T syntax strikes again :-)). But the upshot of all this is that COM32 programs using "Run kernel image" work totally correctly now, without any hack to limit the stack size, and I can say without reservation that menu.c32 is working perfectly fine now (given the configuration filename via the command line); it can load itself numerous times (until there is no more memory left to load the image again) as well as other image types without any problems now. I plan to start doing further testing on real hardware with various booting scenarios now, but so far, everything looks good. | ||
| + | |||
| + | === 18 July === | ||
| + | |||
| + | * Added a jmp to self-modifying intcall code to avoid problems on 486 (makes execution in qemu much faster too) [[ http://git.etherboot.org/?p=people/dverkamp/gpxe.git;a=commitdiff;h=3d6bd95bcb0919c4c14df0a1bce3641388f6d88d | 3d6bd95bcb0919c4c14df0a1bce3641388f6d88d ]] | ||
| + | |||
| + | Since menu.c32 is working well now, here is a sample SYSLINUX menu I am using to test (http://10.0.0.11 is a web server): | ||
| + | |||
| + | <code> | ||
| + | default menu.c32 | ||
| + | prompt 0 | ||
| + | menu title gPXE COMBOOT menu test | ||
| + | |||
| + | timeout 600 | ||
| + | |||
| + | label tomsrtbt | ||
| + | menu label tomsrtbt | ||
| + | menu default | ||
| + | kernel http://10.0.0.11/~daniel/gpxe/gtest/bz2bzImage | ||
| + | append initrd=http://10.0.0.11/~daniel/gpxe/gtest/initrd.bz2 root=100 | ||
| + | |||
| + | label gtest | ||
| + | menu label tomsrtbt via gtest.gpxe | ||
| + | kernel http://10.0.0.11/~daniel/gpxe/gtest.gpxe | ||
| + | |||
| + | label tube | ||
| + | menu label tube | ||
| + | kernel http://10.0.0.11/~daniel/gpxe/TUBE.COM | ||
| + | </code> | ||
| + | |||
| + | * Had a bit of fun playing with xl0's newly-ported Lua COM32 module ([[http://syslinux.zytor.com/archives/2008-July/010386.html | SYSLINUX mailing list thread ]]); it worked fine without any modifications (although I haven't tested much). You can see my obvious incompetence at Lua :-) (the function is an example from //Programming in Lua//):{{:soc:2008:dverkamp:journal:jul-18-2008-lua.png|}} | ||
