August 29, 2025

Sun 3 bootrom souce - the Sun 3/80 - test the lance driver

What I want to do is to test the lance ethernet driver that I am able to compile from the bootrom source. The only hardware I have with a lance ethernet is my sun 3/80. The idea is not to monkey with the bootrom in my 3/80, but to use that bootrom to boot some standalone code I write. That standalone code will be a build of the minimal source I can prune down to run the lance ethernet driver as if was part of a bootrom.

So what will happen, when this all works, is that the sun 3/80 will network boot my code (using rarp and tftp). Then that code will turn around and do exactly the same thing -- run rarp and tftp to boot some other standalone code. It will need to be "some other" code because it will be loaded to and run at a different address than the 0x4000 that the test standalone will be running at.

Once all this works, I will take the next step (probably) and work up a DHCP client to replace RARP.

Doing all this has been an excellent way to really understand things that go on with the bootrom device drivers, especially the ethernet. It has also been a great chance to dig into some Sun 3/80 details I never looked at closely before.

Status report - 8-29-2025

The first step was to code up "fixture.c" which supplies a variety of things that are present in the bootrom code, but I don't want to import in their entirety. I also pull in inet.c and tftp.c verbatim, making a few minor changes. After a days work, it all compiles without errors.

Testing revealed some surprises with virtual address faults to unexpected addresses. The tftp code simply uses a block of memory at 0x3000 for the data structures it needs (a better scheme would use some kind of allocator). The code as trying to use the 3/160 rom base address to access the romvec table -- this was a simple change.

Now I have added a multitude of printf statements to see what the code is doing. It is trying to do the RARP, sending a packet and awaiting a reply.

I fire up wireshark and am pleased to find that "rarp" makes a perfectly good capture filter. It sees the real bootrom sending a rarp request, and my linux machine replying. But it does not see a second rarp request from my test code (though the printf statements indicate it things it sent a packet), so that is the problem I am now troubleshooting.

DMA addresses

The lance chip exposes itself as two 16 bit registers. It does most of its work by DMA interacting with structures in memory.

The lance chip has a 24 bit addressing capability. So what happens as far as the upper 8 bits in the Sun3 memory world. As near as I can tell this happens: 

on the sun 3/160 the upper 8 bits get set to 0x0f
on the sun 3/80 the upper 8 bits get set to 0xff
The bootrom code uses a simple memory allocator (in monalloc.c) to dole out memory suitable for DMA. It starts (on the 3/80) from a base address of 0xfff0_0000 -- note that the virtual address map has this mapped to physical memory at 0x00ff8000 which is near the top of the actual 16M of physical memory on my sun3/80. This is so for 3 pages (24K) then the mapping does other things. Perhaps 24K is adequate for the lance structures.

On the 3/160 the DMA memory allocator starts off at 0x0ff0_0000, but I have not worked out the full details of the address mapping as I have for the 3/80. But I do know the if_ie.c driver works just fine using that, so I am not worried much about it.

Feedback? Questions? Drop me a line!

Tom's Computer Info / tom@mmto.org