Captain Kerbal

Category: Toshiba Project

A break

I’ve been having a break from KSP, simply because I’ve been doing other things; namely, working on the Toshiba Project, and playing around with an old Palm Pilot VIIx.

Not much really…

I probably won’t be playing any KSP for the next couple of weeks, at least. Hopefully I use that time wisely, and either make progress on the Toshiba Project (HDD investigations at the moment) or with the Palm Pilot. If I do something really exciting, I might even share about it here! ūüėÄ

Advertisements

Make-ing limitations?

One of the ‘blockers’ for Takahe Linux¬†is the lack of a ‘proper’ build system. Currently, it’s an all-or-nothing approach, which is less than ideal, mostly because it tends to take ~ half an hour or so to rebuild on my PC. I’ve been trying to write a replacement, but I’m struggling, mostly due to the complexity involved…

“Why don’t you take suckless.org’s approach, and just use make?” I hear you ask. Or maybe not, if you’d never read suckless’s spiel on build systems. But – for my use case, at least – make is broken:

  • There is no easy way to specify if something needs to be rebuilt (if it’s not file-based) – you have to put the tests in the build shell script.
  • There is no way to extend the rule matching system beyond plain old files.
  • There is no easy way to auto generate dependencies. You can do so, by generating a makefile; a process prone to¬†bugs. Also, auto generating makefiles creates a monster makefile, which is not at all fun to read… just one of the issues with autotools, apparently.

Here’s a longer list¬†of issues that I found on the net. Most of these do not really apply to my particular problem, but they are still valid.

However, it mentions that there are alternatives to make. What alternatives?

Here’s what I’ve found:

  • Write another build system yourself.
  • Create a dumb-but-working script.
  • Create yet another specialized makefile generation script.
  • Use another build system, such as CMake, Waf, Scons, Tup, and so on.

Not good :/

Tup looks, by far, the best idea. For my particular use case, it’s broken, mostly because it requires Lua, and I don’t think that it’s that modular. But…

Why shell sucks

I’ve written a few toy programs in shell¬†– I’m marginally proficient, at least. Or, too put it another way, I’ve found where the manual is…

I’ve been considering a new build system for Takahe Linux, or at least a refreshed version, so I was wondering what to write it in. Currently, I’m using a shell script that works. That’s about the only positive thing I can say for it!

Actually, it’s not too bad. The problem is that I can’t see any half-decent way of adding some features I’d like – namely, dependency handling – without making a mess of what is a relatively simple shell script.

Anyway, I ended up writing a list of things I disliked about shell scripts – a list of things that make shell scripting suck. Some are just annoying; others can cause catastrophic failures (read – data loss, corruption, general pain)!

  • No array datatype! Actually, having everything as a string can be annoying, too.
  • Unassigned variables can be accessed.
  • Lack of clear namespaces.
  • Lack of multiple return variables.
  • Too many interactive functions (just general language bloating…).
  • Awkward (arguably non-existent) multi-threading support.
  • Syntax is not at all forgiving¬†– forgetting to quote something properly can be bad, for instance. And it can even work, until that moment where it doesn’t… and you suddenly loose files because a directory had a space in it’s name!
  • Slow. This is not really an issue…
  • Error checking is weird. For instance, by default, failures in a pipeline are silently ignored in Bash.
  • There are many, many different shells. All of which behave differently for different things…
  • Colour is nice. Until it breaks another script…
  • Parsing the output of commands is inherently prone to breakage!
  • You have to learn the syntax of lots of sub commands just to get something to work. Or languages within languages; sed, for instance!
  • There are no libraries. You have to use commands instead. Which can be really inflexible (how do you propose to pass <insert complex datatype here> to that command, and how are you going to parse the complex output in a sensible way?).

Just to show that I’m not completely against shell scripts, here’s why I do use them:

  • Light. Bash has a 4MB memory overhead on my system; dash 2MB. Python uses 10MB… on a good day.
  • Simple. Kind of. For some things…
  • File-orientated, which can be quite nice.
  • High level. Writing some of the simple stuff in C would be even worse than writing it in shell…

Generally, though, I’d like a scripting language that was a ‘real’ language – with proper datatypes, better error handling, and so forth. So¬†I went looking for ‘sane’ alternatives.

Here’s some that I found:

rc is lightweight (1MB RSS), and it supports arrays. It still is a shell-based language, though…

lua is not designed for shell scripting, so it’s a bit awkward. In terms of performance, it’s one of the best interpreted languages, and uses ~2MB RSS on my system.

perl is well known as being a messy language – even more so than shell. It is, however, heavily designed to be a replacement for shell scripting, so it’s possibly the best fit. On the other hand, if perl, why not rc? Perl is about 4 times as ‘heavy’…


 

