freeldr

[Timo Kreuzer]

Hi,

While taking a short break from my GSOC work, I like to do some work on 
freeldr.
Final goal is to make it work with MSVC, but first I'd like to do a 
little cleanup, since its a bit messy.

First I'd like to know how the state of the old bootcode is and if we 
still need it and whats left to do to get rid of it.
Then I'd suggest to remove the code that draws purple unicorns like it 
was done for ARM (afaik, we don't use it anyway)
I'd also like to fix formatting (tabs -> spaces)

Any remarks, objections, wishes, doubts?

Regards,
Timo

[Alex Ionescu]

Last time I tried to do this Brian Palmer went ape-shit :)

Best regards,
Alex Ionescu

On Fri, Jun 10, 2011 at 10:13 AM, Timo Kreuzer [e-mail] wrote:
> Hi,
>
> While taking a short break from my GSOC work, I like to do some work on
> freeldr.
> Final goal is to make it work with MSVC, but first I'd like to do a little
> cleanup, since its a bit messy.
>
> First I'd like to know how the state of the old bootcode is and if we still
> need it and whats left to do to get rid of it.
> Then I'd suggest to remove the code that draws purple unicorns like it was
> done for ARM (afaik, we don't use it anyway)
> I'd also like to fix formatting (tabs -> spaces)
>
> Any remarks, objections, wishes, doubts?
>
> Regards,
> Timo
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Brian Palmer]

Please cite your sources Alex...

I'm all for improving FreeLoader. What bothers me is when people decide they
want to implement something new that breaks something old and they don't fix
it. Did the PE version of FreeLoader ever get fixed with regards to the
fathelper code needed for FAT12/16 support?

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Alex Ionescu
Sent: Friday, June 10, 2011 10:19 AM
To: ReactOS Development List
Subject: Re: [ros-dev] freeldr

Last time I tried to do this Brian Palmer went ape-shit :)

Best regards,
Alex Ionescu

On Fri, Jun 10, 2011 at 10:13 AM, Timo Kreuzer [e-mail] wrote:
> Hi,
>
> While taking a short break from my GSOC work, I like to do some work on
> freeldr.
> Final goal is to make it work with MSVC, but first I'd like to do a little
> cleanup, since its a bit messy.
>
> First I'd like to know how the state of the old bootcode is and if we

