loongson2f: evbmips or new port ?

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

Hi,
I have a loongson2f-based system (lemote fuulong) booting into sysinst;
ethernet, serial, USB are working, IDE is almost there (I've an
interupt issue that I've worked around with a hugly hack, but I still
hope to have it working properly :)
For now the code is in arch/loongson, based on a few bits from evbmips/gdium,
and from OpenBSD code (OpenBSD supports gdiun, fuulong and others).

The code can easily be turned into evbmips/loongson, but there's
a few things to consider before going one way or another.

First, loongson2 kernels will be 64bits-only. There are some memory and PCI
ressources mapped in physical address above 2Gb and so inaccessible from
32bit kernel unmapped segments. It would probably be possible to
address this using kernel tlb entries, but it would make things much
more complicated, with a posssible run-time cost and no real benefits.
N32 binaries run fine, of course (I've not tested N64 yet).

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

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.

Anyone has ideas on how things should be ?

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