May the Forth be with you

Learning Forth. It is actually a very powerful language.

Don't know if the One Laptop Per Child initiative will give something to children, but it certainly brings something to me: very good Forth lessons.

There are also some useful documentation from Sun (meanwhile Oracle).

Open Boot vs. OpenBIOS

While being a great Open Source fan, I still think it would be better to use a real machine's firmware to ensure the emulation is complete. Once we are sure the virtual hardware is working properly there will be no need to run POST. It doesn't even have to be implemented.

Otherwise there are chances that Firmware would perfectly function on a virtual hardware, but it would have nothing to do with the real hardware. There are always some features which are documented too fuzzy or not documented at all.

So I'm going to give it a shot with the real firmware. Btw it is called OBP - Open Boot Prom.

The first results are not very fruitful: the RAM is not detected, and there are no sbus devices (=> no booting from SCSI yet). But at least OBP has the command "power-off" (which OpenBIOS doesn't), and the command is even perfectly working:

$ qemu-system-sparc -M SS-20 -L . -bios ss20_v2.25_rom -nographic -hda hda.img
ESP ERROR: esp_mem_writeb: Unhandled ESP command (a2)

Power-ON Reset
SMCC SPARCstation 10/20 UP/MP POST version VRV3.45 (09/11/95)


CPU_#0 TI, STP1021PGA(1.x) 1Mb External cache

CPU_#1 ******* NOT installed *******
CPU_#2 ******* NOT installed *******
CPU_#3 ******* NOT installed *******

<<<>>> IS RUNNING (MID = 00000008)



$$$$$ WARNING : No Keyboard Detected! $$$$$
MMU ICACHE_TLB bit pattern Test
Case 0000000f: I_TLB mis-matched exp=55555000 obs=00000000 xor=
55555000 entry # 0x00000000
Available Memory 0x08000000
Allocating SRMMU Context Table
Context Table allocated, Available Memory 0x07fc0000
Setting SRMMU Context Register
Context Table allocated, Available Memory 0x07fc0000
Setting SRMMU Context Table Pointer Register
RAMsize allocated, Available Memory 0x07fb0000
Allocating SRMMU Level 1 Table
Level 1 Table allocated, Available Memory 0x07fafc00
Mapping RAM @ 0xffef0000
RAM mapped, Available Memory 0x07fafa00
Mapping ROM @ 0xffd00000
ROM mapped, Available Memory 0x07faf800
Mapping ROM @ 0x00000000
ROM mapped, Available Memory 0x07faf000
ttya initialized
Cpu #0 TI,TMS390Z55
Cpu #1 Nothing there
Cpu #2 Nothing there
Cpu #3 Nothing there
Probing Memory Bank #0 Nothing there
Probing Memory Bank #1 Nothing there
Probing Memory Bank #2 Nothing there
Probing Memory Bank #3 Data Access Error
ok show-devs
/TI,TMS390Z55@f,f8fffffc
/SUNW,sx@f,80000000
/eccmemctl@f,0
/virtual-memory@0,0
/memory
/obio
/iommu@f,e0000000
/openprom
/aliases
/options
/packages
/obio/power@0,a01000
/obio/auxio@0,800000
/obio/SUNW,fdtwo@0,700000
/obio/interrupt@0,400000
/obio/counter@0,300000
/obio/eeprom@0,200000
/obio/zs@0,0
/obio/zs@0,100000
/iommu@f,e0000000/sbus@f,e0001000
/packages/obp-tftp
/packages/deblocker
/packages/disk-label

ok show-sbus
SBus slot f
SBus slot e
SBus slot 0
SBus slot 1
SBus slot 2
SBus slot 3
ok power-off

$

Looks like the OpenBIOS doesn't recognize Solaris boot sector:


Configuration device id QEMU version 1 machine id 32
UUID: 00000000-0000-0000-0000-000000000000
CPUs: 1 x FMI,MB86904
Welcome to OpenBIOS v1.0 built on Jul 5 2009 17:37
Type 'help' for detailed information

[sparc] Booting file 'cdrom' with parameters ''
Trying cdrom (/iommu/sbus/espdma/esp/sd@2,0)
Not a bootable ELF image
Not a Linux kernel image
Not a bootable a.out image
Trying cdrom:d (/iommu/sbus/espdma/esp/sd@2,0:d)
Not a bootable ELF image
Not a Linux kernel image
Loading a.out image...
Loaded 7680 bytes
entry point is 0x4000
Jumping to entry point...
bootblk: can't find the boot program
halt, power off

Solaris/sparc under qemu

My next project is launching Solaris/sparc under qemu.

Sparc v9 (sun4u) is just not ready yet, but sparc v8 (sun4m) emulation is there since years, so there are good chances to get some luck with Solaris 9 - the last Solaris version which supports 32 bit machines. Alas, no OpenSolaris.

update: I gathered a Solaris/SPARC under qemu how-to.

Full Flash - to - flashable update file converter

... is coming soon. Just need to test it a little.

Meanwhile, does anyone know how the LZMA Squash-fs from Broadcom routers can be mounted on x86 machine? I tried to port the module from Siemens GPL package, but failed. Though it may be the endianness problem...

CFE Loader in full-flash

Ok, probably the bad news for those who rent bcm963xx devices from the providers.

The full flash contains not just the contents of the flash update file, but also some information how the flashing was done. This means if the user, renting the device, would flash the device with another firmware and then flash it back, the Provider will notice the change.

bcm963xx firmware dumps vs. update files

This is the next step. It's important to find out how to create an update file from the flash dump. The update files are already explored and described.

The dumps are less explored. What I see, is unlike in firmware updates, CFE-Boot-Loader comes before the flash header.

• The root-fs and the kernel image are coming after the header, like in the update files.
  
• If I move the boot-loader to the place between the header and the start of the root-fs, the checksum of the root-fs & kernel is OK.
• The checksum of header is also OK.
• The checksum of the complete image fails.

What does it mean? The only option I see is the stored Boot-Loader is not the same as in the update file. Maybe it's just the addresses/offsets, which are changed during flashing. It's necessary to compare the flash dumps with the flash update files to see what is going on.

Stay tuned. ;-)