still
> need it and whats left to do to get rid of it.
> Then I'd suggest to remove the code that draws purple unicorns like it was
> done for ARM (afaik, we don't use it anyway)
> I'd also like to fix formatting (tabs -> spaces)
>
> Any remarks, objections, wishes, doubts?
>
> Regards,
> Timo
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

_______________________________________________
Ros-dev mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev

[Timo Kreuzer]

Am 13.06.2011 18:07, schrieb Brian Palmer:
> Please cite your sources Alex...
>
> I'm all for improving FreeLoader. What bothers me is when people decide they
> want to implement something new that breaks something old and they don't fix
> it. Did the PE version of FreeLoader ever get fixed with regards to the
> fathelper code needed for FAT12/16 support?

Yes, I just recently added it back.
The image is now composed of 16 bit code in a raw binary chunk prepended 
before the PE file. All 16 bit code is supposed to go in there soon.
Btw, the code was always there, it was only limited in the minimum 
supported cluster size. This limitation is now gone.

[Bernd Blaauw]

Op 10-6-2011 16:13, Timo Kreuzer schreef:
> Any remarks, objections, wishes, doubts?

http://reboot.pro/14412/ lists a modified FreeLDR (for PXE?) and 
CHAIN.C32 (Syslinux multiboot bootloader module).
I'd hope ReactOS can be booted from (FreeLDR on) all of the following 
(ofcourse 1 step at a time at implementation) :
* harddisk (implemented)
* floppy (unsure)
* image of above mentioned floppy, loaded by Syslinux/Memdisk.
* ReactOS ISO (WinVblock driver likely needed as well). Tried it, 
immediate hang on FreeLDR
* ReactOS bootCD extracted to harddisk ( FreeLDR --> 
"C:\ROSSETUP\SETUP.EXE" --> phase 1/2/3)

In other words: does FreeLDR itself access the hardware device to read 
more of itself? Or only once done loading itself and 'mounting' ReactOS 
from harddisk?

[Timo Kreuzer]

Am 13.06.2011 00:40, schrieb Bernd Blaauw:
> http://reboot.pro/14412/ lists a modified FreeLDR (for PXE?) and 
> CHAIN.C32 (Syslinux multiboot bootloader module).
> I'd hope ReactOS can be booted from (FreeLDR on) all of the following 
> (ofcourse 1 step at a time at implementation) :
> harddisk (implemented)
> floppy (unsure)
> image of above mentioned floppy, loaded by Syslinux/Memdisk.

It is possible to store the bootsector on a floppy. You cannot put 
reactos on a floppy.
> ReactOS ISO (WinVblock driver likely needed as well). Tried it,
>
> immediate hang on FreeLDR

I don't understand what you mean. Of course you can boot from the 
ReactOS ISO.
> ReactOS bootCD extracted to harddisk ( FreeLDR -->
>
> "C:\ROSSETUP\SETUP.EXE" --> phase 1/2/3)
>
> In other words: does FreeLDR itself access the hardware device to read 
> more of itself? Or only once done loading itself and 'mounting' 
> ReactOS from harddisk?

On FAT12/16 disks, freeldr uses code to load more of itself, using bios 
calls.

[Bernd Blaauw]

Op 13-6-2011 9:28, Timo Kreuzer schreef:
> It is possible to store the bootsector on a floppy. You cannot put 
> reactos on a floppy.

It is possible yes, just not working right now. Perhaps broken code or 
broken floppy driver.
ReactOS 0.2.7 is able to store FreeLoader (2.0) and bootsector to 
floppy, during the end of phase 1 bootcd ("install bootsector/bootloader 
to MBR, skip, or floppy).
I've not had any luck with earlier (0.2.4 and 0.2.5 tried) or later ones 
(0.3.x , recent trunk builds).
It seems Floppy needs to be 1.44MB as trying with a 360KB floppy drive 
didn't work at end of phase 1 (setup claiming "no disk in drive").
The good news is WinImage happily converts A: (yes, working in VMware, 
with A: being a 1.44MB file) to 360KB, and still ReactOS 0.2.7 can be 
loaded from FreeLDR located on A:
> > ReactOS ISO (WinVblock driver likely needed as well). Tried it,
> >
> > immediate hang on FreeLDR
>
> I don't understand what you mean. Of course you can boot from the 
> ReactOS ISO.

I mean (Syslinux is a bootloader, MEMDISK loads/boots an image in memory)
1) BIOS --> A: bootsector --> Syslinux --> Memdisk --> [360KDISK.IMG --> 
FreeLDR bootsector --> FreeLDR -->] C:\REACTOS\NTOSKRNL.EXE
2) BIOS --> A: bootsector --> Syslinux --> FreeLDR bootsector --> 
FreeLDR --> C:\REACTOS\NTOSKRNL.EXE
3) BIOS --> A: bootsector --> FreeLDR -->  C:\REACTOS\NTOSKRNL.EXE
4) HDD/USB --> Syslinux --> Memdisk --> REACTOS.ISO (install ReactOS 
from an ISO)
5) CD --> Isolinux --> Memdisk --> ReactOS.ISO (install ReactOS from an 
ISO located on multiboot-CD)

Your very recent realmode changes to FreeLDR might make above scenarios 
more doable. However with bootcd's phase 1 being unable to create a 
FreeLoader diskette, I'm kinda stuck.
Already tried replacing diskette's FreeLDR 2.0 by a trunk version but 
that ends with a black screen, not even showing FreeLDR.
I guess either diskette booting isn't supported anymore for recent 
FreeLDR and recent ReactOS, or bootsector changed.

Above scenario's :
1) loads FreeLDR from memory image, gets stuck loading NTOSKRNL. Good to 
see it works partially already at least.
2) not tested yet, but should work easily.
3) tested, works (for FreeLDR 2.0 + ROS 0.2.7)
4) not tested recently, even if loading succesfully, you'd end up in 
protected mode quite fast, only way to find the ISO's contents in RAM 
(and continue installing) is that WinVblock driver
5) not tested

