Monday, July 28, 2008

Acceleration of Suguri

Když jsem zažil nečekaní úspěch s Neverhood, podíval jsem se po AppDB wine po dalších hrách s hodnocením Platinum a Gold. Hned u A mě zaujala svým názvem hra Acceleration of Suguri. Stáhnul jsem a ono to zase bez problémů fungovalo... Takhle budu muset za chvíli přejít na další OS, jinak nic užitečnýho neudělám ;-)



Je to jednoduchá arkáda, ale s krásnými postavičkami a veselou hudbou. Hrát se dá proti kamarádovi u počítače, přes síť anebo proti počítači. Trial má oproti plné verzi jen 3 holky - Suguri se světelným mečem, Saki s výbušnými kužely a Iru s plazmovou pistolí. Dále jsou k dispozici jen dvě scény - Forest a Lake. Myslím ale, že to vůbec nevadí, ono se to docela rychle omrzí.


Acceleration of Suguri
Acceleration of Suguri
A tady video na youtube, omluvte zhoršenou kvalitu, točil jsem to foťákem, aby tam byl i zvuk.

Systémové požadavky: CPU 1.2 GHz, RAM 256 MB, Video RAM 32MB, DirectX 8.1a


Příjemně mě překvapilo, že je to naprosto v pohodě hratelné i na notesu s přesně 32 MB VRAM.

Jak na to:
$ wget http://www.shindenken.org/daidai/AoSuguriTrial.zip
$ unzip AoSuguriTrial.zip
$ cd AoSuguriTrial
$ pasuspender wine AoSuguriTrial.exe


Sice je to podrobně japonsky popsáno na stránkách hry :-), ale neškodí si připomenout ovládání:




Menu:



Šipky

Z potvrzuje výběr



Hra:


Z normální útok

ZZ zesílený útok

X útok

XX zesílený útok

C speciální útok, je dostupný až poté, co několikrát zasáhnete protivníka. Velká číslice v půlkolečku nahoře ukazuje, kolik je jich k dispozici.

V rychlý pohyb

Z+X

A+Z útok ruční zbraní

A+X útok ruční zbraní na větší vzdálenost

A+C

S štít (je dostupný až poté, co několikrát zasáhnete protivníka - viz nápis SHIELD)

T menu

Esc odchod do OS




K nastavení síťové hry slouží config.exe, na třetí záložce je třeba nastavit IP adresu protivníka, ten musí udělat to samé. OK je to tlačítko vpravo.

Acceleration of Suguri

Bohužel síťová hra je trochu rozbitá, postavy na lokálním a vzdáleném stroji se liší a nesedí ani jejich poloha, takže u sebe souseda trefím, ale na jeho obrazovce minu.


Sunday, July 27, 2008

zabitej den


Včerejšek nebyl zrovna nejproduktivnější. Nejdřív jsem se konečně podíval na (1. díl) IT Crowd. Není to špatný, ale ty vtipy jsou většinou strašně předvídatelný.
No a pak jsem si pod vlivem zprávičky o další verzi Wine nainstaloval starou pecku Neverhood. Wine v MDV 2008.1 je sice jen ve verzi 0.9.58 (v Backports je 1.1.2, ale nemám je zapnuté, momentálně upřednostňuju stabilitu před bleeding edge), ale i tak to proběhlo naprosto bez potíží. Wine se musí nastavit jako Windows 95. Aby fungoval zvuk, je kvůli PulseAudio potřeba změnit ovladač zvuku ve winecfg na OSS (s esd to dost blblo, často byl místo zvuku jen šum) a taky spouštět wine s pasuspender (viz tady). Dohrál jsem to ve 4 ráno ...





Thursday, July 3, 2008

Customizing Asus AM200g - V. firmware modification

I would not dare to upload a firmware built from scratch, but what about only slightly modified one?

For me, it would suffice to just add a call to some script on the flash drive that would be launched at boot. From there I'd be able to do all I need (ATM).

The WL-600g GPL Makefile contains the following default sequence of commands in its buildimage section:

