Learning to SWIM

Apparently there is no free USB sniffer for Windows 7;
so on Saturday I dug out and replugged a physical Windows XP machine
(my Planche SVN server btw).
SniffUSB 2.0
did the job okay under Windows XP.
Reading the flash from ST Visual Programmer resulted in a 7.2 MB log file.
On Sunday I was done reading the firmware of my STM8S-Discovery on Darwin!
While the ST-Link is my first USB project, I did write an iSCSI client for the Haiku bootloader,
so the CDBs were somewhat familiar. Not the vendor-specific ones of course!

Why all the fuss, you might wonder. And yes, there's a User Manual on SWIM.
But it tells you how long to set the line to low or high etc.
I couldn't find a direct correlation between the three SWIM commands (SRST, ROTF, WOTF)
and the CDBs.

Exiting SWIM mode was trivial once reading worked, and it filled a gap in the enum.

While deciphering the 3.5 MB flash write mechanism,
I found that the buffer is not cleared between commands,
so may contain artefacts at unused offsets.

2011-06-28

Libusb breakthrough for ST-Link

Sunday I've hacked on a libusb-based program to interface with my STM8S-Discovery's ST-Link.
The device's USB interface couldn't be claimed under Darwin though, since Darwin's
IOUSBMassStorageClass driver tried to use it apparently. The equivalent to a Linux "quirk"
appeared to be a so-called codeless kext, which assigns a device/interface a different driver.
But all variations that I tried didn't work out. I even tried writing a real stub kext.

Today I found out that the stupid property list editor had been using a wrong value type
for some of the match criteria. And suddenly it works!

It turns out that STM8S-Discovery, STM8L-Discovery and STM32VLDiscovery all have the same
product and vendor IDs, start in "DFU" mode and return ST-Link version 1.
STM32VLDiscovery has JTAG version 11 and no SWIM version.
Both STM8S-Discovery and STM8L-Discovery have SWIM version 3 and no JTAG version.
Exiting DFU mode (to mass storage mode) works okay and survives multiple program invocations.

2011-06-23

Sunshine fading

It's been a while that Oracle has taken over Sun and I still hadn't made the move away from
discontinued OpenSolaris. So I tried upgrading from snv_134b to today's
OpenIndiana -
a nightmare!!! I've managed to uninstall (cf. below) the pkg command
and haven't figured out a way to get it back, so I'm pretty much destined to
install OpenIndiana from scratch. Lots of data to backup from ZFS first,
including QEMU VMs and my interrupted PowerPC port of Haiku.

$ pfexec pkg install SUNWipkg SUNWipkg-um SUNWipkg-gui

$ pfexec pkg uninstall entire slim_install system/zones/brand/ipkg

$ pfexec pkg uninstall package/pkg # DON'T!!!

$ pfexec pkg image-update -v

2011-06-09

After POWERing up

To boot from CD I found this to work:

0 > boot /pci@800000020000003/pci@2,3/ide@1/disk@0

2011-06-02

POWERing up again my IBM IntelliStation 9111-285

screen how-to

It's been a while, and not only do I have to look up each time how to connect to the
ASMI (Advanced System Management interface) but also how to connect to the serial port from my PowerMac:

The dark side of ni(hi)lism

I managed to screw up my nilfs2 partition.
As gildean says, NILFS is "quite different from the classical filesystems".
It indeed is, it doesn't clean up its blocks itself, it needs a daemon to occasionally do so,
installed by nilfs-tools. That's not available
through apt-get, so you need to download the .deb and double-click it.

In order to transfer the on-SD user to MMC, I mounted /dev/mmcblk3p6 to /mnt and ran
cp -R --preserve . /mnt/myuser and set up an entry in /etc/fstab.

2011-05-21

Linux running

Turns out that some good soul prepared an alternative boot.mmc.32.img
file elsewhere.

Linux 2.6.32 runs pretty well now, so unless the bootloader changes again I won't care about
Android any more.

2011-05-19

Froyo FTW ... or better not?

I updated my Toshiba AC100 to 2.2.5.0029
(Android "Froyo")
last week, only to find out that it started booting into my Linux partition.
Lucky me, I had done a backup of the original partition!
With partition 5 restored, the system update completed successfully after some time.

In addition to the annoyingly crappy email client,
there turns out to be no Facebook app on Toshiba Market Place. ;)

The Linux image has changed the file system from ext3 to nilfs2, so I needed to install
the nilfs-tools package. Then, Ubuntu's volume manager is able
to format the partition with NILFS; don't worry it won't recognize the format and display it as
"Unknown". So to mount it, look up the device path (here, /dev/sdb1)
and mount it manually (here, at /mnt).