A working implementation of loading/mounting a ISO9660 image file, 
despite protected mode, is Parted Magic (Linux based).

But I guess you and other developers should just continue doing what 
you're good at, undisturbed/undistracted, and at some point we'll see 
PXE-booting working after which above stuff is easier to accomplish as well.

[Ameen Ross]

Most Linux distros nowadays can boot from ISO. Even with persistent changes.
On 06/15/2011 12:43 AM, Bernd Blaauw wrote:
> A working implementation of loading/mounting a ISO9660 image file, 
> despite protected mode, is Parted Magic (Linux based).

[Bernd Blaauw]

Op 15-6-2011 7:17, Ameen Ross schreef:
> Most Linux distros nowadays can boot from ISO. Even with persistent 
> changes.

ah so you're claiming something like this would work out of the box:
label ubuntu1104
kernel memdisk
append iso initrd=ubuntu.iso

To my knowledge, Linux ISO booting consisted of
[A] booting kernel
[B] processing INITRD
[C] mounting CD/DVD/BluRay, or ISO
[D] continuing.

What I mean is only doing C and D, everything has to be self-contained 
in 1 single file
For DOS this goes fine as it doesn't enter protected mode.
For Linux specific adjustments are required (unless working with 
separate kernel and initrd as above)
For Windows and ReactOS as well.

Persistent changes depend on some writable medium (harddisk, usb etc), I 
don't like messing around with that. A single file to load an operating 
system.

Anyway, I'll be quite happy for now if someone can just tell me how to 
create a bootdisk with recent FreeLoader on it, so I can boot recent 
ReactOS (installed on C:\REACTOS) from it.
My guess is finding some bootsector writing software (perhaps WinImage), 
adjusting diskette bootsector followed by copying FreeLDR and its 
freeldr.ini file.
That may be the solution or not, purely depends on if bootsector refers 
to a file on filesystem, or to a specific location/sector (as SYSLINUX 
does, thus ruining DEFRAG and partition resizing).

[Ameen Ross]

> ah so you're claiming something like this would work out of the box:
> label ubuntu1104
> kernel memdisk
> append iso initrd=ubuntu.iso

This is one entry from my multiboot USB drive's GRUB menu:

title Ubuntu Netinstall x86
find --set-root /iso/ubuntunetinstall.iso.gz
map --mem /iso/ubuntunetinstall.iso.gz (hd32)
map --hook
chainloader (hd32)
> To my knowledge, Linux ISO booting consisted of
> [A] booting kernel
> [B] processing INITRD
> [C] mounting CD/DVD/BluRay, or ISO
> [D] continuing.

This is another entry in my menu.lst:

title Kubuntu 10.04
find --set-root /iso/kubuntu-10.04-desktop-i386.iso
map /iso/kubuntu-10.04-desktop-i386.iso (0xff)
map --hook
root (0xff)
kernel /casper/vmlinuz file=/cdrom/preseed/kubuntu.seed boot=casper 
persistent iso-scan/filename=/iso/kubuntu-10.04-desktop-i386.iso splash
initrd /casper/initrd.lz

Both boot methods work just fine.
> What I mean is only doing C and D, everything has to be self-contained 
> in 1 single file
> For DOS this goes fine as it doesn't enter protected mode.

Not entirely true. This is another of the entries in my list:

title FreeDOS Balder Floppy
map --mem /iso/balder10.img.gz (fd0)
map (hd1) (hd0)
map (hd0) (hd1)
map --hook
chainloader --force (fd0)+1
rootnoverify (fd0)

This works fine, as long as I don't boot with HIMEM.

[Bernd Blaauw]

Op 15-6-2011 19:56, Ameen Ross schreef:
>

ah you're using GRUB with some of its internal commands, seems like 
you're quite right, be it due to GRUB, Ubuntu or the combination.
Thanks for your response. I suggest we'll continue this thread sometime 
once ReactOS has the same capabilities of memory loading :)