Linux on CRTU-RU (o;

[davorin]

Hmm...at least something on the built-in Screen....no mouse/keyboard yet due to some odd udev problems...

[fisafisa]

Any news?

[Whales]

Are you compiling your own kernel in gentoo or using a precompiled one?  You may find some of the old features are still in the tree, just disabled. 

[davorin]

Always compiled the kernel....I might give NetBSD a chance this weekend....

[fisafisa]

On my part I have reverse engineered part of the hardware interface for the TX/RX board.
So far I have identified that a 2K dual ported RAM is directly mapped on a bus.
There seem also to be at least 18 address bits of which 8 need to have the following bin pattern 110101xx where xx is probably slot dependant. So 0xD4 0xD5 0xD6 0xD7
This ties up with a previous post in this thread!
I suspect the whole protocol is a dialogue between main processor and board processor within the 2K shared ram.

The big FPGA does not seem to play  a role in the bus management.
Only 2 pins connected to it. Maybe clock?

Filippo

[langwadt]

Also useful, under linux, would be a way to map these addresses to user-space, so that one can test things without need to write drivers.

/dev/mem will do that. Something like:

int fd = open("/dev/mem",O_RDWR|O_SYNC);
unsigned char* RxTxMem1 = (unsigned char *) mmap(0, getpagesize(), PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0x000D4000);
unsigned char* RxTxMem2 = (unsigned char *) mmap(0, getpagesize(), PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0x000D5000);

Also, accessing I/O ports from user space is pretty simple:

#include <sys/io.h>
//...
ioperm(0x0100, 0x10, 1);
ioperm(0x0140, 0x30, 1);
//...
uint8_t val8 = inb(0x100); // 8-bit wide read
uint16_t val16 = inw(0x100); // 16-bit wide read
uint32_t val32 = inl(0x100); // 32-bit wide read
outb(val8, 0x100); // 8-bit wide write
outw(val16, 0x100); // 16-bit wide write
outl(val32, 0x100); // 32-bit wide write

Dealing with interrupts from userspace is not as simple. But, writing a very simple driver that can block a userspace process that does a read (or ioctl) on a special file until the interrupt fires isn't that hard. I did it once years ago. The "Linux Device Drivers" O'Reily book is a pretty good resource for these things.

you have to be root to just map mem

the UIO driver maps a memory area for user space and give you interrupt  with a blocking read

[senseless]

Any news, @davorin or @fisafisa? Should have some spare time the next few days and want to do similar stuff.

[senseless]

Just to let you know, after some fiddling around, X is sort of running (will have to add some y shift obviously ).

[fisafisa]

no progress here.
Just using the uinit as is.
How did you achieve this?
Next step would be to try run the dos software under emulation, but would it be able to access the bus?

Good work anyway.

F

[senseless]

Got it working now

Well, it was a lot of trial and error in the end. First, installing it was a pain, cause I had no medium to boot from (USB sticks not working, USB-CDROM/USB-FDD would). I ended up using unetbootin with the harddrive install option on the win2k partition.
Then, i compiled an additional kernel module for the graphics unit (don't actually know if that was necessary in the end, have to test it..). And in the end a lot of trying different xorg.confs, Modeline settings and grub2 parameters.
Regarding emulation, yes, that is the next step now. I am not really sure what the best option would be. After talking to the QEMU guys, they don't have support for ISA passthrough, although that shouldn't be to hard to implement rudimentary if there are no interrupts involved (I don't think there are any for the interesting boards, win2k drivers only show I/O and mem (except for the MacSpeech board?)). Getting DOS running in QEMU is easy though.
Dosemu (abandoned, dosemu2 is active) on the other hand could potentially have support for it, but it is much harder to get DOS running there...

[markus_jlrb]

@senseless

are you willing to share the configured linux image or
the configure/make Files to build it as well as grub2
config ;-)

Markus
Owner of a CMU200
See posts in https://www.mikrocontroller.net/topic/433164#6262821

[senseless]

Yeah, sooner or later I will release some additional info on how to replicate it on your machine, but it is still a mess..

During reverse engineering the software of the "cmud" executable (of V5.21), I came across some password protected functions, namely "eep_wrtsrncmu" (write serial number??) and "eep_sbhoc" (no idea what it means). Didn't take too long to figure out the passwords: "CIVIDARHSP" ( ) for the first and "weissbier" for the second. Who would have guessed that considering that Rohde&Schwarz is based in Munich, Bavaria

[RShacker]

Finally with my own account now...
So after reverse engineering the hack out of the 'cmud' executable (I guess I spent ~200 hours on it...), I finally got a good understanding of how it is communicating with the hardware.
As a short and quick proof, here is a video of the worlds most famous application 'blinky':

[fisafisa]

Cool!

Looking forward to read more about this.
It would be great if we can get a bit more about that device.

Filippo

[fisafisa]

Hi.
I did not know about cmud.exe DOS program.
I found the only other reference in some elektor chat logs.

So are you running the original cmud on Linux, or did you make a Linux version?

Ciao

[RShacker]

If you are running the regular DOS program, you can press alt+f4 and you will end up on the DOS command line interface. IIRC under C://CMU/BIN_V5.21/TOOLS you can find the cmud.exe. It stands for CMU Debugger and you have the possibility to setup different hardware parts separately, get some hardware and version information, read some EEPROMs and so on. As it does not contain any GUI stuff, is much smaller than the full GUI DOS program (base.exe), and you can infer what part of the code is doing what from the available commands (and allowing to run them separately), I started reverse engineering that executable.

And no, what I have shown is completely rewritten based on the RE findings. Currently, the MMIO an I/O Ports stuff is working; some I2C communication is work in progress.

[fisafisa]

Good idea.
reverse engineering a simple test program is certainly easier.

In any case, what is your plan?
What objective are you trying to achieve?

The knowledge your are obtaining may come useful in repairing one of these units in the future.
So please consider sharing it.

Nice job in any case.
Filippo