sudo mount -t nilfs2 /dev/sdb1 /mnt

After the usual

sudo tar xavf Ubuntu7.tar.gz --numeric-owner -C /mnt

I had to unmount it manually

sudo umount /mnt

Unfortunately on boot it complains about not finding /dev/mmcblk3p6.
Seems like the SD card is not scanned by the init script?

2011-03-24

ST-Link findings

It seems Martin Capitanio
recently succeeded in accessing the STM32 Value line discovery ST-Link from Linux!
There's a fork on GitHub
that claims to have a working gdb-server.

For starters I'm struggling to get arm-none-eabi GCC 4.5.2 compiled
in order to download the current firmware with
stlink-download.
Andreas Schwab's recipe for ppc64 luckily works here, too: make all-gcc; sudo make install-gcc

2011-03-20

µC tools WIP

Lately I've been spending some time working with microcontrollers again.
At university I had been working with msp430 based sensor nodes
as well as 68k and avr based boards.
My STM8-Discovery had been
collecting dust, with no stm8 binutils / GCC available and no evaluation key from Cosmic arriving.
So, inspired by the chatter about the LLVM
keynote at FOSDEM 2011,
I decided to get to know LLVM and clang by contributing
an STM8 backend.

This Embedded World, the STMicroelectronics people rather pointed me to the
STM32-Discovery of MCUs
than caring about the STM8 compiler situation
(and Atollic do seem to ship a binary
arm-eabi GCC for their Eclipse-based
TrueSTUDIO/STM32).
But they were willing to give me an STM8L-Discovery for comparison.
That was when I realized how gently I had been introduced to the world of microcontrollers
by our university's msp430 Linux setup; and probably why their Embedded Systems lab
was running some oldish Windows.

Diving deeper into the world of MCUs

A nice lady from Silicon Labs
(note: a few years earlier one man simply sent me to silabs.com, as did NXP this year)
gave me not only the HID-USB-to-IR reference design
but also a C8051F336DK development kit,
saying openly that their tools were for Windows only.
But I did find an SDCC project.

Renesas provided me with a V850ES-Jx3-L starter kit
and promised to ship me an RL78 starter kit as well (but then came the earthquake in Japan).
I was really surprised to learn that Renesas these days is also supplier
of SuperH (e.g., sh4) MCUs.
Renesas' tools seem Windows-only,
but supposedly binutils / GCC have support for v850-elf.
Still need to check.

LLVM status

In my LLVM quest I succeeded in compiling trivial C methods to stm8 assembler.
This weekend I managed to prefix the file with the required stm8/ line, based on Subtarget.
But it still emits a lot of ELF-specific cruft that the ST assembler wouldn't understand;
I fear I may need an MCStreamer to teach LLVM to emit assembler source
that ST can process (avoiding .file, .align, etc.).
Either that or implement an MCCodeEmitter that assembles machine code directly -
the advantage would be the ability to do it on Darwin, the downside is that there's no
documented instruction formats wrt src/dst encoding so I would need to encode/define each
instruction variant.

2011-03-20

Tegra 2

For New Year I got myself a Tegra2-based (arm) Toshiba AC100 netbook.

At FOSDEM 2011 I spoke to the speaker of a MeeGo talk about possible
Tegra2 support.

At Embedded World 2011 the Nvidia guys unfortunately were unsensitive to my issues
and pointed to companies like Toradex. Nice people indeed and open to upstreaming things,
but obviously they can't easily lift the restrictions Nvidia puts on us with their binary
x86 Linux tools like nvflash and their L4T's binary userspace daemon(s) and Xorg drivers...

2010-11-01

ppc64 debugging breakthrough

To get powerpc64-linux-gnu-gdb compiled,
I had to remove the $(LIBS) dependency of the psim target.

2010-08-29

No longer scuzzy: iSCSI

Sometimes a little distance helps solving problems. Having worked towards iSCSI boot support for Haiku some time already,
I kept getting an extra SCSI response with status 0x2 when doing READ (6), READ (10) or READ (12).
Turns out it wasn't related to the read command at all. Instead of the SCSI response message to READ CAPACITY
I expected I was getting a Data In message all along, followed by the actual SCSI response message with status 0x0.

Having found out, it turned out that READ (12) was indeed triggering an invalid opcode sense key.
Using READ (16) worked much better!
I committed its struct in r38425,
maybe Adrien or someone has a use for it too.

