[ros-diffs] [ros-arm-bringup] 32129: --- FIXED COMMIT LOG FOR r32128. NO CHANGES IN THIS REVISION --- Implement ramdisk support for FreeLDR (ramdisk.c and ramdisk.h). The implementation is portable across all architectures. We also define a virual ramdisk file (hardcoded name is reactos.img, on the boot volume) for testing ramdisk support on architectures without native ramdisk support (such as x86). This could be further extended to allow network booting as a ramdisk at a later time, but is now primarly for test purposes. We introduce two new FreeLDR command-line parameters that should be sent by non-x86 firmware: rdbase and rdsize, and a new freeldr.ini ARC path: ramdisk(0) -- this is compatible with Windows. For compatibility and status output, we use 8MB chunks for reading virtual ramdisk files (a dot is displayed for each additional 8MB chunk). Finally, for code-reuse, the ramdisk implementation will "steal" the BIOS support routines in the arch-vtable and replace them with simple memcpy wrappers. To the disk/filesystem routines in FreeLDR, they think they are reading from the BIOS (or other firmware), but instead, the sector reads are coming from memory). For now, only FAT ramdisks have been tested, and a sector size of 512 bytes is implied. We also disable the FAT block cache since it wouldn't make much sense to cache RAM. *** Note that kernel ramdisk support is missing, so once the kernel attempts to load drivers from the boot device (ramdisk(0)), it will panic. This is currently non an issue on non-x86 builds since the kernel won't get that far for a while.
ros-arm-bringup at svn.reactos.org
ros-arm-bringup at svn.reactos.org
Tue Feb 5 02:39:23 CET 2008
- Previous message: [ros-diffs] [ros-arm-bringup] 32128: Implement ramdisk support for FreeLDR (ramdisk.c and ramdisk.h). The implementation is portable across all architectures. We also define a virual ramdisk file (hardcoded name is reactos.img, on the boot volume) for testing ramdisk support on architectures without native ramdisk support (such as x86). This could be $ We introduce two new FreeLDR command-line parameters that should be sent by non-x86 firmware: rdbase and rdsize, and a new freeldr.ini ARC path: ramdisk(0) -- this is compatible with Windows. For compatibility and status output, we use 8MB chunks for reading virtual ramdisk files (a dot is displayed for each additional 8MB chunk). Finally, for code-reuse, the ramdisk implementation will "steal" the BIOS support routines in the arch-vtable and replace them with simple memcpy wrappers. To the disk/filesystem routines in Fre$ For now, only FAT ramdisks have been tested, and a sector size of 512 bytes is implied. We also disable the FAT block cache since it wouldn't make much sense to cache RAM. $lds since the kernel won't get that far for a while.
- Next message: [ros-diffs] [ros-arm-bringup] 32130: The Windows headers include a file called ioaccess.h in the ddk folder, which exposes various READ/WRITE_PORT/REGISTER_ routines as inlined macros for various architectures (PPC, MIPS, AMD64, IA64, X86), making use of the MSVC compiler-intrinsics (inp, outp, etc). Since ReactOS already has those intrinscs implemented, we've also created an ioaccess.h w32api header file which makes use of them. We can now remove the portio.h and portio.c files in FreeLDR, since there's no more need to duplicate this code. Additionally, this can be also done with the PPC port of FreeLDR or any other architecture, since it doesn't require per-architecture support in FreeLDR anymore -- only the underlying intrinsics in intrin.h must be implemented (note that for PPC, MIPS and ARM, the notion of a port doesn't even exist -- those functions map to register-reading functions, where register basically means memory).
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Author: ros-arm-bringup
Date: Tue Feb 5 04:39:22 2008
New Revision: 32129
URL: http://svn.reactos.org/svn/reactos?rev=32129&view=rev
Log:
--- FIXED COMMIT LOG FOR r32128. NO CHANGES IN THIS REVISION ---
Implement ramdisk support for FreeLDR (ramdisk.c and ramdisk.h). The implementation is portable across all architectures.
We also define a virual ramdisk file (hardcoded name is reactos.img, on the boot volume) for testing ramdisk support on architectures without native ramdisk support (such as x86). This could be further extended to allow network booting as a ramdisk at a later time, but is now primarly for test purposes.
We introduce two new FreeLDR command-line parameters that should be sent by non-x86 firmware: rdbase and rdsize, and a new freeldr.ini ARC path: ramdisk(0) -- this is compatible with Windows.
For compatibility and status output, we use 8MB chunks for reading virtual ramdisk files (a dot is displayed for each additional 8MB chunk).
Finally, for code-reuse, the ramdisk implementation will "steal" the BIOS support routines in the arch-vtable and replace them with simple memcpy wrappers. To the disk/filesystem routines in FreeLDR, they think they are reading from the BIOS (or other firmware), but instead, the sector reads are coming from memory).
For now, only FAT ramdisks have been tested, and a sector size of 512 bytes is implied. We also disable the FAT block cache since it wouldn't make much sense to cache RAM.
*** Note that kernel ramdisk support is missing, so once the kernel attempts to load drivers from the boot device (ramdisk(0)), it will panic. This is currently non an issue on non-x86 builds since the kernel won't get that far for a while.
Modified:
trunk/reactos/boot/freeldr/freeldr/disk/ramdisk.c
Modified: trunk/reactos/boot/freeldr/freeldr/disk/ramdisk.c
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/disk/ramdisk.c?rev=32129&r1=32128&r2=32129&view=diff
==============================================================================
--- trunk/reactos/boot/freeldr/freeldr/disk/ramdisk.c (original)
+++ trunk/reactos/boot/freeldr/freeldr/disk/ramdisk.c Tue Feb 5 04:39:22 2008
@@ -95,7 +95,7 @@
// Get the file size
//
gRamDiskSize = FsGetFileSize(RamFile);
- TuiPrintf("Found virtual ramdisk (%dKB) \n", gRamDiskSize / 1024);
+ TuiPrintf("Found virtual ramdisk (%dKB)\n", gRamDiskSize / 1024);
if (!gRamDiskSize) return;
//
- Previous message: [ros-diffs] [ros-arm-bringup] 32128: Implement ramdisk support for FreeLDR (ramdisk.c and ramdisk.h). The implementation is portable across all architectures. We also define a virual ramdisk file (hardcoded name is reactos.img, on the boot volume) for testing ramdisk support on architectures without native ramdisk support (such as x86). This could be $ We introduce two new FreeLDR command-line parameters that should be sent by non-x86 firmware: rdbase and rdsize, and a new freeldr.ini ARC path: ramdisk(0) -- this is compatible with Windows. For compatibility and status output, we use 8MB chunks for reading virtual ramdisk files (a dot is displayed for each additional 8MB chunk). Finally, for code-reuse, the ramdisk implementation will "steal" the BIOS support routines in the arch-vtable and replace them with simple memcpy wrappers. To the disk/filesystem routines in Fre$ For now, only FAT ramdisks have been tested, and a sector size of 512 bytes is implied. We also disable the FAT block cache since it wouldn't make much sense to cache RAM. $lds since the kernel won't get that far for a while.
- Next message: [ros-diffs] [ros-arm-bringup] 32130: The Windows headers include a file called ioaccess.h in the ddk folder, which exposes various READ/WRITE_PORT/REGISTER_ routines as inlined macros for various architectures (PPC, MIPS, AMD64, IA64, X86), making use of the MSVC compiler-intrinsics (inp, outp, etc). Since ReactOS already has those intrinscs implemented, we've also created an ioaccess.h w32api header file which makes use of them. We can now remove the portio.h and portio.c files in FreeLDR, since there's no more need to duplicate this code. Additionally, this can be also done with the PPC port of FreeLDR or any other architecture, since it doesn't require per-architecture support in FreeLDR anymore -- only the underlying intrinsics in intrin.h must be implemented (note that for PPC, MIPS and ARM, the notion of a port doesn't even exist -- those functions map to register-reading functions, where register basically means memory).
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
More information about the Ros-diffs
mailing list