Generally, none of those options sound attractive. Lua’s probably the best bet, because it places value on correctness, at least in comparison, but shell scripts directly translated into lua are very verbose!

What I’ll probably do is see whether I can make make work. Or perhaps just become really frustrated…

Cracking the DSDT code

Kind of. I’ve mentioned before¬†that I’ve been poking around in the DSDT tables from the Toshiba, in an attempt to figure out what’s going on. Well, I’ve made some progress.

Specifically, I’ve been looking in the code for the functions for controlling the hard drive. This boils down to a several power management functions, and a couple of functions named _STM and _GTM. These get/set the timing modes for the disk controller.

_STM looks a bit like this:

Put 0x98 into EDI1.

Plug 0xFF00 into EAX1, 0x00A0B10C into EBX1, the timing mode into ECX1, 0x00 into EDX1, and 0xB2 into a register (or memory location?) named “_SB.PCI0.EIO.MOTH.TRP4”.

To quote from the (reverse engineered; not by me) HCI spec:

The HCI is activated by reading a byte from port B2h into the AL register. There are two functions in the HCI one that enables a device setup status to be read and another that enables it to be set. The function that is then executed depends on the value held in the AX register, according to the following list:

– FE00h: Read current status of device

– FF00h: Setup device

Unlike the System Configuration Interface (SCI) it is not necessary to open or close an interface to the HCI.

Does this sound familiar?

So this piece of code is calling into the HCI… which is essentially a SMI (system management mode) trap… which is bad. Because I have no idea about what happens after that!

Essentially, this piece of code sets the timing mode by chucking the device ID in EBX1, timing into ECX1, and then calling into HCI. At least that’s how I understand it at the moment!

However, this does nothing for helping me understand how the hardware really works…

A package manager for Takahe Linux

I’ve just added a package manager PKGBUILD to Takahe Linux – for pacman!

It needs libarchive at a minimum, as it turns out, although bash and a few other bits are required too (for makepkg).

Yay!

Next up: some of the GCC toolchain? Git? Python?

This seems to be a theme

In my prior post, I said that it was time for a break from the Toshiba Project. I should have known better Рthe last time I said that was shortly before this post! Nothing quite that stunning has occurred, though.

Instead, I’ve been reading up on PCI, in the hope that I’ll be able to learn more about the PATA controller. I’ve made some progress on that front. It turns out that Linux ‘breaks out’ the PCI configuration registers via the sys filesystem. By reading the file in question, I can compare the configuration registers with the Piccolo specification – hopefully shedding some light on how it works. In this case, I needed to read /sys/bus/pci/devices/0000:00:00.0/config, using ‘od -x’. I then wrote up the results into an markdown file for further study. The results were inconclusive…

First of all, the chipset appears to be (if it is a Piccolo device) in “Triton Mode”, ie largely compatible with the PIIX4 chips of the time. At least some of the registers are the same! Secondly, some of the registers line up with the Piccolo spec… and some don’t. At all. So if it is a Piccolo device, it is either operating in “Triton Mode” or is a distant cousin from the device in the spec!

I’ve tried probing 0x80 – the Triton/Toshiba mode switch on the Piccolo – but it didn’t do much. I could swap it to ‘1’, but swapping it to ’31’ again causes a kernel panic…

I’m not sure what else I’ll try – if it is in Triton Mode, it’s incompatible – neither of the Linux drivers for the PIIX4 chips work.

Also, the PIIX4 has 4 functions – one of which is the PATA controller – and the chip in my Toshiba has one. Piccolo chips should have at least two. How does that work?

Time for a break

I’ve had a lot of fun working on the Toshiba project over the last three weeks or so. Highlights include:

  • Getting ACPI working.
  • The PgUp button fix.
  • Setting up a serial link.
  • Learning a lot about ACPI, ATA, and the PCI bus.

But I think I’ll take a break, to work on other projects.

The next big push will probably focus on learning more about the disk controller, either through figuring out how to reverse engineer the Windows 98 driver (once I can confirm that it is actually doing it’s thing!), or by experimenting with the existing Linux drivers.

Notes for next time:

  • The Windows 98 driver only claims to support TOS7301 controllers. What’s up with that?
  • I’ll need to figure out what the difference in probing is between pata_legacy and pata_piccolo. See Alan’s last email for help with that.
  • I’m going to have to implement a ‘stub’ driver for experimenting with…
  • The best lead I’ve got at the moment would be that pata_piccolo does not ‘see’ the disk controller – probing fails. I’ll have to experiment with different methods to figure out which one works, and why, then add the other methods from pata_piccolo to the new driver to see whether they work.