The boot started to go pretty far then. I ran into memory issues though and thought it might be a bad idea to
malloc ~1.6 MiB for the first kernel_ppc ELF segment, so I implemented a zero-copy mechanism instead.
Getting this right for the case where we don't want full blocks got my mind a little twisted.

Anyway it's working now, I get to the frame buffer (third icon) and see the PIC panic.

Yesterday I briefly poked at ppc64 bootloader support and got the memory ranges detected correctly.
Still unsure how to handle the memory translations.

2010-06-12

Mr. MMU Man #2

Seems I never documented the initial memory mappings on my PowerMac G3, so here we go:

#1 is the boot loader (__text_begin at 0x00102074, size to _end 221068)
#3 is the memory claimed by Haiku for the page table.
#7 contains the ATI Radeon 9200 frame buffer (0x98008000).
#11 is the OpenFirmware (entry at 0xff809b08).

Dissecting network hardware

I've been having some network hardware issues the week before, so I looked into reflashing
my D-Link access point with OpenWRT.
The power supply unit and possibly the flash is damaged, and soldering the serial port is not yet finished.

TCP/IP

Last weekend I've hacked together the beginnings of a TCP implementation for the Haiku boot loader.
It handles the SYN, SYN-ACK, ACK sequence for connecting and FIN-ACKs for disconnecting.
Queuing and resending data packets are prepared but untested.

Haiku RemoteDisk

I found out that Haiku has a facility similar to qemu-nbd
that allows to connect to remote disks.
Once I had made the necessary adjustments to make the remote_disk_server run on OpenSolaris,
the client wouldn't discover it. Turns out it didn't set an IP address.

Happy New Year - Life Signs

I managed to get a sign of life from the Haiku kernel - by doing return -42 as first instruction in
_start. Further tries indicate it survives the initial version check and
setting the number of CPUs but gets stuck during the rendezvous.

It's often the small things, in this case an "uninitialized" kernel argument interfering with CPU rendezvous!

Haiku and OpenFirmware

Testing Haiku on real hardware has been a little painful, requiring to reboot and hold Command+Option+O+F for each try.
While searching for a way to set boot arguments,
by way of the printenv command I've discovered a setting auto-boot?
that saves me the key combination.

setenv auto-boot? false

These options simplify TFTP booting:

setenv default-client-ip 10.0.0.2setenv default-server-ip 10.0.0.1

Having renamed the bootloader to bl, allowing me to boot by typing:

boot enet:,bl

I can even fully automate this by doing:

setenv auto-boot? truesetenv boot-command boot enet:,bl

2009-12-30

Haiku on ppc

Over Christmas I've been poking some more at Haiku/ppc.
Given an IDE disk to boot from and booting via TFTP, this is where it ends (kernel tracing enabled):

kernel entry at 0x80081de4
kernel stack top: 0x80004000

Here's the output from a modified boot loader
showing the memory mappings right after the output above:

Not surprised that it didn't find a partition, since I didn't provide a haiku.image.
So I waited and waited for OpenSolaris to write a 120 MB image to my USB memory stick...
I found out that Haiku hangs above due to my Sonnet SATA controller. Without it I get to a nice boot menu.
The USB boot volume is not found, but I'd blame the G3 firmware for that.

Consequences of global warming?

Poor Tux!
Something fishy appears to be going on with QEMU's VGABIOS for ppc. Kudos to Andy Warhol.

2009-12-06

Some ppc64 insights from Saint Nick

While last weekend or so Fedora 12 screwed my OpenSolaris installation,
this weekend was more successful.

Inspired by Blue Swirl
hinting me
on QEMU's ppc TCG target as possible cause of my sparc64 troubles,
over at OpenBIOS,
I made an interesting discovery with gdb:

That means ever since
Lupus' mention thereof
I was on the wrong track with my ppc64 port of Mono...
Armed with this insight, I managed to get QEMU working on Mac OS X v10.5 ppc64 yesterday,
and malc applied the patch today. Yay! The road to sending my first proper Git patches was a little stony; I ended up using
nano, not finding switches for supplying the cover letter or the patch version
and not finding a free graphical (copy&paste-capable) text editor that plays nice with git send-email.

Updating Mono to r147748 however, eglib didn't seem to supply G_MAXINT so that the build
was once again broken, and I was too tired to fix it right away.

2009-11-17

DTrace# on i386 Mac

Yesterday I was successful adding support for Mac OS X i386.
Not having access to an x86_64 Mac or sparc hardware, this completes my dtrace-sharp ABI coverage. [1]

Performance was around five seconds on a MacBook Core Duo 2.0 GHz,
so not as bad as ppc but still significantly slower than on Solaris x86.

