[OpenBIOS] [PATCH] sparc64: implement OF memory manager

Blue Swirl blauwirbel at gmail.com
Mon Jul 27 10:24:31 CEST 2009


On Mon, Jul 27, 2009 at 10:58 AM, Igor
Kovalenko<igor.v.kovalenko at gmail.com> wrote:
> On Mon, Jul 27, 2009 at 11:52 AM, Blue Swirl<blauwirbel at gmail.com> wrote:
>> On Mon, Jul 27, 2009 at 12:19 AM, Igor
>> Kovalenko<igor.v.kovalenko at 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 at 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 >
>
> Will look into this.
>
> 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.



More information about the OpenBIOS mailing list