Hi Ben,

On Tue, 25 Jul 2000, Ben Harris wrote:
> > On Tue, 25 Jul 2000, Ben Harris wrote:
> > > In article <Pine.NEB.4.21.0007242158060.5075-100000@rangerover.kasbah> you write:
> > > >My idea was
> > > >f.e. to look if its posible to use the NetBSD/arm26 bootloader and modify 
> > > >it so it will load NetBSD/arm32 on the RiscPC too.
> > > 
> > > _Please_ don't do this!  BBBB is a mess, and what I'd like is for someone to
> > > sort things out to build RISC OS executables linked against libsa so we can 
> > > use the same code as the rest of the world.  That _would_ be worth sharing  
> > > between the ports.
> > 
> > Oeps... hehe... well euuhmm... Mark Brinicombe said the same thing of is
> > initarm() implementation for riscos ... i found your initarm() a lot more
> > clear ! ... thats what got me thinking about it...
> 
> My kernel assumes a sane environment when it starts, which means that all
> the hairiness is in BBBB.  BBBB is the bit that handles getting the kernel
> into contiguous physical memory, but I'd _really_ prefer it written in C
> so it can use libsa to load the kernel off an FFS disc and useful stuff
> like that.

Hehe... guess what i was thinking :) ... i rather have a nice ``hairy''
bootloader that is compiled and edited easily than a recompile of my
kernel without really much kernel-load debugging

> [ea and eb]
> > I compiled in the mbuf alignment patch in the arm32 if_ea.c and if_eb.c
> > and they compile. I'm currently doing speed tests to see if there is a
> > significant performance gain/lossage but i dont think so really.
> 
> Ah.  I needed the patch because without it the NFS_BOOT_DHCP stuff simply
> didn't work.  Does it work on arm32 without the mbuf alignment fixed?  
> This may be a consequence of my compiler changes.

Hmm... never did that i must confess.... i can try if you like...

> > I get a 300 kb/sec :( for FTP and thats quite bad ... dunno why ... i'm
> > gonna check that out...
> 
> The ea driver copies every packet into a temporary buffer first, which is
> likely to be a serious speed lose.  I take it your chip doesn't drop
> packets like mine does then?

Well sometimes it drops packets yes...  but rarely ... I do sometimes get
a timeout :( and then it waits and waits with a dead network and then
starts again. I must say that i havent found those timeouts anymore since
i patched it.... so maybe its fixed now!! and is there some fragment of
code that gets haywire and thus is not grabbing packets ? thus giving a
timeout? would explain the trouble!

Reinoud