./buildFS
$(HOSTTOOLS_DIR)/mksquashfs $(TARGET_FS) $(PROFILE_DIR)/rootfs.img -noappend -be -lzma -no-fragments -noI
$(OBJCOPY) -O binary vmlinux vmlinux.bin
$(HOSTTOOLS_DIR)/cmplzma -k -2 vmlinux vmlinux.bin vmlinux.lz;\
$(HOSTTOOLS_DIR)/bcmImageBuilder --output $(CFE_FS_KERNEL_IMAGE_NAME) --chip $(BRCM_CHIP) --board $(BRCM_BOARD_ID) \
--productname $(CUSTOMER_PRODUCT_NAME) --blocksize $(BRCM_FLASHBLK_SIZE) --cfefile $(CFE_FILE) --rootfsfile rootfs.img --kernelfile vmlinux.lz --include-cfe;

Let's keep hoping that WL-600g is the same as AM-200g, try to reverse the process, do the modifications and put together again.
bcmImageBuilder should just put together the filesystem file, kernel, cfe file (st like bios - see OpenWRT - Everything you need to know about broadcom hardware (Part 1)) and some checksums. There is a utility done by OpenWRT people that should be a replacement of bcmImageBuilder. Here. From there I learned the structure of the header, let's repeat it here for the sake of completeness:
The header takes the first 256 bytes

/* Image component */
struct imagecomp {
uint8_t                 address[12];    /* Address of this component as ASCII */
uint8_t                 len[10];        /* Length of this component as ASCII */
};
/* Image tag */
struct imagetag {
uint8_t                 tagver[4];      /*   0 -   3: Version of the tag as ASCII (2) */
uint8_t                 sig1[20];       /*   4 -  23: BCM_MAGIC_1 */
uint8_t                 sig2[14];       /*  24 -  37: BCM_MAGIC_2 */
uint8_t                 chipid[6];      /*  38 -  43: Chip id as ASCII (6345) */
uint8_t                 boardid[16];    /*  44 -  59: Board id as ASCII (96345GW2, etc...) */
uint8_t                 bigendian[2];   /*  60 -  61: "1" for big endian, "0" for little endian */
uint8_t                 imagelen[10];   /*  62 -  71: The length of all data that follows */
struct imagecomp        cfe;            /*  72 -  93: The offset and length of CFE */
struct imagecomp        rootfs;         /*  94 - 115: The offset and length of the root file system */
struct imagecomp        kernel;         /* 116 - 137: The offset and length of the kernel */
uint8_t                 dualimage[2];   /* 138 - 139: use "0" here */
uint8_t                 inactive[2];    /* 140 - 141: use "0" here */
uint8_t                 reserved1[74];  /* 142 - 215: reserved */
uint32_t                imagecrc;       /* 216 - 219: crc of the images (net byte order) */
uint8_t                 reserved2[16];  /* 220 - 235: reserved */
uint32_t                headercrc;      /* 236 - 239: crc starting from sig1 until headercrc (net byte order) */
uint8_t                 reserved3[16];  /* 240 - 255: reserved */
};

Let's decompose it for the firmware from Joyce:
tagver="36 00 00 00" = "6..."
sig1="42 72 6f 61 64 63 6f 6d 20 43 6f 72 70 6f 72 61 74 69 6f 00" = "Broadcom Corporatio."
sig2="76 65 72 2e 20 32 2e 30 00 00 00 00 00 00" = "ver. 2.0......"
chipid="36 33 34 38 00 00" = "6348.."
boardid="39 36 33 34 38 47 57 2d 31 31 00 00 00 00 00 00" = "96348GW-11......"
bigendian="31 00" = "1"
imagelen="33 38 32 32 33 35 36 00 00 00" = "3822356..." #indeed 3822356 + 256 = 3822612 (the size of the firmware file)
cfe="33 32 31 37 30 33 31 31 36 38 00 00 36 32 31 37 32 00 00 00 00 00" = "32170311..62172....." # this starts to be tricky ...
## 62172 is clearly the cfe size, but the cfe itself is slightly different from the files provided in the WL-600g GPL package.
rootfs="33 32 68 31 37 30 39 36 39 36 30 00 00 33 31 33 37 35 33 36 00 00 00" = "3217096960..3137536..." #fs size = 3137536
kernel="33 32 32 30 32 33 34 34 39 36 00 00 36 32 32 36 34 38 00 00 00 00" = "3220234496..622648...." # kernel size = 622648
## 3137536+622648+62172+256=3822612 - all fits so far!
dualimage="00 00"
inactive="00 00"
reserved="00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00"
imagecrc="c9 ea a8 50"
reserved2=""

