This is an old revision of the document!
Table of Contents
Getting Slackware ARM on the Toshiba AC100 (also know as the Dynabook AZ)
When all this started off I was using ARMedslack 13.37 but as of version 14 the official Slackware ARM port changed name to Slackware ARM. Any reference to ARMedslack in this short tutorial refers to the Slackware ARM official port.
Preface
The Slackware ARM userland can run on almost any ARM based hardware out there and the Toshiba AC100 is no exception to that rule of thumb. The only impediment to going straight ahead is the kernel. I like to work around the problem by borrowing the kernel from some other distribution that has support for the AC100. currently you have 3 options to get reasonable support for the hardware:
- 2.6.38 kernel patched up for AC100
- 3.0 kernel patched up for AC100
- 3.15+ mainstream kernel (untested yet)
The 3.1 kernel development got broken on the way and to my understanding is unmaintained.
There are several places you can get the binary kernel images or the sources to compile them I generally look for Ubuntu first. Initially I used the Ubuntu kernel version 2.6.38 but over time I upgraded to version 3.0.27.
Requirements
What you'll need:
- kernel image for AC110 in zImage along with the kernel modules and firmware (here is the one I use)
- abootimg utility for manipulating the images (git clone –depth 1 https://gitorious.org/ac100/abootimg.git)
- tegra-linux utility for doing the nvflash stuff (available from Toshiba at the time of writing)
- Slackware ARM miniroot tarball from http://ftp.slackware.org.uk/slackwarearm/slackwarearm-devtools/minirootfs/roots/
- A copy of the content of /proc/cmdline before you change kernel
Initrd
Although it is technically possible to boot without using an initrd I've not had the time to experiment that. If all you need is simple boot then the initrd only really needs busybox and a very simple script that mounts root and then switches root.
This is what my init script looks like in the initrd image:
#!/bin/sh exec 3>&1 mount -t sysfs -o nodev,noexec,nosuid none /sys mount -t proc -o nodev,noexec,nosuid none /proc sysctl -w kernel.printk="4 4 1 7" >/dev/null 2>&1 mount -t tmpfs -o mode=0755 none /dev mknod -m 0600 /dev/console c 5 1 mknod /dev/null c 1 3 mkdir /dev/pts mount -t devpts -o noexec,nosuid,gid=5,mode=0620 none /dev/pts busybox mdev -s sleep 5 echo 0x0100 > /proc/sys/kernel/real-root-dev mount -o ro /dev/mmcblk0p7 /root if [ ! -r /root/sbin/init ] then /bin/sh fi umount /proc umount /sys umount /dev/pts exec switch_root /root /sbin/init 3
You can extract the scriot from my rescue and boot images if you need: first use abootimg to extract the initrd.img then use zcat | cpio -idm to extract the content from the initrd image. Edit the above script to suit where you want to boot the miniroot from (in my case this is the internal EMMC drive biggest partition) and load any modules that are required for booting (my kernel configuration does not need to do that buy if you borrowed the binary kernel from somewhere you might need some modules for the FB console or for the mass storage). Make sure the minitoot fstab has the correct root device too.
Repackaging the boot image for Aboot
If you made changes to the initrd you need to repackage that first. From your initrd tree repackage the initrd image:
find . | cpio -o -H newc |gzip -9c > ../initrd.img
Then repackage the image for aboot:
abootimg –create slack.img -k zImage -f bootimg.cfg -r initrd.img
You are now ready to try your rescue image without actually flashing it.
Before you actually go ahead it's a good idea to make a backup of the original rescue image. Start your device into recovery mode (POWER + ESC + CTRL) and then from the pc where you have the tegra-linux utils run the following commands:
nvflash --bl harmony/fastboot.bin --sync nvflash -r --read 5 original_part05_rescue.img
Then restart your device into recovery mode (POWER + ESC + CTRL) an load the rescue image into ram:
nvflash --bl rescue.img --sync
If loading the rescue image directly into ram fails you will haveto flash it to the rescue partition:
nvflash --bl harmony/fastboot.bin --sync nvflash -r --download 5 sosboot.img
And then boot into rescue (POWER + HOME).
If the rescue image works fine you can use it to flash itself to the rescue partition. On my device the rescue partition is /dev/mmcblk0p1 and the normal boot partition is /dev/mmcblk0p2. You will use dd for the rescue and boot images and mk?fs/tar for the root filesystem. Your images need to be on SD or usb mas storage so that you can read them from the rescue system.
Rebooting
Your safest bet is probably to flash the rescue image first and then use that to do the rest, in doing this you will be forced to make sure the initrd is set up right for whatever you want to do.
Boot while pressing HOME and then hit 1
You should get dropped into a shell. If you ruut will be on SD ot USB then you can probabbly prepare them from another PC but if you want to use the internal EMMC: Format your target root partition mount it and extract the miniroot tarball to it. Make sure you set up fstab on the root partition to match your system. Mount the real root and try chroot to it to check all in in place.
Replicate the changes you made to the rescur image to the boot image too. Reboot again into rescue mode and flash the boot image to /dev/mmcblk0p2 (or where ever the boot image should be on your device). Reboot and enjoy.
Managing the boot image from the AC100
Once you have any sort of linux up and running on the AC100 (and the tegrapart command line sent to kernel is correct for your hardware) you can manage your boot images directly from the AC100.
You can dump the raw images like this (this dumps the recovery partition boot image {partition 5 seen from nvflash} on my device)
dd if=/dev/mmcblk0p1 of=recovery.img
You can then extract kernel and initrd with the unpack_bootimage, modify things and repackage it with the make_bootimage. the bootimage utils are available in source and can be compiled on you AC100 linux distro.
Write back the image with dd again. Once you're up the firs time you will need to complete the miniroot with all the other packages you need to make it into a desktop machine. The quickest way to do this is probably to install manually slackpkg and then use that to install the rest of the stuff.
Handy Workarounds
Here are some little issues I worked around that other people might find handy
MPlayer
Mplayer from armedslack has unsuitable defaults for the AC100 so if you want video and audio playback go and edit /etc/mplayer/mplayer.conf and set these two lines:
vo=x11 ao=alsa
pppd
pppd does not correctly setup /etc/resolve.conf … I worked around this by writing very simple ip-up and ip-down to be put in /etc/ppp/
/etc/ppp/ip-up:
#!/bin/bash if [ $USEPEERDNS -eq 1 ] then cp /etc/resolv.conf /etc/org_resolv.conf > /etc/resolv.conf [ "$DNS1" != "" ] && echo "nameserver $DNS1" >> /etc/resolv.conf [ "$DNS2" != "" ] && echo "nameserver $DNS2" >> /etc/resolv.conf [ -s /etc/resolv.conf ] && cat /etc/ppp/resolv.conf > /etc/resolv.conf fi
/etc/ppp/ip-down:
#!/bin/bash [ -s /etc/org_resolv.conf ] && cat /etc/org_resolv.conf > /etc/resolv.conf
Battery Status
Acpi is not working right and apm seems useless so I read the battery charge state directly from /sys/class/power_supply/battery/charge_now but the format is not directly human readable so I wrote something that calculates is as a percentage:
echo " $(echo "($(cat /sys/class/power_supply/battery/charge_now) * 100) / $(cat /sys/class/power_supply/battery/charge_full_design)" | bc) %"
You will get an error if you run this when the AC100 is on AC power without the battery.
Adobe Flash plugin
Although you cannot download it from adobe, Android has the blasted libflasplayer.so library but even if you hack it out of some apk you will run into trouble with incompatible libraries dew to the different instruction sets used in android and ARMedslack. In order to get some basic flash support in my ARMedslack AC100 I used swfdec: it will not play youtube videos as you get told that you need to update but it's better then nothing. I've been reported that the android libflasplayer.so works on Slackware ARM 14.
Hardware information
Here is some of the information I fetched on my AC100 before going into reflashing it with a different OS
The original partition layout
This is the layout on a 10G device, layout may be slightly different on other versions. Retreave this by using nvflash –getpartitiontable:
part # name size description remarks 2 BCT 3 145 728 (3 MB) boot config table 3 PT 524 288 (512 kB) partition table 4 EBT 2 097 152 (2 MB) bootloader 5 SOS 5 242 880 (5 MB) recovery partition 6 LNX 8 388 608 (8 MB) linux kernel and initrd kernel starts at 0x800 initrd starts at 0x20E800 7 MBR 1 048 576 (1 MB) master boot record 8 APP 314 572 800 (300 MB) applications (/system) 9 CAC 419 430 400 (400 MB) cache (/cache) 10 MSC 2 097 152 (2 MB) misc (/misc) 11 EM1 524 288 (512 kB) 12 UBA 1 294 991 360 (1235 MB) user data (/data) 13 EM2 524 288 (512 kB) 14 UDB 5 950 144 512 (5674.5 MB) user data (/storage)
A possible way to boot linux the first time
If I remember correctly I think this is how I first got my custom image from my linux PC to the AC100 with the linux4tegra utilities. I targeted the rescue partition so that if something went wrong I'd still have android working right from partition 6. If you have a rooted android with a terminal you could possibly do this from android by using dd on the correct block device or alternatively try booting the image and ramdisk without actually writing the images to flash until you have tested them to work correctly. At the time I did it the nvflash tool was poorly documented so I did not attempt booting the image without writing it to flash.
Start in Recovery mode
$ nvflash --bl fastboot.stock.bin --go
Backup your target partition
$ nvflash --resume --read 5 part05.img
Erase the kernel partition
$ nvflash --resume --format_partition 5
The system should go automatically to fastboot mode
Flash a kernel and a ramdisk
$ fastboot flash:raw boot zImage init.img
Manipulating the boot image
This is an example of how I manipulate the boot image:
# unpack a partition: $ ./unpack_bootimg part05.img kernel size = 2153760 kernel addr = 10008000 ramdisk size = 421004 ramdisk addr = 11000000 second size = 0 second addr = 10f00000 tags addr = 10000100 page_size = 2048 name = cmdline = id = 4ed00528 cb58acc7 f259f0eb 97d77baf e5bb19fd 00000000 00000000 00000000 extracting kernel in zImage extracting ramdisk in initrd.img # modifying a partition, updating the kernel and ramdisk $ ./make_bootimg part05.img zImage initrd.img kernel size = 2153760 kernel addr = 10008000 ramdisk size = 421004 ramdisk addr = 11000000 second size = 0 second addr = 10f00000 tags addr = 10000100 page_size = 2048 name = cmdline = id = 4ed00528 cb58acc7 f259f0eb 97d77baf e5bb19fd 00000000 00000000 00000000 kernel size = 2153760 ramdisk size = 421004 # updating the boot cmdline: $ ./make_bootimg part05.img -c "mem=448M@0M nvmem=64M@448M vmalloc=320M video=tegrafb console=ttyS0,115200n8 usbcore.old_scheme_first=1 tegraboot=sdmmc tegrapart=recovery:700:a00:800,boot:1100:1000:800,mbr:2100:200:800,system:2300:25800:800,cache:27b00:32000:800,misc:59b00:400:800,userdata:5a000:9a600:800"
If you install the tools on the AC100 you can do this all from ARMedslack on the AC100.
Onboard EMMC Layout
Offsets show below are absolute … while offsets seen in tegrapart (from the kernel boot args) seem off from these absolute values by -2048 (-0x800).
The tegrapart format is a coma separated list od items like this :
<partition name>:<hex start sector>:<hex partition size in sectors>:<hex sector size in bytes>,...
Tere's the EMMC layout of my device:
PartitionId=2 Name=BCT DeviceId=18 StartSector=0 NumSectors=1536 BytesPerSector=2048 PartitionId=3 Name=PT DeviceId=18 StartSector=1536 NumSectors=256 BytesPerSector=2048 PartitionId=4 Name=EBT DeviceId=18 StartSector=1792 NumSectors=1024 BytesPerSector=2048 PartitionId=5 (seen as mmcblk0p1 recovery) Name=SOS DeviceId=18 StartSector=2816 (0xb00) (but offsets in boot args seem to be off by -0x800 <2048> from this value) NumSectors=2560 BytesPerSector=2048 (0x800) PartitionId=6 (seen as mmcblk0p2) Name=LNX DeviceId=18 StartSector=5376 (0x1500) NumSectors=4096 BytesPerSector=2048 (0x800) PartitionId=7 Name=MBR DeviceId=18 StartSector=9472 NumSectors=512 BytesPerSector=2048 (0x800) PartitionId=8 (seen as mmcblk0p3 mbr) Name=APP DeviceId=18 StartSector=9984 NumSectors=153600 BytesPerSector=2048 (0x800) PartitionId=9 (seen as mmcblk0p4 system) Name=CAC DeviceId=18 StartSector=163584 NumSectors=204800 BytesPerSector=2048 (0x800) PartitionId=10 (seen as mmcblk0p5 cacche) Name=MSC DeviceId=18 StartSector=368384 NumSectors=1024 BytesPerSector=2048 (0x800) PartitionId=11 Name=EM1 DeviceId=18 StartSector=369408 NumSectors=256 BytesPerSector=2048 (0x800) PartitionId=12 (seen as mmcblkp6 misc) Name=UDA DeviceId=18 StartSector=369664 NumSectors=632320 BytesPerSector=2048 (0x800) PartitionId=13 Name=EM2 DeviceId=18 StartSector=1001984 NumSectors=256 BytesPerSector=2048 (0x800) PartitionId=14 (seen as mmcblkp7 userdata) Name=UDB DeviceId=18 StartSector=1002240 NumSectors=6837504 BytesPerSector=2048 (0x800)
Building Newer 3.0 Kernel
There has been a lot of work done on mainstream kernel from 3.8 on, but I've not had the time to check out if it's functional enough to be used on the AC100 as a netbook and besides that there are also other issues that are holding me back on doing the testing on mainstream kernel:
- I still have not wired up the uart for debugging things if the frame buffer console ceases to function as expected
- mainstream kernels do not support tegra part so work needs to be done to migrate on-board emmc to gpt partition
- at some point also fdt will need attention too
According to ac100.grangow.net form 3.15 on there is full support on mainstream kernel.
Native kernel build (in order to compile this native 512Mb arr not sufficient so you need to swap on something {SD,usb storage or internal emmc}: an extra 512Mb swap will suffice). It;s technically possible to work form marvin's kernel git but I've not been able to configure that kernel to boot correctly … it hangs while attempting to read RTC, but it's probably just something wrong that I did in the configuration. #git clone –depth 1 -b chromeos-ac100-3.0 https://gitorious.org/~marvin24/ac100/marvin24s-kernel.git
wget https://launchpad.net/ubuntu/+archive/primary/+files/linux-ac100_3.0.27-1.1.tar.gz tar xf linux-ac100_3.0.27-1.1.tar.gz cd linux-ac100-2.6.38 #yeah the mane of the directory is misleading ! make paz00_defconfig make zImage modules firmware INSTALL_MOD_STRIP=1 make firmware_install make modules_install INSTALL_MOD_STRIP=1
Prepare The Image For Booting
Once you've the modules in place you need to package the kenel in aboot format … I previously did this with an old tool … there's now a standard tool: “abootimg”
git clone --depth 1 https://gitorious.org/ac100/abootimg.git cd abootimg make make install
There are 2 possibilities for booting with the stock boot loader:
- form the normal boot partition (/dev/mmcblk0p2 on my device)
- from the rescue boot partition (/dev/mmcblk0p1 but only works on android 2.1 systems)
You can choose to leave the normal boot partition alone and target the rescue partition or vice versa but don't mess with both until you have transitioned to a functional system.
The rescue partition is only 5Mb while the normal boot is 8Mb depending on how bid your image is you might be forced to use the ordinary boot … but conceptually the image creation is the same.
Dump your target partition with whatever tool is most convenient: dd if you have a linux system or rooted busybox on the AC100 or nvflash for non rooted devices. then examine the image with “abootimg -i”
root@ac100:~# abootimg -i /dev/mmcblk0p2 Android Boot Image Info: * file name = /dev/mmcblk0p2 [block device] * image size = 8388608 bytes (8.00 MB) page size = 2048 bytes * Boot Name = "Ubuntu Boot Img" * kernel size = 2628788 bytes (2.51 MB) ramdisk size = 2219793 bytes (2.12 MB) * load addresses: kernel: 0x10008000 ramdisk: 0x15000000 tags: 0x10000100 * empty cmdline * id = 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 root@ac100:~#
You also need to save the original command line passed to the kernel because it's not stored in the original image.
root@ac100:~# cat /proc/cmdline mem=448M@0M lp0_vec=0x2000@0x1c29e000 tegraboot=sdmmc tegrapart=recovery:300:a00:800,boot:d00:1000:800,mbr:1d00:200:800,system:1f00:25800:800,cache:27700:32000:800,misc:59700:400:800,userdata:59c00:9a600:800 root@ac100:~#
When you repackage up the image you will want to add to those arguments: “root=<root device> rootwait ro” where <root device> will be wherever your root filesystem will be (/dev/mmcblk0p7 for internal EMMC, /dev/mmcblk1p1 if root will be on the SD's first partition or /dev/sda1 if on a usb stic's first partition).
The first time I repackaged up an image I did not know much about aboot so I used a custom inirtd to leave the boot process as close as possible to the original … but it is possible to boot without initrd I just have not had time to play with it. It your original image is from android you may need to create your own initrd … the kernel has all that's required to boot so the initrd needs only do vary basic stuff (all that you really need is busybox if all you want is just booting).
First extract the contents of the original image by running “abootimg -x <image_file_name>” This will extract the config file, the kernel and initrd (bootimg.cgf, zImage and initrd.img respectively)
Modify the bootimg.cfg to look something like this:
root@ac100:/boot# cat bootimg.cfg bootsize = 0x800000 pagesize = 0x800 kerneladdr = 0x10008000 ramdiskaddr = 0x15000000 secondaddr = 0x10f00000 tagsaddr = 0x10000100 name = Slackware Boot Img cmdline = mem=448M@0M lp0_vec=0x2000@0x1c29e000 tegraboot=sdmmc tegrapart=recovery:300:a00:800,boot:d00:1000:800,mbr:1d00:200:800,system:1f00:25800:800,cache:27700:32000:800,misc:59700:400:800,userdata:59c00:9a600:800 root=/dev/mmcblk0p7 rootwait ro root@ac100:/boot#
If the original image is an android image you need to create your own initrd. Replace the zImage with whatever you compiled and repackage it up with “abootimg –create slack.img -k zImage -f bootimg.cfg -r initrd.img”
Flash the new boot image back to the partition you decided ti target (with whatever method was used to extract it in the first place) and reboot.
Audio With The Newer Kernel
Finally the speakers are working but in order to get any audio out of the AC100 with 3.0 kernels you haveto do a few things:
- use alsamixer to unmute everything (or at least selectively what you need)
- run “alsaucm -c tegraalc5632 reset” to reset the audio hardware
- use “alsactl store” to store the settings so that you can restore them at boot time
You can then add this to rc.local
/usr/bin/alsaucm -c tegraalc5632 reset /usr/sbin/alsactl restore
Contacts
If you have any issues or suggestions about this short tutorial you are welcome to contact me ( louigi600 (at) yahoo (dot) it) or even contribute yourself directly on this wiki. I apologize in advance for any vital information that may have been left out when tosh-ac100.wetpaint.com was blocked and this how-to was moved here.