Re: loongson2f: evbmips or new port ?

[Michael <macallan1888%gmail.com@localhost>]

On Thu, 11 Aug 2011 12:49:17 +0200
Manuel Bouyer <bouyer%antioche.eu.org@localhost> wrote:

> On Wed, Aug 10, 2011 at 10:20:35PM -0400, Michael wrote:
> > > [...]
> > > Next, there may be userland compile-time options issues: earlier 
> > > loongson2f
> > > processors needs a workaround in software for processor hang, for both
> > > kernel and userland binaries (nop should be remplaced with or at,at,zero,
> > > this is what gas' -fix-loongson2f-nop option does. Only earlier loongson2f
> > > are affected (mine seems not have this problem) so maybe we can just
> > > ignore the issue, or build all evbmips64 binaries with this option
> > > (-fix-loongson2f-nop has ~no runtime performance impact, and should
> > > have no bad effect on any processor but who knows ...)
> > 
> > Mine seems to need it - even with your patches applied init hangs pretty 
> > much immediately ( I used o32 binaries from releng ).
> > I'll check what happens with n32 and -mfix-loongson2f-nop, a kernel built 
> > with this option hangs immediately as well.
> 
> How does your CPU show up ?
> Mine is:
> cpu0 at mainbus0: 800.02MHz (hz cycles = 4000100, delay divisor = 400)
> cpu0: ICT Loongson 2F CPU (0x6303) Rev. 0.3 with MIPS R4010 FPC Rev. 0.1
> cpu0: 64 TLB entries, 1TB (40-bit) VAs, 1TB (40-bit) PAs, 16MB max page size
> cpu0: 64KB/32B 4-way set-associative L1 instruction cache
> cpu0: 64KB/32B 4-way set-associative write-back L1 data cache
> cpu0: 512KB/32B 4-way set-associative write-back L2 unified cache
> bonito0 at mainbus0: BONITO Memory and PCI controller, ASIC rev. 0.1

cpu0 at mainbus0: 891.80MHz (hz cycles = 4459000, delay divisor 446)
cpu0: ICT Loongson 2F CPU (0x6303) Rev. 0.3 with MIPS R4010 FPC Rev. 0.1
the rest is identical to yours.

> > > loongson2 system use pmon as firmware 
> > > (http://www.opsycon.se/PMON2000/Main).
> > > The pmon version provided by lemote can load ELF files from ext2fs, fat or
> > > iso9660; the partition table is fdisk-style (MSDOS).
> > > It looks like there's no way to load from other disk format
> > > (say, get the first 512 bytes of the disk executed).
> > > This mean we have to keep a small ext2 partition at the beggining of 
> > > drive,
> > > which holds the NetBSD kernel or a NetBSD bootloader.
> > > Does anyone know if there is space in a MBR to store a disklabel ?
> > > evbmips uses:
> > > #define LABELSECTOR     0                       /* sector containing 
> > > label */
> > > #define LABELOFFSET     64                      /* offset of label in 
> > > sector */
> > > is it compatible with a MBR ?
> > > 
> > > at the very last, fdisk and mount_ext2fs needs to be included in the
> > > install ramdisk. If LABELSECTOR or LABELOFFSET has to be changed for
> > > loongsoon, it will be much more tricky to keep it in under evbmips.
> > > 
> > > For the record, it looks like OpenBSD uses a x86-like partitionning 
> > > scheme,
> > > with a OpenBSD parititon in the MBR and the disklabel in the OpenBSD
> > > partition.
> > 
> > I don't see a need to re-invent the wheel here - the firmware uses PC-style 
> > partitioning, there's a drop-in replacement for disksubr.c which does The 
> > Right Thing(tm) for us here ( which GDIUM uses already ), why not use a 
> > PC-style disklabel inside an MBR partition?
> 
> How does disklabel(8) deal with it then ?
> sbin/disklabel/Makefile has a list of MACHINE for which disklabel is
> compiled with -DUSE_MBR but evbmips is not there.
> Note that USE_MBR only changes the default value of a flag, so
> it may be possible to set it contidionally on a sysctl value.

Needs to be added I guess - I formatted an SD card on an amd64 box for use with 
the gdium.
So far I only worried about the kernel reading the disklabel which works just 
fine.

have fun
Michael