Gujin graphical bootloader 0.4
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 12 lines · Etienne Lorrain
These two files in memory have also to be at fixed linear addresses in real mode - and if you have a memory manager (himem.sys) loaded, these address may not be free. Usually you will find at the bottom of the himem memory the smartdrv (disk cache) data. It is then impossible to load a file at a random memory address and stay in real mode to do futher processing. In this case, Gujin is just malloc'ing the memory (using himem.sys), loading and decompressing this file (checking its CRC32), and only then disable interrupts, switch to protected mode, copy the file at its intended linear address and jump to the kernel code.
hmm.
You say: BIOS/hardware can be broken, let use DOS do load Linux!
IMHO using DOS (himem.sys and letting DOS to setting our hardware in ibmbio.com and ibmdos.com) give us more problem that solution!
We should have complete control to hardware, not letting DOS to hide/modify the BIOS segment 0040:0000 and some other hardware setting.
Thus we should (if possible) use only BIOS call (or directly hardware), but forget DOS. (BTW you know what DOS makes before himem.sys ? Do we have the sources?)
giacomo
--- Giacomo Catenazzi <[email protected]> a écrit :
Quoted 14 lines
Quoted 12 lines · Etienne Lorrain
These two files in memory have also to be at fixed linear addresses in real mode - and if you have a memory manager (himem.sys) loaded, these address may not be free. Usually you will find at the bottom of the himem memory the smartdrv (disk cache) data. It is then impossible to load a file at a random memory address and stay in real mode to do futher processing. In this case, Gujin is just malloc'ing the memory (using himem.sys), loading and decompressing this file (checking its CRC32), and only then disable interrupts, switch to protected mode, copy the file at its intended linear address and jump to the kernel code.
Quoted 3 lines
hmm.
You say: BIOS/hardware can be broken, let use DOS do load Linux!
There are ISA/PCI cards which are initialised before the first sector
of the HD/FD is loaded (SCSI, network boot ROM or special devices), but it is true that they are not usually using memory at 0x100000.
I have just done this relocation thinking that it may be nice to be
able to load a kernel over the 16 Mbytes limit - to free a maximum of space to the 16 Mb DMA-able area (if DMA is 16 Mb only) - but that is stuff for the future because the kernel would be linked at another address. I applied this late-relocation in case of himem.
Quoted 3 lines
IMHO using DOS (himem.sys and letting DOS to setting our hardware in ibmbio.com and ibmdos.com) give us more problem that solution!
I am not able to open the A20 gate in all the ways himem.sys can,
objdump will be your friend here. Note that Linux has never booted on such a special machine - using I/O ports 0x329 or 0x320 to open A20 - I just leave the door open to run from DOS/win, even for beginner who do not know what is himem/emm386 - or people wanting to remote boot Linux from a DOS/win machine getting vmlinuz from the network.
Quoted 3 lines
We should have complete control to hardware, not letting DOS to hide/modify the BIOS segment 0040:0000 and some other hardware setting.
So Gujin will boot from an IDE HD not supported by the BIOS,
on a VGA card without BIOS (or nearly: see VGA_MEMORY compile switch). It can also do what loadlin does - I do not want to maintain two identical software.
Quoted 3 lines
Thus we should (if possible) use only BIOS call (or directly hardware), but forget DOS. (BTW you know what DOS makes before himem.sys ? Do we have the sources?)
Forget DOS/Win - what a dream... Can I join your dream?
Etienne.
___________________________________________________________
Do You Yahoo!? -- Vos albums photos en ligne,
Yahoo! Photos : http://fr.photos.yahoo.com