The reserved2 part is different from WL-600g - after some experimentation, I found out that the first four bytes are CRC of the fs image and the second four bytes are CRC of the kernel, but was not able to figure out the CRC algorithm.
to extract cfe:
dd bs=1 if=JOYCE_IAD_U2_B_306063520_cfe_fs_kernel of=cfe skip=256 count=62172
to extract fs:
dd bs=1 if=JOYCE_IAD_U2_B_306063520_cfe_fs_kernel of=fs skip=62428 count=3137536
to extract kernel:
dd bs=1 if=JOYCE_IAD_U2_B_306063520_cfe_fs_kernel of=kernel skip=3199964 count=622648

By calling the Asus' bcmImageBuilder command on the extracted files, I got a firmware identical (verified with md5sum) to the original:
../../Dokumenty/GPL_AM604G_ForRussia/GENERIC_6348_WLAN_A34_3-06-02-01/hostTools/bcmImageBuilder --output bcmimage --chip 6348 --board 96348GW-11 --blocksize 64 --cfefile cfe --rootfsfile fs --kernelfile kernel --include-cfe

So, let's proceed further...
$ file fs
fs: Squashfs filesystem, big endian, version 2.0, 3136535 bytes, 423 inodes, blocksize: 65536 bytes, created: Mon May 28 08:35:59 2007

the file command confirms the fs file is indeed a squashfs image. Let's extract it:
$ unsquashfs -s fs
Reading a different endian SQUASHFS filesystem on fs
Can't find a SQUASHFS superblock on fs

This is already reported in Ubuntu, I reported it to the Mandriva guys as well.
The hand-compiled squashfs 3.3 seemed to work just fine, but it was not able to deal with the Broadcom specific lzma compression. I tried to mount the fs file on the router, but unfortunately mount was not compiled with support for mounting loop devices
# mount -o ro -o loop /var/usb/usb_2/fs /var/usb/a
mount: Mounting /var/usb/usb_2/fs on /var/usb/a failed: Block device required

After some retries I found out about the excellent OpenBox4 people hacking another Broadcom based ADSL router. They developed nb4-unsquash - a tool to extract the content of Broadcom-lzma-compressed squashfs.


But I still did not trust it entirely. I found out I can mount the internal flash and that's enough for me.
First I made a backup of the original fs:
# mkdir /var/usb/a
# mount -o ro /dev/mtdblock0 /var/usb/a
# /var/usb/usb_1/bin/tar cvf /var/usb/usb_2/firmwarefs.tar /var/usb/a/

Copied the filesystem to my PC:
on-my-PC $ mkdir /tmp/fs
on-my-PC $ netcat -l -p 9000 | dd of=/tmp/fs/fs.tar
on-router# /var/usb/usb_1/bin/dd if=/var/usb/usb_2/firmwarefs.tar |/var/usb/usb_1/bin/mipsel-linux-netcat 192.168.1.64 9000

Unpacked (as root because the contents are special files):
$ su
# cd /tmp/fs
# tar xvf fs.tar

Before doing any modifications I tried recreating the squashfs image:
# /home/hajma/Dokumenty/GPL_AM604G_ForRussia/GENERIC_6348_WLAN_A34_3-06-02-01/hostTools/mksquashfs /tmp/fs/var/usb/a rootfs.img -noappend -be -lzma -no-fragments -noI

and verified with the nb4-unsquash that it looks similar to the original one:
# nb4-unsquash -d new rootfs.img
# nb4-unsquash -d old /tmp/joycefs
# ls -laR old/ > /tmp/oldfslist
# ls -laR new/ > /tmp/newfslist
# kdiff3 /tmp/oldfslist /tmp/newfslist

