On Tue, Dec 04, 2007 at 09:25:42AM +1100, Andrew Dennison wrote: > To the list too... > > ---------- Forwarded message ---------- > From: Andrew Dennison <[EMAIL PROTECTED]> > Date: Dec 4, 2007 9:24 AM > Subject: Re: [Prex-devel] problems booting with large task > To: Alexander Botero-Lowry <[EMAIL PROTECTED]> > > > On Dec 3, 2007 8:05 PM, Alexander Botero-Lowry <[EMAIL PROTECTED]> wrote: > > Howdy all, > > > > For the last few days I've been porting over SEE (Simple ECMAScript Engine) > > [ http://www.adaptive-enterprises.com.au/~d/software/see/ ] to prex. This > > has mainly involved porting over some of msun (the math lib freebsd uses), > > and filling in a few holes in stdio implementation as well as stealing a > > few necessary include files and the likes here and there. I also extended > > fslib to have fprintf, vfprintf, fputc and fwrite implementations, which > > are used in a few places by libsee. Anyway, I finally got it all compiling > > and linking, but when I attemped to boot with my new task I ran into a > > fun new set of problems. If any calls are actually made to libsee, prex > > either gets a triple fault (or so qemu says), or qemu simply goes for a > > blank screen with no indication of how far into the boot process it got. > > Have you turned on boot debugging? > In boot/include/boot.h: > #define DEBUG_BOOT 1 > #define DEBUG_BOOT_IMAGE 1 > #define DEBUG_BOOT_IMAGE_RELOCATE 1 > This doesn't seem to give me anything new when I try to boot, either in the case of a triple fault or in the case of a hang on a blank screen. Which is leading me to believe that it may be a problem in the boot sector. Since the triple fault occurs right after "Loading PREXOS..."
> How much memory does prex have available on i386? It looks like > CONFIG_MIN_MEMORY is set in the default config so you may be > exhausting the 512KB that appears to be available (I've never run prex > seriously on i386). > On boot it always says one meg available, I haven't quite figured out how to convince it to see all the memory.. > > > My guess is that either bootldr or the boot sector can not handle the > > large binary in the disk image. A simple test of the interpreter is about > > a 300kb binary. > > This would most likely show up as an unsupported type of elf > relocation. Are you using an executable task or a relocatable task? > executable task, but i'm thinking that the increased size of the FAT table is tripping up the boot sectors ability to actually load the image at all? > Does your task fit within any arbitrary limits imposed by the link script? > Not that I can tell, but that asm stuff that constitutes the linker script doesn't really mean much to me. > > > > The information dumped by qemu when a triple fault occurs are as follows: > > Wikipedia suggests a triple fault can be caused when the IDT is > corrupted: sounds like a memory sizing / linking issue. > > The prex i386 port has a gdb stub - are you using gdb in your debugging? > I haven't quite figured out how to attach gdb via qemu, though if I'm right about it being the boot sector that won't help much. > Andrew > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > _______________________________________________ > Prex-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/prex-devel > ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 _______________________________________________ Prex-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/prex-devel
