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

Igor Kovalenko igor.v.kovalenko at gmail.com
Tue Jul 28 23:42:49 CEST 2009


On Mon, Jul 27, 2009 at 12:24 PM, Blue Swirl<blauwirbel at gmail.com> wrote:
> 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 >

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 :)

-- 
Kind regards,
Igor V. Kovalenko



More information about the OpenBIOS mailing list