I saw that all except some modification times was identical, so I put the recreated fs together with the old kernel and cfe:
# /home/hajma/Dokumenty/GPL_AM604G_ForRussia/GENERIC_6348_WLAN_A34_3-06-02-01/hostTools/bcmImageBuilder --output bcmimage --chip 6348 --board 96348GW-11 --blocksize 64 --cfefile cfe --rootfsfile rootfs.img --kernelfile kernel --include-cfe

Then I took a deep breath and flashed the router with the recreated firmware ... ... ... ... ... ...
And it worked!

Unfortunately it was not possible to simply find a place in the boot sequence where everything is already done and flash is mounted. The /etc/profile, launched by the line ::respawn:-/bin/sh of /etc/inittab, calls /bin/cfm, which takes care of all the ADSL settings and mounting the flash - but it stays loaded and the script does not go on. So after several retries I found a solution - added another line to the /etc/inittab:

$ diff -u inittab.old inittab
--- inittab.old 2008-07-03 00:31:44.000000000 +0200
+++ inittab     2008-07-03 00:31:52.000000000 +0200
@@ -1,5 +1,6 @@
+::respawn:-/bin/myscript.sh
tty2::askfirst:-/bin/sh

that will launch a script that waits until the flash drive is mounted and then passes the command to script residing on the flash:
$ cat bin/myscript.sh
#!/bin/sh
while [ "`echo /var/usb/usb_*`" = "/var/usb/usb_*" ]; do
ping 127.0.0.1 # the shell does not have the sleep builtin, hence using ping as a substitute
done
ping -c 20 127.0.0.1 # wait 20 seconds after the usb is mounted just to be sure load is not too high
/bin/sh /var/usb/usb_2/myscript.sh > /var/usb/usb_2/myscript.log 2>&1

Then I created the new image:
# /home/hajma/Dokumenty/GPL_AM604G_ForRussia/GENERIC_6348_WLAN_A34_3-06-02-01/hostTools/mksquashfs /tmp/fs/var/usb/a rootfs.img -noappend -be -lzma -no-fragments -noI

Combined with the rest of the lot:
# /home/hajma/Dokumenty/GPL_AM604G_ForRussia/GENERIC_6348_WLAN_A34_3-06-02-01/hostTools/bcmImageBuilder --output bcmimage --chip 6348 --board 96348GW-11 --blocksize 64 --cfefile cfe --rootfsfile rootfs.img --kernelfile kernel --include-cfe


and flashed. Works like a charm. I put the firmware to the OpenWRT page on AM-200g. direct link



In the next part I'll try to fix the dhcp.



FYI, this is the content of the /var/usb/usb_2/myscript.sh file, launching the jabber daemon:

#!/bin/sh
/bin/iptables -I INPUT -p tcp -i ppp_8_48_1 --dport 5222 -m state --state NEW -j ACCEPT
/bin/iptables -I INPUT -p tcp -i ppp_8_48_1 --dport 5223 -m state --state NEW -j ACCEPT
/bin/iptables -I INPUT -p tcp -i ppp_8_48_1 --dport 5269 -m state --state NEW -j ACCEPT
/var/usb/usb_1/bin/jabberd -c /var/usb/usb_2/jabberd/jabber.xml

FYI, the steps to cross-compile netcat and coreutils (for the tar and dd commands):
$ wget ftp://heanet.dl.sourceforge.net/n/ne/netcat/netcat-0.7.1.tar.bz2
$ tar xvf netcat-0.7.1.tar.bz2
$ cd netcat-0.7.1
$ ./configure --build=i686-pc-linux-gnu --host=mipsel-linux --target=mipsel-linux --prefix=/var/usb/usb_1
$ make
$ make install
$ cd ..
$ wget http://ftp.gnu.org/gnu/coreutils/coreutils-6.9.tar.bz2
$ tar xvf coreutils-6.9.tar.bz2
$ cd coreutils-6.9
$ ./configure --build=i686-pc-linux-gnu --host=mipsel-linux --target=mipsel-linux --prefix=/var/usb/usb_1
$ make
$ make install

Customizing Asus AM200g - IV. jabberd configuration

Customizing Asus AM200g - III. jabberd and vim

Customizing Asus AM200g - II. Preparing the environment

Customizing Asus AM200g - I. PREPARATION