[PATCH] sparc64: implement OF memory manager

[Igor Kovalenko]

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: [e-mail]

-- 
Kind regards,
Igor V. Kovalenko

[Blue Swirl]

On Mon, Jul 27, 2009 at 12:19 AM, Igor
Kovalenko<[e-mail]> 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: [e-mail]

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.

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 >

[Igor Kovalenko]

On Mon, Jul 27, 2009 at 11:52 AM, Blue Swirl<[e-mail]> wrote:
> On Mon, Jul 27, 2009 at 12:19 AM, Igor
> Kovalenko<[e-mail]> 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: [e-mail]
>
> 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.
> 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?

-- 
Kind regards,
Igor V. Kovalenko

[Blue Swirl]

On Mon, Jul 27, 2009 at 10:58 AM, Igor
Kovalenko<[e-mail]> wrote:
> On Mon, Jul 27, 2009 at 11:52 AM, Blue Swirl<[e-mail]> wrote:
> > On Mon, Jul 27, 2009 at 12:19 AM, Igor
> > Kovalenko<[e-mail]> 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: [e-mail]
> >
> > 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.

[Igor Kovalenko]

On Mon, Jul 27, 2009 at 12:24 PM, Blue Swirl<[e-mail]> wrote:
> On Mon, Jul 27, 2009 at 10:58 AM, Igor
> Kovalenko<[e-mail]> wrote:
> > On Mon, Jul 27, 2009 at 11:52 AM, Blue Swirl<[e-mail]> wrote:
> > > On Mon, Jul 27, 2009 at 12:19 AM, Igor
> > > Kovalenko<[e-mail]> 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: [e-mail]
> > >
> > > 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