Re: loongson2f: evbmips or new port ?

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

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

>  
> > 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.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--