My old ass is having the hardest time with the Linux 6.2 series, we were looking at 2.6.x from 2004-2011 (and then for years after on ancient Debian Stable and RHEL-like systems that remained in production forever; I think I … Continue reading →
Since I recently got my HP Apollo 9000 Series 735 up and running, and it’s March, I decided to have a little Marchintosh fun and load MAE (the Macintosh Application Environment, a real officially-licensed Apple product) on to it this evening. As you can see from the photo (because I don’t have a device that can capture the video this thing outputs, and haven’t figured out screenshots under HP-UX 10.20), it works.
Over a year ago I started working on an inert HP Apollo 9000/735 a friend gave me from their collection to avoid moving it cross-country. I’ve recently got it working, and am posting notes about the fun.
At the end of my first post about it, I had recapped the power supply, but had not found a monitor that would talk to the enormousCRX-24z video board with its 1280×1024@72Hz Sync-on-Green via 3x BNC output, or verified the condition of the discs. As you can see from the splash image, all of those things have been remedied.
I spent the last two afternoons procrastinating from other work doing a deferred maintenance project, porting the labs for UK’s CPE287 Introduction to Embedded Systems from the “V5” armcc to the “V6” armclang compiler, since the most recent releases of Keil (the IDE we use in the class) have dropped support for the older compiler, and all our materials were written against V5. It has been a somewhat interesting porting exercise for a “same vendor, same platform” situation.
We have some slightly unusual circumstances: First, because the class starts in writing pure assembly, proceeds through manual bit manipulation in C, and eventually starts to write high-level software driver model code, we hit all the styles and interfaces. Secondly, we have an inexpensive textbook and supporting materials we rather like, but all the examples use the old style assembly syntax, which differs significantly from the more modern GCC/LLVM style, and for pedagogical consistency reasons we’d like to write our code in that style.
For the time being, Keil with the V6 toolchain includes the older armasm binary, so separate pure-assembly .s sources written in the old syntax can still be ingested, you only have to port inline assembly.
Keil’s debugger doesn’t appear to be able to keep source lines of inline assembly and the disassembly view synchronized for GCC-style inlined assembly the way it could with armcc. Unfortunate, and a bit klutzy for setting breakpoints, but not a deal-breaker.
armclang defines __ARMCC_VERSION as 6something so various pieces of existing code have pre-processor directives that will decide to use the armcc style inline assembly instead of the gcc style ones. Particularly irritating, TI’s first party TivaWare library has this problem in both cpu.c and sysctl.c, so I had to make a hacked version with the #ifdef s swirled around appropriately. The code in TivaWare intended for IAR ewarm is suitable for armclang … as long as you remove some spare ewarm-specific pragmas embedded here and there for suppressing return value warnings; I ended up putting -Wno-return-type in the extended compiler options for projects depending on those files.
armclang is much more aggressive about optimization by default than armcc was. In particular, you could get away without marking variables used in busy wait loops or ISRs volatile in armcc, and armclang will happily optimize them out if you forget.
armclang is more vocal about implicit type conversion than armcc, especially where it might affect signedness. This is triggered a lot by the REGISTER_NAME &= ~0xMASK bit-specific addressing idiom. I sprinkled in lots of UL suffixes on literals to avoid the issue.
Long term we might try to get off of Keil, though my experiences with CodeComposerStudio have been sufficiently frustrating that I’m in no hurry to move to it for the TI TivaC boards we’ve been using, and while I like ST’s Cube environment, it would both be a major change of materials and a potential supply-chain nightmare (when is the last time you saw a legitimate major electronics vendor with STM32 parts in a stock status other than “Expected Date: Eventually”?)
The Latitude E7250 I’ve been carrying around since 2017 is one of my favorite machines I’ve ever had; it’s small, robust, has perfect hardware support under Linux… and is starting to get a little too feeble for some tasks I’d like to use it for, experienced a few spurious shutdowns, and has a screen crack causing delamination.
I continue to be a fan of having a small, relatively inexpensive machine for carrying around, and a believer in “The only Dell laptops with acceptable build quality start with a 7”, so in the tradition of the $400 for a refurb and RAM upgrade I spent on the E7250, I ordered one of its more-or-less direct successors, a refurbished Latitude 7390 on a half-off sale a few weeks ago for about $470.
After a few weeks, it looks to be an excellent successor. Nitpicky details and comparisons below the fold.
Setting up a new machine, I was reminded that the default Firefox tab style after 89 is “utter lack of visual separation, but with lots of useless empty space.” I’ve hacked sloppy solutions on several other machines, but it looks … Continue reading →
I have an Onn Surf 8 (One of the surprisingly-not-that-shitty ultra-cheap Walmart tablets) that my research group bought a couple of to use as Android dev testbeds. I’ve been occasionally using it as a normal tablet since I have it around, and have been consistently irritated by the collection of bloatware it comes with…. so I decided to hack it. To tl;dr this whole thing, ignore the collection of typically scammy Android dev forum and blogspam crud, and use the open-source mtkclient for your MediaTek Android device hackin’ needs.
I’ve wanted a hard-copy terminal for a while – both to play with and to use for explaining why serial works the way it does, but they tend to be expensive. Most of the common hard-copy terminals also aren’t really convenient objects to own: loud desk-sized machines (Teletype 33 family, most DECWriters), additionally clockwork nightmares (IBM 2741, earlier Teletype devices), which speak ridiculous protocols (…ditto). This only leaves a handful of reasonable options, the most common of which are portables like TI Silent 700s and DEC LA12s, or one of the dasiywheel-printer based terminals (which are often non-period-correct things like a WheelWriter with a modern serial interface card in it).
So, of course, I’ve been idly keeping an eye out for a deal on one on the auction sites, and mid-October last year I got lucky: I scored a TI Silent 700 Mod. 745 for $34.00+S&H (about $47 all in) from a Shopgoodwill auction, and got it working.
An old friend of mine was moving cross-country and got in touch about taking “Some of his old computers” a while ago. I of course agreed, and it turned out to be quite a growth event for my hoard. There will be several posts about machines that arrived in this process as I get to them.
The list of things to be re-homed included “an Apollo” which I was hoping was a pre-acquision DN-something or a HP 300/400 series because I’ve had a long fascination with Domain/OS. What showed up is… not that. This is a later HP Apollo 9000/735 PA-RISC workstation, ca. 1992, which is easily the most exotic piece of hardware that transaction made me steward of. The OS options are HP-UX 7-10.20, a few BSDs, or a second-class NextStep 3.3 port; I’ll probably go with HP-UX10.2. It came with the requisite HP-HIL keyboard and mouse (thank goodness) and a DEC branded 5xBNC to VGA cable.
This thing was serious rarefied-air hardware when it was new: PA-7100 99 MHz processor, 208 MB of RAM in 12 obscene proprietary 16MB RAM modules + 16 soldered to the processor board, a HP CRX-24Z video board, a full-height SCSI HDD, and an AUI Ethernet daughter card. Probably in the ballpark of $60,000 new. It is also built like a piece of high-end industrial equipment, with big sheet-metal frames with handles that pull out of the back of the system for every major component.
My first attempt to power it resulted in …a feeble blink of the power light. That suggested to me that the PSU was bad, probably due to defunct electrolytic capacitors. So, in standard “old electronics troubleshooting” fashion, I pulled the PSU, tore it down, read labels off the most suspicious capacitors, and ordered replacements. The HP Museum folk also suggest the AC line filter module is a time bomb on all of these, so since it’s still made, I grabbed one of those too.
List with Mouser links, since they were the vendor with everything I needed in-stock: 8x 2200uF 25V, 12.5mmD 40mmH, 5mm lead spacing , Nichicon UPJ1E222MHD firstname.lastname@example.org 1x 220uF 35v, 10mmD, 20mmH, 7mm lead spacing, Nichicon UPM1V221MPD1TA 1@$0.72 1x 1x 22uF, 25V, 5mmD, 12mmH: Nichicon UPS1E220MDD1TA email@example.com 1x 12uF, 35v, 5mmD, 10mmH, Panasonic EEA-FC1V120B 1@$0.39 1x AC Power Entry Module, Schaffner FN9222R-10-06, 1@$6.50 I also ordered a couple 470uF 25V, 10mmD, 20mmH, 5mm lead spacing caps, but ended up not installing them because there was no sign of damage and they were hard to get a good angle on.
I passed on dealing with a couple smaller electrolytics with no signs of damage, and also two gigantic 2x 1200uF, 250v, 35mmD, 47mmH, 10mm lead spacing input caps that cost $7.50 a piece, since they looked both fine and like a fight to get out without damaging the PCB. One of these days I really need to invest in a proper pump-driven desoldering gun to make this kind of task safer and easier.
I of course picked up an extra 1-2 of each since it was noise over paying for shipping, and it’s a good thing because I dropped one of the new 220uF/35V parts and it instantly disappeared forever, presumably to wherever my cat has been hiding toys recently. The new input filter is slightly longer than the original and required a bit of creative terminal bending to fit around the caps, but it made it back into the case. After the recap, it powered right up, and on a second try after giving the hard disc a gentle thump to unstick the heads from park, everything spun right up.
It booted to status LEDs at that point, and shows “8,6,3,1” which according to the service manual indicates “Autoselection Failure to Find Boot Device” – probably meaning the HDD is dead and/or wiped. The appropriate HP/UX media is easy enough to find. Unfortunately, the monitor on my basement bench doesn’t seem to want to sync with the presumed 1280×1024@72Hz Sync-on-Green coming out of the video card, so I’m stuck for now until I can find a workaround. There is a 4th BNC labeled “Stereo” that might somehow be useful for sync? Or I need a scan converter/sync stripper gadget? … further research required.
Yesterday I pulled my ThinkPad 560E out, dd’d a floppinux on to a real floppy, booted it up and… it traps on an invalid opcode as soon as it tries to load init.
A little thinking made me realize that the way they were building their busybox binary was contaminating it with libraries from the system they were building on (which was apparently i686), so despite all their “will work on a 486 or later” option selections, the images they produced only work on i686 or later boxes.
I opened an issue then got obsessed and decided to fix it myself, and … you can read the details in my followup to the issue.
The magic lazy out for this kind of thing now is the pre-built musl based cross toolchains provided by https://musl.cc/
I made a couple other suggestions (about using musl, about configuring the kernel for xz and using it for the initrd, etc.) while I was hacking, because putting together little cross-compiled Linuxes is something I used to know what I was doing with. It did take a couple hours to spin back up, there are always picky cross-environment things to remember, and things have changed, mostly for the easier.
I’ve posted a copy of my generated i486-clean image. (Subsequently swapped out for a rebuild with slightly more useful busybox and kernel options, but only about 450k free)
Where most of the users’ time will be spent in routine operation of the product, and where learning is only a small part of the picture, designing for productivity – even if it requires retraining- is often the correct decision.