Re: loongson2f: evbmips or new port ?

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

Hello,

On Wed, 10 Aug 2011 23:55:25 +0200
Manuel Bouyer <bouyer%antioche.eu.org@localhost> wrote:

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

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

have fun
Michael