I figured out that on x86 both Solaris and Mac OS X change a nop instruction
to int13. On the Mac it seemed to be written off-by-one though for the actual probe...

[1] I checked that the latest Git QEMU sparc-softmmu
works again on Mac OS X, unpatched;
however booting a DTrace-capable Solaris still requires sparc64-softmmu and OpenBIOS fixes though.

2009-11-15

More on DTrace performance

Adding support for Solaris amd64 turned out pretty easy. So here are some numbers:

OpenSolaris x86 with probe enabled:

real 0m1,07s
user 0m0,82s
sys 0m0,22s

OpenSolaris x86 with probe disabled:

real 0m1,08s
user 0m0,83s
sys 0m0,22s

OpenSolaris x86 with no probes firing:

real 0m1,05s
user 0m0,81s
sys 0m0,21s

OpenSolaris x86 with no probes firing and without dtrace attached:

real 0m0.103s
user 0m0.085s
sys 0m0.018s

OpenSolaris amd64 with probe enabled:

real 0m1,12s
user 0m0,73s
sys 0m0,20s

OpenSolaris amd64 with probe disabled:

real 0m1,11s
user 0m0,85s
sys 0m0,23s

Since these measurements were not scientifically exact,
I'll regard the absolute difference of 0.01s between disabled and enabled as statistical deviation and thus as "zero impact"
(when the probe was enabled, the D script traced the timestamp).
Leaving out the managed console output, the is-enabled check and the actual probe summed up to around 0.03s.
The test system was an AMD Athlon64 X2 2.2 GHz.

And now for something completely different:

Mac OS X ppc with probe enabled:

real 0m22.077s
user 0m20.188s
sys 0m1.212s

Mac OS X ppc with no probes firing:

real 0m22.114s
user 0m20.137s
sys 0m1.222s

Mac OS X ppc with no probes firing and without dtrace attached:

real 0m0.214s
user 0m0.142s
sys 0m0.046s

If run through dtrace, it spends five times more time in userland and more than 100 times longer in whole!
Without dtrace attached, it comes close to the OpenSolaris numbers.
Test system was a dual-core PowerMac G5 2.0 GHz.

It had been a while since I've actively worked on DTrace support
for the Mono runtime. I integrated
the "mono" provider
in r104964 (June 5, 2008). Since then that allows to trace VES initialization, JIT method compilation and hopefully GCs
via USDT probes - similar to the
Java 1.6 "hotspot" provider.
It was however not yet possible to trace method flow or to define probes at random points in managed code,
because there was simply no documentation.
There was an undocumented libdtrace.so library, but it didn't appear to expose this functionality,
just helpers to run D scripts as used by
the Java DTrace API
(Chime)
or dtrace(1M) itself.

Now a Ruby project gave me a valuable hint: the DTrace Object Format (DOF).

OpenSolaris' sys/dtrace.h header defines a number of structs for encoding a provider definition
in a somewhat platform-neutral format. Then there's a DTRACEHIOC_ADDDOF ioctl
to register such a DOF file with the kernel. The system thereby gets offsets to points in native code,
which it overwrites to make is-enabled probes return 1 if enabled by a client script
and to turn the actual probes from NOPs into a trigger for the client-specified actions.

So what dtrace-sharp does is it lets you specify providers with probes -
with custom provider name, module name, function name and probe name - and registers them with the system.
It emits native stub functions per probe that can be p/invoke'd from managed code when the probe is supposed to fire.

The dyld source was helpful in figuring out the ioctl,
but who would've guessed that user_addr_t is 8 bytes for a 32-bit userland application?
Also, the sys/dtrace.h header deviates in some places. Apple requires DOF version 3,
which OpenSolaris does not support.

Unfortunately the performance on Mac OS X when running with dtrace was desastrous compared to OpenSolaris...

There are still some limitations of course - the probes can't pass any arguments yet,
and a number of ABIs (Solaris {amd64,sparc[64]}, Mac OS X {i386,x86_64}) are still unsupported.
Back on OpenSolaris, I checked whether the x86 stubs work unmodified on amd64, but no, they crashed.
On to some more disassembling...

So what's ahead? I still need to decide where to push my Git repository once dtrace-sharp becomes usable.
I think it'll be useful even if I continue to add more DTrace support to the Mono runtime,
since being pure managed code it might be usable on other runtimes like GNU Portable.NET as well.
I will be looking into adding method-enter and method-return probes
to the Mono runtime.
To do so I'll try to dump the system-modified is-enabled probe instructions
in order to check whether I can avoid a function call for the is-enabled probe from a hot path like method execution.