Dumping Busybox Firmware of newer bcm963xx devices

Particularly this script is for routers bases on BusyBox with kernel 2.6.8.1 built with gcc 3.4.2. It's inspired by Jerome Petazzoni's SkayaWiki, which is unfortunately quite outdated.

The world has been changed a lot since 2.4.x kernels. Also it now it's much less room in the RAM to play with. Jerome did the trick, using 1.5M all-in-one BusyBox binary, but nowadays I had to do the same, having all in all just 124K! Nonetheless, it's obviously possible. :-D

Disclaimer: you may use these scripts ONLY to dump the firmware of your own devices, and purely for educational purposes. Also I don't provide any warranty of any kind! The script is working in my case, but may damage your router, format all your hard drives, and insult your Mother-in-law.

The script was developed and tested under Linux. I haven't chance to run it under cygwin, but it should work. If anyone tries this I would appreciate the feedback.

Ok. Let's see, how you can use it.

The current version of the script has just one dependency:

• python

To run the script, download it here, (you have to replace underscores in the name with dots, it's a limitation of my hosting provider), unpack it, edit the string

inichat=[("Login name:","admin\n"),("Password:","admin\n"),("> ","sh\n")]

providing your superuser account. The login prompt may also vary. In some older firmwares it's 'Login:', in mine it's 'Login name:'.

After changing this line (and, optionally your router - ip address), you can launch the script by typing:

python bcmfwext.py filename_to_save

The script is sending 4 files to the bcm963xx device, showing the progress per file, so don't get surprised when after something like 255/255, you see something like 1/7500.

On my system it takes approx 7 minutes to get the dump, so be patient. But if it takes more than 30 minutes, something went wrong.

Any feedback would be appreciated in English, German or Russian.

Good luck!

Let's see if this blog is the right way to share tech stuff

I've got some scripts and ideas to share, let's see, if blogging is the best way to do it. :)