Re: BusBlaster V3c for MIPS?

["Maciej W. Rozycki" <macro%orcam.me.uk@localhost>]

On Sat, 29 Jul 2023, down in the bunny hole wrote:

> > Do you actually want to debug YAMON
> > because something does not work as expected?
> > Or what do you want to achieve?
> 
> two goals
> 1) debug an existing version of YaMon, as it integrates a gdb-stub
> which doesn't work as expected.

 That may well be the case since GDB has moved forward, although back in 
the day it was fine.  We used it for bare-metal regression testing just 
fine.  Have you tried the most recent version of YAMON?  What version has 
the board come with?

> 2) reprogram a second board, as its ROM doesn't contain YaMon but a
> rather custom firmware (probably related to VxWorks but I am not sure)

 That's normally done via the parallel port.  All you need is a 
straight-through (pin-to-pin) male-male DB25-DB25 cable, and of course 
another machine with a parallel port.  Since you write you have two Atlas 
boards, you can well use one to reprogram the other, once you have booted 
it into an OS, with the `cat' command.  Images come as text files in the 
Motorola S-Record format.

 The procedure is described in the manual (it's the same as with Malta: 
essentially you flip the PROG rocker switch, the dot-matrix display will 
show "Flash DL", `cat' the firmware to the parallel port, the display will 
indicate progress, followed by "Complete", at which point you flip the 
PROG switch back to boot the board).  The download process is all handled 
entirely in hardware, by an on-board FPGA chip, so you can't brick the 
board really.

> >  NB Atlas is weird, the Philips STB chip is a quirky PITA
> > which is why we dropped support for this system from Linux long ago.
> 
> I see negative comments on the MIPS wiki against the Atlas board.
> I never owned an Atlas board, yesterday I retrieved two boards
> (different revisions) from an industrial dumpster, but when I was a
> student, we had an Atlas board in our universitary laboratory.

 Lucky you, if I had one I might have revived Linux kernel support, just 
for the sake of schadenfreude!

> I don't have any bad memories about it: around 2009, we didn't run
> GNU/linux on the board (kernel 2.4? 2.6?), we programmed in assembly
> (GNU/AS + GNU/LD) on our host computers (i586 GNU/Linux) and loaded
> the elf binary via ethernet into the board.

 That's the procedure that was used with regression-testing too (though 
test cases were C or C++ programs; I think we didn't have Fortran support 
back then).  Atlas has a SCSI interface too, but I don't remember if it 
could be used to boot an OS.

 YAMON surely had support for ATA (IDE), so maybe you could boot from an 
add-on PCI ATA interface.  Malta surely can boot from onboard ATA, as I 
used it routinely, and a second-stage bootloader has been written by a 
colleague of mine that supports some filesystems (at least EXT2, maybe 
other ones) via the YAMON API.

> We wrote some metal-bare application, compiled static with a simple
> lib-c and a super simple crt0.S, things that used nothing but the CPU,
> the small alphanumeric display on the mobo, the serial and the timer;
> in some lab exercises we also used COP0 for CPU exceptions, and may be
> limited use, but I don't remember anything that wasn't described by
> the book "See MIPS run".
> 
> What's the problem with Atlas?

 I don't remember the exact details anymore as it was 15+ years ago, but 
as I say the issue was with the Philips chip, which was a pain to handle 
in the kernel.  I think it had errata of some kind, making it unreliable 
beyond just being awkward by design.  We surely pulled our hair about it 
and were quite happy to use Malta boards instead.

 For simple bare-metal apps where you could have largely if not entirely
ignored the Philips chip I guess it was OK.  E.g. the dot matrix display 
and the debug UART are both directly accessible via the CPU bus and then 
the so-called CBUS auxiliary CPU core card interface to the mainboard.  
For the regular UART, Ethernet, USB and most other peripherals you need to 
take the PCI route and then via the Philips chip.

 Since you mention MIPS32r2, as a matter of interest, what core cards have 
the two Atlases come with?  CoreLV with a 4KEc CPU?  I guess these would 
be the newest one would ever use with an Atlas, as many later core cards 
were incompatible for some reason, and by then Atlas had been deprecated 
anyway.

  Maciej