On Mon, Jul 27, 2009 at 12:24 PM, Blue Swirlblauwirbel@gmail.com wrote:
On Mon, Jul 27, 2009 at 10:58 AM, Igor Kovalenkoigor.v.kovalenko@gmail.com wrote:
On Mon, Jul 27, 2009 at 11:52 AM, Blue Swirlblauwirbel@gmail.com wrote:
On Mon, Jul 27, 2009 at 12:19 AM, Igor Kovalenkoigor.v.kovalenko@gmail.com wrote:
This patch implements OF memory manager. I used arch/ppc/qemu/ofmem.c as a starting point, future plans in ofmem area would be to migrate common parts from working implementations (ppc and sparc64) into common module.
Client interface handler now uses ofmem implementation instead of walking hardware translation tables. Since setup code in entry.S does install it's own translations ofmem initialization routine simply copies entries from hardware. Properties "available" and "translations" are then populated as needed.
This implementation passes boot test with no visible changes on screen for HelenOS-0.4.0-sparc64.iso Linux boot does not get any further with this patch due to conflicts with memory mappings in low memory region.
Signed-off-by: igor.v.kovalenko@gmail.com
Great work, thanks! There are a few problems though.
It breaks PPC because of the changed prototypes for ofmem_map and ofmem_translate. It's safe to change the PPC implementations to use ulong too because int and ulong are the same size there.
I'll set up ppc cross and will fix ppc breakage.
I'd recommend binutils 2.18, configured for powerpc-elf and gcc 4.2.4: Using built-in specs. Target: powerpc-elf Configured with: ../configure --target=powerpc-elf --disable-nls --disable-threads --enable-languages=c --disable-shared --enable-multilib --disable-libssp Thread model: single gcc version 4.2.4
Code that is commented out should be removed.
get_hash_size uses PPC mfsdr1.
SPITFIRE_* should probably go to arch/sparc64/spitfire.h.
There's quite a lot of debug output to serial console, that should be limited to CONFIG_DEBUG builds in the future but at this point it doesn't matter too much.
Aurora 2.0 shows some difference:
Without the patch: boot: Allocated 8 Megs of memory at 0x40000000 for kernel Loaded kernel version 2.6.13 Loading initial ramdisk (2522576 bytes at 0xC00000 phys, 0x40C00000 virt)... \ Remapping the kernel... done. Registering callbacks... va>tte-data:interpret: exception -13 caught .soft1:interpret: exception -13 caught .soft2:interpret: exception -13 caught done. Booting Linux...
With the patch: boot: map_page_range 0000000040000000 -> 0000000000400000 00800000 mode 27 Allocated 8 Megs of memory at 0x40000000 for kernel Loaded kernel version 2.6.13 map_page_range 0000000040c00000 -> 0000000000c00000 0026a000 mode 27 Loading initial ramdisk (2522576 bytes at 0xC00000 phys, 0x40C00000 virt)... ofmem_unmap 0000000040c00000 269fff unmap_page_range found 0000000040c00000 -> 0000000000c00000 0026a000 mode 27 map_page_range 0000000000400000 -> 0000000000400000 00800000 mode 32 mapping mode altered mapping mode altered
Strange OBP version `OBP 3.10.24 1999/01/01 01:01'. EXIT 0 >
There is an issue with qemu, in that disrupting traps are not finishing conditional code evaluations. I posted a patch fixing that to qemu list, I now can see Booting linux as well.
Can you please install the largest part (ofmem_sparc64.c and ofmem_sparc64.h) into svn trunk so I can post smaller changes then?
I don't see how the patch can be split so that it doesn't break anything. Committing just the files but not use them does not seem useful.
I'd recommend using quilt (maybe with gquilt GTK front end), then it's easy to shuffle patches and splitting patches is possible by duplication. It's no match to Git + STGit + QGit though.
I'm trying to post self-contained changes, still git is on it's way :)