Linux on CRTU-RU (o; - Page 1
Forum section: electronics / testgear

author: davorin
author_rank: Unknown
timestamp: October 31, 2015, 07:22:11 pm
content: Now had a Little time to preinstall latest Debian 8 on a 2.5 IDE drive and put it into my CRTU-RU...Of course it boots...but fails starting XWin (o;Output of lspci:Code:root@crtu:~# lspci00:00.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and Memory Controller Hub (rev 04)00:02.0 VGA compatible controller: Intel Corporation 82815 Chipset Graphics Controller (CGC) (rev 04)00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 12)00:1f.0 ISA bridge: Intel Corporation 82801BA ISA Bridge (LPC) (rev 12)00:1f.1 IDE interface: Intel Corporation 82801BA IDE U100 Controller (rev 12)00:1f.2 USB controller: Intel Corporation 82801BA/BAM USB Controller #1 (rev 12)00:1f.3 SMBus: Intel Corporation 82801BA/BAM SMBus Controller (rev 12)00:1f.4 USB controller: Intel Corporation 82801BA/BAM USB Controller #1 (rev 12)01:08.0 Ethernet controller: Intel Corporation 82801BA/BAM/CA/CAM Ethernet Controller (rev 03)01:0a.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Controller

author: ivaylo
author_rank: Frequent Contributor
timestamp: November 01, 2015, 05:56:40 am
content: What's the plan? You think you can use it under Linux?

author: davorin
author_rank: Unknown
timestamp: November 01, 2015, 08:29:30 am
content: Exactly..that's the plan....probably be finished by 2025 (o;

author: briselec
author_rank: Regular Contributor
timestamp: November 01, 2015, 10:54:00 am
content: XWin?

author: davorin
author_rank: Unknown
timestamp: November 01, 2015, 10:59:25 am
content: Not planned...problem is currently that X11 is unusable due to i815 driver errors....Someone remember the internal IP address of the PowerPC board? Was it 10.4.4.4 or something?

author: dom0
author_rank: Super Contributor
timestamp: November 01, 2015, 11:47:02 am
content: Quote from: davorin on November 01, 2015, 10:59:25 amnmap is your friend. Put the main machine in the 10.0.0.0/8 net and scan the entire net. Scan while take a while (16M hosts), but it'll show up eventually.

author: Wuerstchenhund
author_rank: Super Contributor
timestamp: November 01, 2015, 04:25:37 pm
content: Quote from: davorin on November 01, 2015, 08:29:30 amIf you want to control the CRTU under Linux then the first steps should be to find out what the DOS software does, i.e. which firmware binaries are loaded into what module, what commands does it use to control the modules, how does the software get the data from the modules, what are the software interfaces and so on. You'd need a debugger and disassembler and other utilities but they should be freely available.Only after you've done that you can start building a new front end under Linux. Just installing Linux and dabbling in the dark is unlikely to get any useful results on an instrument that complex.QuoteThe i815 should work just fine under Linux but may need some manual changes to the X11 config as the LVDS display in CRTU/CMU200 doesn't provide EDID information and the driver might therefore be unable to set the correct video settings for the LCD.

author: davorin
author_rank: Unknown
timestamp: November 01, 2015, 05:48:34 pm
content: Well..i815 support was dropped in recent Mesa implementations...But first of all I need to find a Linux distro and kernel where /dev/fb0 is supported...next try will be Gentoo and Archlinux...after Debian 6/7/8 (o;I don't se the need for X11 at all....

author: Wuerstchenhund
author_rank: Super Contributor
timestamp: November 01, 2015, 06:19:22 pm
content: Quote from: davorin on November 01, 2015, 05:48:34 pmMaybe, but what for do you need Mesa 3D (OpenGL) on a test instrument? Basic X11 should be just fine.QuoteSo how do you want to do the UI then? I hope you're not considering some text mode cludge because that will most likely end up looking like shit (and if it looks like shit and isn't better then the current DOS software then you're unlikely to attract many supporters for your project).You'd most certainly need X11 (not necessarily MESA) for the UI, plus it provides an easy way for remote control. And the i815 graphics shouldn't be any hindrance.But as I said before, all that is pretty irrelevant if you haven't found out how to control the CRTU's hardware modules first.

author: davorin
author_rank: Unknown
timestamp: November 01, 2015, 06:57:21 pm
content: I install osx86 on it *lolNo seriously....X11 might be useful as it would enable to use it remotely just like on the HP 16702A and others...BTW: Which role plays the LPT dongle at the back? Is it for both DOS and Windows part?

author: Wuerstchenhund
author_rank: Super Contributor
timestamp: November 01, 2015, 07:09:21 pm
content: Quote from: davorin on November 01, 2015, 06:57:21 pmExactly.QuoteThe dongle is for certain parts of the Windows software, it shouldn't be required for the DOS software.

author: briselec
author_rank: Regular Contributor
timestamp: November 01, 2015, 08:42:55 pm
content: I don't think a different distro will make any difference. It's not creating a framebuffer device because it can't detect what monitor you are using. See if it's got an i810fb module and try loading that.

author: davorin
author_rank: Unknown
timestamp: November 01, 2015, 09:09:05 pm
content: Well it doesn't...though it's compiled into the kernel...nothing to see in the "dmesg" output....Some "mtrr" errors are seen though on X11 startup...Well speaking of Linux distros....there are huge differences...that's why I never use Linux for a server...especially not for internet services...that's why we used always FreeBSD at internet companies here in Switzerland...and I still use FreeBSD (o;But I don't wanna start a Linux/BSD war here (o;

author: Wuerstchenhund
author_rank: Super Contributor
timestamp: November 01, 2015, 10:29:54 pm
content: Quote from: davorin on November 01, 2015, 09:09:05 pmMaybe you should stick with some older Linux distro anyways as the CRTU/CMU200 is based on ISA, and I'm not sure how much of the ISA support has been kicked out in newer kernels.I'd give some older openSUSE a try.

author: davorin
author_rank: Unknown
timestamp: November 06, 2015, 05:08:20 pm
content: Finally some more time after spedning few days in sunny "Sauerland" (o;Seems Gentoo Linux is currently the best distro....at least I could boot a compiled kernel...now doing a reinstall of gentoo on a CF Card which then goes with an IDE/CF Adapter inside the CRTU-RU (o;This is what the WinNT device Manager tells about the R&S Drivers/boards:Code:R&S Digital Board DriverI/O0100 - 010FI/O0140 - 016FI/O0178 - 01BFCode:R&S IQIF Board DriverI/O11E0 - 11EEI/O21E0 - 21EEI/O31E0 - 31EEI/O41E0 - 41EEI/O51E0 - 51EEI/O15E0 - 15EEI/O25E0 - 25EEI/O35E0 - 35EEI/O45E0 - 45EEI/O55E0 - 45EEI/O01E0 - 01EFI/O05E0 - 05EACode:R&S Link Handler DriverI/O01C0 - 01C7I/O01C8 - 01CFI/O0290 - 029FI/O02B0 - 02BFI/O0320 - 032FI/O0340 - 034FI/O03A0 - 03AFI/O05C0 - 05C7I/O05C8 - 05CFI/O0690 - 069FI/O06B0 - 06BFI/O07A0 - 07AFI/O0B20 - 0B2FI/O0B40 - 0B4FI/O0BA0 - 0BAFI/O0FA0 - 0FAFMemory000D6000 - 000D6FFFMemory000D7000 - 000D7FFFCode:R&S Mac Speech Board DriverI/O0330 - 033FI/O0350 - 035FI/O0730 - 073FI/O0740 - 074FI/O0A90 - 0A9FCode:R&S MC 2000 DriverIRQ11Code:R&S Rx Tx Board DriverMemory000D4000 - 000D4FFFMemory000D5000 - 000D5FFF

author: davorin
author_rank: Unknown
timestamp: November 08, 2015, 12:33:21 pm
content: Well...remote launching of X programs works now (o;But still no LCD Screen or out-of-sync Messages on external VGA Monitor....

author: fisafisa
author_rank: Regular Contributor
timestamp: November 08, 2015, 04:56:52 pm
content: ...For all the memory mapped boards, it would be very good to be able to read back the memory....after initialisation.I wonder if there are ways to intercept the IO calls and log them too.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.Just some ideas.Filippo

author: nctnico
author_rank: Super Contributor
timestamp: November 08, 2015, 07:49:22 pm
content: Perhaps you can run some kind of DOS mode VM which can capture/log all the memory transactions. This may actually be easier using Windows and a debugger.

author: Wuerstchenhund
author_rank: Super Contributor
timestamp: November 08, 2015, 09:23:38 pm
content: Quote from: fisafisa on November 08, 2015, 04:56:52 pmWell, there's stilldebug:http://thestarman.pcministry.com/asm/debug/debug.htm

author: fisafisa
author_rank: Regular Contributor
timestamp: November 08, 2015, 10:24:46 pm
content: Dosemu seems promising.It has the ability to pass-through IOs apparently.And look and behold what the author writes in the plugin section:"For what can plug-ins be used?------------------------------The main reason I implemented 'plugin' was the need to write a DOS driver forsome (very) special selfmade Hardware, which nobody else would profit fromexcept my employer ... and because I was too lazy to patch in the changes toevery new released dosemu version;-) This way DOSEMU atleast profits from theinterface.Having it now, I see some more usage such as- DOS drivers using 32-bit written by contributorsand distributed separately.- special debugging code to reverse engineer (DOS) drivers for specialhardware, if the manufacturer does not cooperate in writinga Linux driver. Also with this, distributing separately can avoidcopyright conflicts.- Replacements for DOS system commands, which (via inte6) then runfaster in 32-bit or can do things which aren't possible otherwise.- Drivers for video chips we currently do not support.We even may consider to move more of our current code into plugin(as we just did with the keyboard code), this would make it possible todistribute them separately. It may be necessary to add some more hooks(plugin_*.h), but for this we wait what happens;-)"

author: davorin
author_rank: Unknown
timestamp: November 09, 2015, 07:27:17 pm
content: Hmm...cvt tool doesn't help get an X display on the built-in LCD or external VGA....Guess some DSO hookup to the VGA signals and calculate the ModeLine values by hand...well if the LCD and VGA signals share the same timing...

author: kfitch42
author_rank: Frequent Contributor
timestamp: November 09, 2015, 08:01:42 pm
content: Quote from: fisafisa on November 08, 2015, 04:56:52 pm/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 readuint16_t val16 = inw(0x100); // 16-bit wide readuint32_t val32 = inl(0x100); // 32-bit wide readoutb(val8, 0x100); // 8-bit wide writeoutw(val16, 0x100); // 16-bit wide writeoutl(val32, 0x100); // 32-bit wide writeDealing 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.

author: davorin
author_rank: Unknown
timestamp: November 09, 2015, 08:04:59 pm
content: Ah nice...Long time I wrote kernel drivers...back then in good old 2.0.x/2.4.x times with uClinux and a few MBytes RAM (o;

author: fisafisa
author_rank: Regular Contributor
timestamp: November 09, 2015, 08:40:06 pm
content: My idea was to see whether we can run the dos apps in linux....and even better if we can record the traffic between the application and the hardware...Ciao

author: davorin
author_rank: Unknown
timestamp: November 09, 2015, 08:45:24 pm
content: Never used "dosbox" nor "dosemu"....and if they support some sort of "hardware hooks"...

author: davorin
author_rank: Unknown
timestamp: November 14, 2015, 05:12:04 pm
content: Hmm...at least something on the built-in Screen....no mouse/keyboard yet due to some odd udev problems...

author: fisafisa
author_rank: Regular Contributor
timestamp: November 27, 2015, 11:10:13 pm
content: Any news?

author: Whales
author_rank: Super Contributor
timestamp: November 27, 2015, 11:22:08 pm
content: 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.

author: davorin
author_rank: Unknown
timestamp: November 28, 2015, 09:36:36 am
content: Always compiled the kernel....I might give NetBSD a chance this weekend....

author: fisafisa
author_rank: Regular Contributor
timestamp: November 29, 2015, 05:49:15 pm
content: 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 0xD7This 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

author: langwadt
author_rank: Super Contributor
timestamp: November 29, 2015, 07:02:23 pm
content: Quote from: kfitch42 on November 09, 2015, 08:01:42 pmyou have to be root to just map memthe UIO driver maps a memory area for user space and give you interrupt with a blocking read

author: senseless
author_rank: Contributor
timestamp: April 26, 2020, 03:05:01 pm
content: Any news, @davorin or @fisafisa? Should have some spare time the next few days and want to do similar stuff.

author: senseless
author_rank: Contributor
timestamp: May 04, 2020, 07:37:36 pm
content: Just to let you know, after some fiddling around, X is sort of running (will have to add some y shift obviously).

author: fisafisa
author_rank: Regular Contributor
timestamp: May 04, 2020, 07:53:47 pm
content: 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

author: senseless
author_rank: Contributor
timestamp: May 04, 2020, 10:37:13 pm
content: Got it working nowWell, 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...

author: markus_jlrb
author_rank: Regular Contributor
timestamp: May 13, 2020, 10:54:30 am
content: @senselessare you willing to share the configured linux image orthe configure/make Files to build it as well as grub2config ;-)MarkusOwner of a CMU200See posts inhttps://www.mikrocontroller.net/topic/433164#6262821

author: senseless
author_rank: Contributor
timestamp: May 14, 2020, 09:18:23 pm
content: 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

author: RShacker
author_rank: Newbie
timestamp: June 28, 2020, 09:19:05 pm
content: 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':

author: fisafisa
author_rank: Regular Contributor
timestamp: June 29, 2020, 10:29:58 pm
content: Cool!Looking forward to read more about this.It would be great if we can get a bit more about that device.Filippo

author: fisafisa
author_rank: Regular Contributor
timestamp: July 02, 2020, 10:28:14 pm
content: 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

author: RShacker
author_rank: Newbie
timestamp: July 11, 2020, 11:35:15 am
content: 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.

author: fisafisa
author_rank: Regular Contributor
timestamp: July 12, 2020, 08:07:03 pm
content: 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

author: snickers
author_rank: Contributor
timestamp: June 15, 2024, 04:38:06 pm
content: Quote from: RShacker on July 11, 2020, 11:35:15 amAlso working with this reverse.The beginning ... of every true embedder - switch LED on.Ported to PASCAL/LAZARUS

author: RShacker
author_rank: Newbie
timestamp: August 10, 2024, 08:27:04 pm
content: Ah, very cool. I also used Ghidra for RE. I actually only noticed this due to your PM and by logging into the mail account used for this forum ("spam mail account") by accidentMy plan back then was using it more freely than what is possible with the integrated SW, i.e. on-device |S21| measurements by sweeping the RF-Gen for example. Dream target was implementing a GNU Radio integration. However, life happened and I could not continue..I don't remember much, but maybe the developments I did back then could help you guys. Therefore, I just made the git repo public:https://github.com/dos4boss/cmudAs I am unfamiliar with DOS/WIN, this is targeted for the Linux I had running on the device.

author: voltsandjolts
author_rank: Unknown
timestamp: September 20, 2025, 04:27:54 pm
content: Quote from: davorin on November 01, 2015, 08:29:30 amRunning outa time, 2025 is almost finished