I tried booting it on a 486, both the standard and the medium model and it loaded fine then stopped like this:
INVALID INSTRUCTION at ....
check corruption with boot.asm: ....
Sorry I didn't copy down the codes, it's on the monitor and also they disappeared after a few seconds even though I pressed pause.
I wonder if it's something as simple as compiling it with -mcpu=486 or 386 flag?
Don't worry too much about it. This motherboard is flaky and I am going to replace it with a Pentium board in a moment.
If Gujin is no more booting on a 486 that would be a bug, I will retry tonight on my reference
portable PC with a 486-DX4/25. The compilation flags are fine for 386/486 CPUs, and I would like
to keep 386/486 working, at least when the fault is not in the BIOS.
Unfortunately, I do not have enough information here - was it started from DOS or from a floppy
or a hard disk? Is that INVALID INSTRUCTION at a Gujin address (kind of 0x1000:0000 to 0x8000:0000)
or at a BIOS address (over 0xA000:0000). When exactly "INVALID INSTRUCTION" appears in the boot
process (I assume the graphic interface was working, but was it in VESA1/window or VESA2/linear),
and does it appear when the tickbox "force bzImage protocol" is checked and/or unchecked?
Without more data I have to assume that the "motherboard is flaky" even for Gujin...
That is my problem with Gujin, not enought bug reports so I have to check myself in between
20 and 40 different ways to boot before release - preferably on different PCs - and when I
have a bug report I do not have enough info to find the problem. Obviously not your fault neither.
Let's have a coffee...
It was booted from a raw floppy, not from DOS.
The address was quite high and I think it was a linear address. It happened right after Gujin1..Gujin2...Loaded and then the banner with the version number. The graphics was still in the original VESA mode, in fact the info from the BIOS was still on the top of the screen.
I didn't compile it myself, I just used the standard image in your tarball.
Sorry this is not much help. Don't worry too much about it, this 486 mobo has a defective L2 cache and it's going to the recycling station anyway. I think it's the last of my 486s. I booted Gujin on a Pentium just a while ago and it worked fine.
BTW, I wonder if the small version of the code could be made to fit into a boot PROM, the kind that is normally put on NICs. 50kB is doable in a PROM. I know something about booting from ROMs as I used to lead the Etherboot project.
I don't know for your 486, could be the screen EDID BIOS (to know the size of the screen), the mouse/joystick
detection,... I still did not come back home to try.
For insertion of Gujin in NIC boot PROM, I tried to think about it but most of the NICs I have have just
32 Kbytes available and 32 Kb is not enough. 50 Kb is possible, but the menu will be seriouly limited.
A way that I did not try is to compress Gujin and call an "auto-decompressor" at the end of loading,
keeping the "auto-decompressor" code not compressed. A GZIP-compatible decompression code is already
in Gujin code (7367 bytes in gzlib.o, containing the 1 Kb CRC32 table for 386/486, pentium+ can use
the assembler optimised crc32 function without table). The main reason I do not really want to compress
Gujin is that I would like to be able at some point to install Gujin from itself, so I have to consider
the code segment read-only.
If you want to try, the best starting point is the target CDnoemul-notpatched of Makefile, because
the El-Torito specification says it will load any filesyze at any address, so producing file
"boot.pic" and putting it as a no-emulation El-Torito boot file should work. I do not think I have
ever seen a real CDROM able to load more than few 2048 bytes sectors, but maybe some emulator can
do it. That would prove the file "boot.pic" is really a self contained Position Independant Code, and
works correctly - so that it could be put in some FLASH and either executed directly there or copied
to RAM and executed.
The best idea I have heard is to put this file into the motherboard FLASH, these days there is
plenty of FLASH (4 Mbytes is usual) and there is sometimes directly spare FLASH, or you can free
some by removing BIOS boot graphics and BIOS boot languages. There is some tools available to list
FLASH content organised as "files". They are BIOS manufacturer dependant. I still did not have
time to experiment.
I could give you more pointers as soon as the VPN I need is working again, to access my other Email...
I tried yesterday and my 486 (either DX2 or DX4, I did not check) has no problem,
so I cannot really go further on the problem with your 486.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.