Out of curiosity, was there any thought is adding this to evbmips
instead of getting its own top-level arch subdir?
emips already has native bootloader and src/distrib files,
so it's enough reason to have own port dir.
to the PowerPC Virtex that lives in arch/evbppc/virtex.
BTW evbppc has
On Fri Jan 28 2011 at 18:05:50 +0900, Izumi Tsutsui wrote:
Out of curiosity, was there any thought is adding this to evbmips
instead of getting its own top-level arch subdir?
emips already has native bootloader and src/distrib files,
so it's enough reason to have own port dir.
additionally, userland is built with MKSOFTFLOAT=yes,
Hmm.
In that case, shouldn't we have different ${MACHINE_ARCH}
for different binaries?
---
Izumi Tsutsui
On Fri Jan 28 2011 at 16:26:50 +0200, Antti Kantee wrote:
On Fri Jan 28 2011 at 23:07:37 +0900, Izumi Tsutsui wrote:
additionally, userland is built with MKSOFTFLOAT=yes,
Hmm.
In that case, shouldn't we have different ${MACHINE_ARCH}
for different binaries?
i think you're right.
pooka@ wrote:
additionally, userland is built with MKSOFTFLOAT=yes,
:
In that case, shouldn't we have different ${MACHINE_ARCH}
for different binaries?
i think you're right. hmm, looking at the build cluster output there
seem to be very few sets shared between mips archs (i don't
On Fri Jan 28 2011 at 23:40:34 +0900, Izumi Tsutsui wrote:
Do you have a naming suggestion? mipsebsf?
hpcmips chose and implemented painful fpemul to avoid such discussion,
IIRC :-)
heh. well, in this case I guess we could implement fpu support in the
CPU to avoid discussions ;)
--
älä
Do you have a naming suggestion? mipsebsf?
hpcmips chose and implemented painful fpemul to avoid such discussion,
IIRC :-)
heh. well, in this case I guess we could implement fpu support in the
CPU to avoid discussions ;)
Heh, indeed, though I'm afraid it will require more FPGA
On Fri, Jan 28, 2011 at 23:40:34 +0900, Izumi Tsutsui wrote:
Only if we will also have non-softfloat mips64?
(as sh3 has only softfloat currently)
Heh, adding FPU support to sh4 kernels is not that much work, but i
never had energy to sit down and figure out how to handle hard vs
softfloat
uwe@ wrote:
Heh, adding FPU support to sh4 kernels is not that much work,
Just FYI,
ftp://ftp.NetBSD.org/pub/NetBSD/misc/nonaka/sh4-fpu/
ftp://ftp.NetBSD.org/pub/NetBSD/misc/nonaka/sh4a/
but i
never had energy to sit down and figure out how to handle hard vs
softfloat userlands :)
---
On 28 January 2011 14:40, Izumi Tsutsui tsut...@ceres.dti.ne.jp wrote:
hpcmips chose and implemented painful fpemul to avoid such discussion,
IIRC :-)
If emips is going to be using softfloat it looks like it could be an
opportunity for hpcmips
machines of the same endian to gain some better
On 01/28/2011 02:05, Izumi Tsutsui wrote:
Out of curiosity, was there any thought is adding this to evbmips
instead of getting its own top-level arch subdir?
emips already has native bootloader and src/distrib files,
so it's enough reason to have own port dir.
to the PowerPC Virtex that lives
evb* method is used for boards/appliances that have
less man power and few variants, I think.
While it avoids clutter, it also tends to bury the lead as it were.
It is harder to know what NetBSD supports and eaiser to pass it by...
It depends. (as I wrote less man power)
It might be
On Jan 28, 2011, at 6:40 AM, Izumi Tsutsui wrote:
pooka@ wrote:
additionally, userland is built with MKSOFTFLOAT=yes,
:
In that case, shouldn't we have different ${MACHINE_ARCH}
for different binaries?
i think you're right. hmm, looking at the build cluster output there
seem to be
Hi, I just got a compile error after the movement of the sysctls.
When having netbsd32 compat on a 64bit machine. A conditional include for
compat/netbsd32/netbsd32.h fixed this, one like in init_sysctl.c
Kind Regards,
Lars
Am 28.01.2011 19:44 schrieb Antti Kantee po...@netbsd.org:
Module Name:
Antti Kantee wrote:
On Fri Jan 28 2011 at 18:05:50 +0900, Izumi Tsutsui wrote:
Out of curiosity, was there any thought is adding this to evbmips
instead of getting its own top-level arch subdir?
emips already has native bootloader and src/distrib files,
so it's enough reason to have
to the PowerPC Virtex that lives in arch/evbppc/virtex.
BTW evbppc has 405 vs oea issue in module.
i have a solution for this i haven't implemented. it basically
involves two things:
- allow a different subdir in the module dir
- re-use the src/compat framework to build
disklabel.h should export nothing to userland and values userland
needs should be obtained via sysctl.
I've been asking this question of various developers for a while.
how do i create a disklabel on a file system image as a normal
user a non-netbsd host with this method?
.mrg.
On Jan 28, 2011, at 3:38 PM, matthew green wrote:
disklabel.h should export nothing to userland and values userland
needs should be obtained via sysctl.
I've been asking this question of various developers for a while.
how do i create a disklabel on a file system image as a normal
On Jan 28, 2011, at 3:25 PM, matthew green wrote:
to the PowerPC Virtex that lives in arch/evbppc/virtex.
BTW evbppc has 405 vs oea issue in module.
evb* method is used for boards/appliances that have
less man power and few variants, I think.
one problem i have with the current way
mrg@ wrote:
to the PowerPC Virtex that lives in arch/evbppc/virtex.
BTW evbppc has 405 vs oea issue in module.
i have a solution for this i haven't implemented. it basically
involves two things:
- allow a different subdir in the module dir
- re-use the src/compat
20 matches
Mail list logo
