First, a little background. A small continuation of the story with the GV2B media player, which I described earlier tu / t . Let me remind you that initially the box was not bought as an Android set-top box for the TV, but as a more powerful replacement for the Raspberry Pi, for which I left an application in April, but which will arrive only in August. And the GV2B was in my hands 8 days after the order, for only $ 100 and with a complete set of cables (which is only $ 5 more expensive than a Raspberry Pi kit with charging, cords and a case).
I’ll reassure the spiteful people from my previous post that Youtube and other applications installed with Play worked fine, and no more shortcomings were found in the device.
More recently, a couple of topics appearedwhich described how Puppy Linux, Arch Linux, and Ubuntu were installed on ARM devices. This is a unique feature of the Allwinner A10, which is difficult to underestimate, but still the system is physically launched from the SD card, not the built-in flash. I began to work more actively on the issue, and came across as many as three ways to flash something into the device’s flash memory, which is encouraging and, possibly, opens a loophole for filling in full-fledged GNU / Linux. I arrogantly note that this is the next step after the banal launch of a slightly dopped image from an SD card.
goal
- Install the Linux kernel on the device. The newest is desirable. Or the newest of those that contains all the device-specific drivers;
- Put GNU;
- Put the desktop environment;
- Make a backup so that the device can be returned to its original state if something goes wrong;
- Have some fun with the challenge (comparable to installing the first versions of USB downloaders on a Wii and going through NetHack or Dwarf Fortress).
Facilities
A GV-2B device from an unknown Chinese manufacturer based on Rockchip 2918 (RK29 for short) (CPU ARM Cortex A8 1GHz + GPU Vivante GC800 600MHz), with 4GB flash memory, 512MB RAM and a good number of connectors.
SD card 16GB class 10.
PC with Arch Linux.
Keyboard.
Monitor.
An HDMI-DVI cord for connecting a monitor.
A bunch of USB cords, adapters, etc.
Caution and Self-Flagellation
Surely many of the readers would have done what is described in the topic, or at least some specific part, faster and better, but I did not find any mention of such a feat in the vastness of the network. The topic contains a lot of practice and very little theory, only the most necessary to understand what is being discussed and what is happening (I admit honestly, I and the theory itself in the described areas are clearly not enough). From an academic point of view, he is drawn to a three-hour laboratory work. I also want to say that for the first time I am doing all this, if I exclude the connection of a disk with Ubuntu pre-installed on the desktop computer to a PC104 x86-compatible single-board.
Device selection
In the G lineup there are about twenty different devices, on different processors, with a different number of connectors, but about the same functionality.
At first I was afraid that I did not take the device on the Allwinner A10, but after reading several reviews about the openness of the kernel source for it, I realized that with Rockchip the situation is not much worse.
There was an option to order a device of the same model range, but already with Cortex A9, namely AmLogic 8726-M, but it doesn’t have any unusual advantages over Rockchip 2918, and judging by the AmLogic website , it also has the source code for the latest chips sadly.
Methods
So, there were found three ways to update the firmware of the device (the contents of the same 4GB flash memory).
The first one didn’t work from a manufacturer using one of the OEM models of the GV line, and it’s good, because their firmware is for a slightly different device, which has three USB ports, and the difference between them is so serious that usually the firmware turns around turning the device into the brick.
There are two left. The second, from a hacker with AndroidForums , is that you need to click on the additional, second reset button located inside the box, while holding it hold the power button for several seconds. This method revealed interesting features, namely the Android system recovery utility v1.3.37 menu (obviously 1337), offering a choice:
- Reboot system now
- Factory reset
- SYSTEM recover
- Update from SDCARD
- Update from uDisk
- Factory test
Unfortunately, the keyboard, when connected to the device, and works fine after loading Android, on the system recovery menu It had no effect, and of the three buttons on the board (power, reset, still reset), only one acted on the menu - the first reset, which either led to the selection of the default active option Reboot system now, or it just worked for its intended purpose. The remaining cursor buttons, unfortunately, did not move. The method was precisely to fill in the firmware from the SD memory card, which did not work out in any way.
After formatting the SD card in fat32, I uploaded the downloaded update for Android with difficulty to download it from the file storage (God, didn’t they hear about Dropbox?) During normal boot Android cursed that the wrong update.img is on the SD card. But I still didn’t hurry to fill it, because backups are not only made by cowards, but on the forums it was often reported that pouring one or another update.img that one author earned on a similar device led to turning it into a brick from another author.
The third son of the method turned out to be closer to what I was going to do. It consisted in connecting the device to a computer using a USB cable.
At first, it was very embarrassing that in system recovery mode the device was not detected from the computer in any way, despite the fact that I connected all the necessary wires to the right place (and even not to the right place, directing the oncoming power to 4.57V and 5.08V via USB, which fortunately did not turn out to be any consequences). As it turned out later, it should be so, because they have their own protocol there, and the difference with connecting external media is significant.
Under Windows, the Rockchip Flasher tool was discovered, which the language doesn’t dare to call wonderful, because it was done terribly and the only thing that can do it is to flash new update.img. But I had to not only flash, but also download the existing one, in case something suddenly went wrong, so I had to refuse the work of Chinese programmers.
With legs, by the way, you need to be careful.
Backup
I want to save everything that is stored in flash memory to be able to restore everything to its original version, if something goes wrong. There are several different methods for this.
Titanium Backup . Android application with which you can take a picture of the system partitions and copy it to the SD card. Everything would be fine, but you need to root the device for this (get administrative privileges). In order to root the device on Android 2.3.1, Universal Androot is no longer suitable, and its author suggests choosing to use Unrevoked , which is suitable only for HTC phones, or SuperOneClick, which seems to be good for everyone, but in order to install the device it requires connecting it with a cord to a Windows computer. Everything would be nice, but he downloads the firmware, adds some files there and uploads it back. Changing the firmware in order to backup it is insanity.
It remained to take advantage of the Android Debug Bridge from the Android SDK, which is not a fact that it would work with this particular device, and pulling along a considerable number of dependencies, which I did not want at all. Everything else, it was necessary to collect all this from the source (read AUR for Arch Linux).
It was already sad, I suddenly discovered the wonderful utility RK29kitchen , announced here which, judging by the description, has absorbed a number of other no less remarkable utilities from the authors who have disassembled the tricky protocol for communicating devices via USB, and a slightly less tricky file with a partition table.
Launch
It turned out to be not so simple. It turns out that the device should not be in system recovery mode, but in the off state, but always with the power on. The problem is that it tries to turn on as soon as it senses that it is connected via USB. But this can be controlled. Holding both reset buttons for 5 seconds, I release first the internal one, and after 3 seconds the internal one. I launch and try to be patient.
$ ./flashdump.sh
Check that your tablet is in the firmware flash mode and connected to computer
rkflashtool: info: interface claimed
rkflashtool: info: reading flash memory at offset 0x00000100
unpacking...OK
Dumping misc (rkflashtool29 r 0x00002000 0x00002000 )
Dumping kernel (rkflashtool29 r 0x00004000 0x00004000 )
Dumping boot (rkflashtool29 r 0x00008000 0x00002000 )
Dumping recovery (rkflashtool29 r 0x0000a000 0x00004000 )
Dumping system (rkflashtool29 r 0x0000e000 0x00080000 )
Dumping backup (rkflashtool29 r 0x0008e000 0x00082000 )
What confuses us a bit is that the flashdump source code says:
rkflashtool29 r 0 0x200
And in conclusion:
reading flash memory at offset 0x00000100
It’s not entirely clear from which offset parm.img is read.
So, for 5-10 minutes and a golden key , I have an image of flash memory entirely and separately of all sections:
$ ls -l flashdump/Image/
4194304 Jun 29 18:15 boot.img
8388608 Jun 29 18:15 kernel.img
4194304 Jun 29 18:14 misc.img
8388608 Jun 29 18:16 recovery.img
268435456 Jun 29 18:18 system.img
$ ls -l flashdump
272629760 Jun 29 18:21 backup.img
4096 Jun 29 18:16 Image
583 Jun 29 18:13 parameter
262144 Jun 29 18:13 parm.img
What happened? If you delve into the forums and source codes of RK29kitchen, it becomes clear that I just read the contents of the device’s flash memory, starting with the partition table, which we sorted into shelves and recorded in the parameter text file, and using it, wrote down the partition table separately.
Here there was found an incredible amount of information relating specifically to update the flash memory on the RK2918 devices. All the devices described are tablets, and connecting them to a computer for updating is somewhat easier (considering the built-in microUSB port, it's also USB OTG).
The last line, using the hexadecimal system, contains the lengths, the beginning of the sections, and their name in brackets. Missing required section, which actually stores the partition table itself. I'll try to decrypt.
The size of the parameter block read is 0x200 (from the source files of RK29kitchen), it is 512, and the file size is 262144 bytes. It turns out that the size of the conditional block is 262144/512, that is, 512 bytes, which is confirmed by the documentation for rkflashtool.
What takes up memory between 0x200 and 0x2000, and this is as much as 3.75MB is a mystery.
parameter (partition table)
256KB
misc
4MB
kernel
8MB
boot
4MB
recovery
8MB
system
256MB
backup
260MB
cache
116MB
userdata
512MB
kpanic
4MB
user
all remaining space
Preparation
Now I have in my hands a set of img files, disk images that I downloaded. I wonder what's inside. From previous knowledge I know that to write files that are not intended to be changed (such as the kernel of the OS) to flash memory, they are made in cramfs format , but some very cunning Chinese people manage to add headers and footers to these images, then use gzip, apparently trying to make it difficult to read their own and create their own images.
It was this miracle, nicknamed by the people cra p fs, that I saw:
$ sudo mount -t cramfs Image/boot.img /media/cramfs
mount: wrong fs type, bad option, bad superblock on /dev/loop0
$ dmesg |tail
[41549.071136] cramfs: wrong magic
When trying to connect with the same RK29kitchen, the result is about the same:
/sbin/e2fsck: Bad magic number in super-block while trying to open system.img
You need to trim the first 8 bytes from the img file:
$ dd if=boot.img of=bootimg.gz skip=8 bs=8 count=20000000
524280+0 records in
524280+0 records out
4194296 bytes (4.2 MB) copied, 4.41275 s, 950 kB/s
Excellent. I came across the very case when the files are packed with gzip, and then an absurd header and footer are added to them, in which there is a CRC and, probably, something else.
Further - more interesting:
$ mkdir myboot
$ cd myboot
$ gunzip < ../bootimg.gz | sudo cpio -i --make-directories
$ ls
data dev init_battery.sh init.rc proc sbin system ueventd.rc
default.prop init init.goldfish.rc init.rk29board.rc rk29xxnand_ko.ko sys ueventd.goldfish.rc ueventd.rk29board.rc
There are a bunch of files inside, it’s not very clear whether they are needed or not. To collect this business in the reverse order you need to be even more accurate, you need to reset the dates on the files:
For assembly of images cpio is traditionally used. Compared to the more popular tar, cpio has a number of advantages that I do not want to delve into in this topic.
And now, I have on hand a customboot.img assembled by myself, which can be poured back into the device.
With kernel.img, such a preparation does not work.
And here is what happened with system.img:
$ sudo mount -t cramfs system.img /media/cramfs
$ ls /media/cramfs/
app bin build.prop etc fonts framework lib media tts usr xbin
Android app files (executable file archive) were found in the app folder. That is, you can add some new programs there or delete those that are, including some annoying and boring. You can add su and busybox to bin, which, as I understand it, is enough to root the device. In etc, change the configuration. Etc. In theory. In practice, you’ll have to tinker a bit with the fact that nothing can be written to the mounted cramfs image just like that.
Well, I managed to dissect something.
New look
Of course, it would be great to try to boot from the SD card by loading an image carefully prepared by someone, but RK29 does not have such an opportunity, so you have to create an image and flash it directly into the device’s flash memory. I hope that there is a backup.
The images prepared in the previous paragraph were all in different formats, namely:
boot.img was in cra p fs format , and the rest, which were already loaded after it, were in more digestible ones. Hence, I will assume that dancing with a tambourine is coming only with this boot.img, and with the rest of the images everything will be more or less ordinary.
I’ll refresh my memory, write what sections are needed to install Linux.
/ Root section. Contains an important / boot folder containing a kernel image. / boot can also be made a separate partition, on the other, non-journaling, file system (since it is used only when loading and updating the kernel). But for simplicity, you can keep it in the root partition. Another important folder, / home, contains user data, and it’s nice to have a separate partition for it. Swap is needed for virtual memory for devices with less than 1GB of memory, however, using the built-in flash memory with a limited read / write cycle for this is at least unwise, it is better to pick up an external SD card for these purposes. / usr stores files common to all users. / var, stores logs, and it would also be more logical to store them on an external SD card.
So, in order to work less, I’ll make an image consisting of three partitions:
/ boot, 16 MB with the cra p fs
/ file system , ~ 4 GB
we won’t create the remaining space for the root / home file system , so far we will stay under root, and how it will turn out to mount an external SD card, so we
mount it / swap too, I will mount it on an external flash card
I downloaded and unpacked the latest open source kernel, which was developed under Rockchip 2918, from odys.de. The kernel version 2.6 was saddened. Archlinux ARM core cross-compilation instructions made you feel like a dumbass, and upset the list of supported devices. Yoctoproject is a little confused. The abundance of Linaro assemblies and, again, a limited list of supported devices, as well as a considerable number of bugs even on supported devices, were confusing. Already started to glance towards LFS . Isn’t there really something universal that a half-dollar would start up on more or less standard equipment based on the Cortex A8 / A9? Uffff.
I was left with no choice, I have to cross-compile the kernel from the source and collect the images myself. I downloaded the linux-linaro-3.5-rc3-2012.06.tar.bz2 kernel source codes and the gcc-linaro-arm-linux-gnueabihf-2012.06-20120625_linux.tar.bz2 cross-compilation toolkit. The only annoyance is that compilation requires a device-specific .config file, which Linaro does not have for RK2918. Fortunately, the odys kernel mentioned earlier has Rockchip-specific files, and they were also found in the newer sources from easypix.eu. I copied them to the source from Linaro, namely:
- folder arch / arm / mach-rk29
- 50-kilobyte arch / arm / configs / rk29_ddr3sdk_defconfig with a huge number of device-specific options
- the last line from arch / arm / tools / mach-types
- section ARCH_RK29 from arch / arm / Kconfig
- mkkrnlimg from the source root
Cross-compiling the kernel
3.5.0-rc3 by Linaro
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- rk29_ddr3sdk_defconfig
$ PATH=$PATH:~/linaro/gcc-linaro-arm-linux-gnueabihf-2012.06-20120625_linux/bin
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- uImage
...
kernel/cgroup.c:470:2: error: 'saved_link' undeclared (first use in this function)
...
make: *** [kernel] Error 2
Pretty sweet, but fixable. It turns out that someone carefully erased two lines and a comment. I remember, this is called memory utilization optimization and refactoring, but this time it doesn’t suit me, and I have to return it to its place:
It worked. Interestingly, stable assemblies from Linaro generally try to collect, how do compilation errors get into it?
Another mistake:
fs/yaffs2/yaffs_vfs.c:46:28: fatal error: linux/smp_lock.h: No such file or directory
The file was found in the sources from odys, but another error occurred, and with a dozen others:
fs/yaffs2/yaffs_vfs.c:317:3: error: assignment of read-only member ‘i_nlink’
...
fs/yaffs2/yaffs_vfs.c:1995:9: error: ?struct mtd_info? has no member named ?sync?
fs/yaffs2/yaffs_vfs.c:1996:6: error: ?struct mtd_info? has no member named ?sync?
fs/yaffs2/yaffs_vfs.c:2097:2: error: ?struct mtd_info? has no member named ?erase
...
Exclude yaffs2 from assembly? Edit C code in which I don't understand anything? I managed the first mistake, then I found a patch that didn’t help a bit, and I had to fix it at random, focusing on inode.c. There were errors with struct mtd, and I must say that in the kernel version from Android 3.4, everything is the same , and I got the feeling that there is no place to wait for hope. The feeling came that the day of the early morning is wiser. But the desire to remove all the lines associated with YAFFS from .config and continue was stronger. Then you can use UBIFS, or in extreme cases even ext3, not intended for flash media.
The award was quick:
Image Name: Linux-3.5.0-rc3
Created: Tue Jul 3 05:35:58 2012
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2258064 Bytes = 2205.14 kB = 2.15 MB
Load Address: fffffff2
Entry Point: fffffff2
echo ' Image arch/arm/boot/uImage is ready'
Image arch/arm/boot/uImage is ready
Move on:
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- modules
...
CC drivers/media/video/gspca/gspca_main.mod.o
LD [M] drivers/media/video/gspca/gspca_main.ko
CC drivers/scsi/scsi_wait_scan.mod.o
LD [M] drivers/scsi/scsi_wait_scan.ko
Everything went well, and it was only alarming that nothing specific RK29 was compiled, and this is very suspicious. uImage received.
3.0.8+ from easypix.eu
Just in case, I decided to try to collect the sources from easypix.eu. Here it is clearly visible that the source code of RK29 is compiled. There are no YAFFS in .config, nor are UBIFS. There is only read-only cramfs that is suitable for / boot, but not at all suitable for the root partition. The assembly falls on:
CC drivers/net/wireless/bcm4329/wl_iw.o
drivers/net/wireless/bcm4329/wl_iw.c: In function ‘wl_iw_set_pmksa’:
drivers/net/wireless/bcm4329/wl_iw.c:5069:5: error: array subscript is above array bounds [-Werror=array-bounds]
Corrected .config, removed the BCM4329 WiFi module from there and added all possible file systems for flash memory. I did not understand whether the RTL8192 driver would compile, well, okay. I continue and come to success:
OBJCOPY arch/arm/boot/Image
Kernel: arch/arm/boot/Image is ready
UIMAGE arch/arm/boot/uImage
Image Name: Linux-3.0.8+
Created: Thu Jul 5 13:29:41 2012
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 7028772 Bytes = 6864.04 kB = 6.70 MB
Load Address: 60408000
Entry Point: 60408000
Image: arch/arm/boot/uImage is ready
Monster
Dr. Frankenstein challenges nature and will cross the last core with the remains that the easypix threw at us.
It is very tempting to create an HWpack for Linaro, but there is no experience in this matter, there is no desire to support alone either. So we take the last core from Linaro git and I will gradually roll on it what is needed for the normal operation of RK29.
So now I have .config and Kconfig from easypix.eu. I realized that the last time I forgot to add the line to arch / arm / Kconfig:
source "arch/arm/mach-rk29/Kconfig"
and in the Makefile:
machine-$(CONFIG_ARCH_RK29) := rk29
После запуска:
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- rk29_ddr3sdk_defconfig
But that is not all. Searching for 'rk29' by source gave 10,707 matches in 358 files to be slowed down, among them audio drivers, codecs, Makefiles, Kconfigs scattered evenly throughout the project.
I will leave it behind the scenes of this topic. As soon as possible, be sure to update the topic and lay out the sources and results. If you want to join my impulse - write.
Distribution
As you know, you will not be full of a single kernel , and it is supposed to submit GNU to it. It describes what and why you need to turn the kernel into a full-fledged operating system.
Ideally, I want Arch Linux, and as it is written on their website, you can take the distribution kit for any other device and just add your own kernel. I already have a kernel, so it remains to unpack the downloaded ArchLinuxARM-am33x-latest.tar.gz, remove / boot from it, marveling at how large the independently-obtained kernel (almost 7MB) is compared to the BeagleBone kernel (2.7MB). The root folder, from which I am going to make an image of the root partition, takes about 421MB, 10% of which are completely unnecessary in my situation kernel sources (linux-3.2.18-1).
Assembly and priming
Training
So, I have two folders, boot and root, from which I need to make two images, the first in cra p fs, and the second in some file system familiar to the kernel and, preferably, intended for flash memory. The choice of the file system for the root partition is extensive, since the kernel from easypix.eu has been assembled with support for JFFS2, UBIFS, EXT [2 | 3 | 4], VFAT and MSDOS. On the network, they praise YAFFS2, it is slightly faster than UBIFS and uses slightly less RAM, but the assembly again threw errors when trying to connect it to .config, so let it be UBIFS.
In addition to collecting images, you need to create a new partition table and an entry point into the kernel, namely the parameter file, which occupies 256KB of memory at the beginning of flash memory, which I cited at the beginning of the topic.
KERNEL_IMG, coincides with what the kernel issued at the end of the assembly, so there is no need to change it. CHECK_MASK is the same for all the images I have seen, I also don’t touch it. The remaining lines are also, except for CMDLINE, which contains MTD partition tables and loading arguments.
The U-Boot website says that the MTD partition table can be set in a simplified form, but I won’t take any risks and will be as close to the original as possible.
So, the memory in the device is distributed as follows:
256KB to the parameters file
16MB on / boot (in case you suddenly want to reload the kernel exclusively, but it will grow 8MB) the
rest on /
It seems that in the Linux kernel, starting with 3.0, the consoles began to be called differently, tty01, etc., but I will leave it as it is.
androidboot.console and init we do not need. Initrd (a disk in memory which is used for assembly and dynamic loading of modules) I decided not to do, perhaps in vain. It is necessary to establish the location of the root partition by poking it in the desired mtd partition (numbered starting at 0). You also need to specify the type of file system for the root partition.
$ mkkrnlimg -a parameter parameter.img
F535BA01
$ ls -l
316 Jul 5 22:56 parameter
328 Jul 10 20:27 parameter.img
It is confusing that the original parm.img, extracted from the device, has a size of 256KB, and the content there is already in five different places. And here only at the beginning of the file. Most likely, the Chinese insured themselves in case the U-Boot would try to load this data at a different offset in memory, and filled it with an additional offset of + 16KB, + 32KB, + 48KB and + 64KB. It is possible that the remaining 3.75MB, which, judging by the partition table, are not busy with anything, also contains the same piece.
They differ by only 12 bytes, 8 of which are added to the beginning. Alas, a comparison with the original parm.img showed that mkkrnlimg adds
KRNL<
and 0x01, and in parm.img it was
PARMG
and 0x02.
The hexadecimal editor from mc helps, and I tweak the title to be like in the original.
Core
$ mkkrnlimg -a uImage kernel.img
7DDF79C6
$ ls -l
7139328 Jul 5 22:49 uImage
7139340 Jul 10 20:42 kernel.img
Различаются всего на 12 байт, 8 добавлено в начало, и подозреваю, что 4 в конец. Такого, как было с boot.img (заголовок на 8КБ, запаковка gzip'ом и cpio) нет в помине.
Корневой в UBIFS
Немного теории специально для тех, кто не понял ЧаВо (включая меня), тут.
Выясняется, что неплохо бы знать размер erase блока и размер страницы для используемой NAND флеш памяти. На плате устройства обнаружен чип с маркировкой Samsung 201 K9GBG08U0A SCB0, по найденной спецификации 4ГБ, размер erase блока значится 128КБ+4КБ, а размер страницы 2КБ.
Из полученного выбираю параметры для создания образа UBIFS и из него образа UBI и состав ubinize.cfg:
[ubifs]
mode=ubi
image=ubifs.img
vol_id=0
vol_size=4000MiB
vol_type=dynamic
vol_name=rootfs
vol_flags=autoresize
UBIFS supports data compression, and I limited the size of the 4GB volume with the same size of physical media, I'm not sure if this is the right solution.
Firmware
It is a little confusing that it is advisable to use a special algorithm for recording UBI images .
The parameters for the starting position and size for rkflashtool are set in 512-byte blocks.
I write the image of the parameter.img partition table at five different offsets, as in the Chinese. The rest is according to the partition table.
$ rkflashtool29 w 0 1 < parameter.img
$ rkflashtool29 w 0x00000020 1 < parameter.img
$ rkflashtool29 w 0x00000040 1 < parameter.img
$ rkflashtool29 w 0x00000060 1 < parameter.img
$ rkflashtool29 w 0x00000080 1 < parameter.img
$ rkflashtool29 w 0x00002000 0x00008000 < kernel.img
$ rkflashtool29 w 0x0000a000 0x0006d600 < ubi.img
В принципе пишется быстро, судя по последнему куску размером почти 4ГБ у меня получилось меньше минуты, но вот при запуске каждый раз происходит инициацилизация, занимающая 50 секунд. В любом случае процедура не заняла и десяти минут.
На всякий случай штатным образом перегружу устройство:
$ rkflashtool29 b
Trial and error method
First start
The first launch was not that it was not successful, but frankly, I’ll say it was a failure. The device did not turn on the diode, did not respond to button presses, and did not output anything via HDMI. It is very successful that I did a backup. It is very fortunate that the device is still able to receive data. Restore to its original state:
rkflashtool29 w 0 0x00082000 < backup.img
The device continues to fail.
I run ./menu.sh from RK29kitchen, change the size of the / system partition in the backup and flash it. The device turns on and shows the line “Loading ...”, but does not go further. Already not bad. I restore the original backup, after the second reboot Android still loads in its original form.
What did I do so and what was wrong
After digging into the source code of RK29kitchen and at the forum where rkflashtool was announced , it turned out that I was not in vain attributing this image to five different offsets, and that it was necessary (90.flash.sh).
The parameter.img file contains “PARM” in the first four bytes, and the next two, which I mistakenly copied from the original parm.img, are the length of the parameter file, 583 bytes. This explains why nothing was loaded (the MTD partition table was not determined and U-Boot could not load the kernel), but it did not explain why the light did not light. Instead of tidying up with a hex editor, the rkcrc utility was discovered, which makes an image with the correct headers and a total size of 16KB from the parameter file when it is run with the -p option. The "-k" option is for creating images labeled "KRNL".
Rummaged in original backup.img. It is not clear whether it was worth changing the partition table so radically, the file clearly reads that the sizes, offsets and order (sections should be in the order of the offset) of the partitions can be changed, and you can also create new partitions, but the names of the partitions cannot be changed. Who exactly sets this restriction is not clear, but most likely the bootloader (U-Boot?).
It was also found there that RK29xxLoader (L) _V2.08.bin is used (a bit later version 2.04 binary obviously goes), while versions 2.12, 2.14 and 2.18 were also found in the RK29kitchen bootloader list, but in Nextbook used 2.20. How to update the bootloader located on the NOR flash memory (which is only 1MB or so) and whether it is worth doing is not clear. In addition to the loader, there is also a package-file, which contains a lot of interesting information.
Attempt number two, panic and despondency
I repeat the entire firmware procedure, but now with the correct parameter.img. Does not work. Restoring back.
At some point, foolishly, instead of using RK29kitchen, I wrote backup.img directly at offset 0. Then I restored the backup, removed the dump again and erased the extra backups. Updating the firmware from the backup at some point did not work. There was a panic from the fact that it seemed to me that I had wiped the very original backup with the correct backup.img. I wrote a script to restore from individual images, but it did not help either. At least the light comes on when the device is turned on. But there is no signal on HDMI.
I thought about extundelete, but realizing that chroot and umount would be required, I refused this thought in fear of screwing up the system not only on an inexpensive Chinese device.
I was flashing all possible firmware, from gbox (a slightly different device with only three USB ports), from the author of the firmware method, found here . Nothing helped. Anyway, a brick, sometimes with an LED when turned on, and sometimes without it at all. It was early morning, and once again I decided that the evening of the early morning was wiser.
And how I was right. By connecting the device to the monitor, it turned out that everything was working.
Conclusions and Surveys
This experience, although not very pleasant, led me to the following conclusions and findings on the network:
- the device needs time to reformat partitions after the firmware
- some firmware has a bootloader, sometimes 2.08, sometimes 2.14. Where to flash it is not clear. The author of RK29kitchen could not get an answer to this question
- the mysterious package-file is probably located in the mysterious space between the parameters and the kernel, and it is also possible that there is also a bootloader and no less mysterious HWDEF that describes the device parameters
The first thing I did was a complete dump of all 4GB of flash memory.
I try to fill the kernel from the backup by unpacking it and repacking it. If it doesn’t work, then something is not right.
Unpack, pack and flash:
mkkrnlimg -r kernel.img kernelimg
mkkrnlimg -a kernelimg kernel2.img
rkflashtool29 w 0x00004000 0x00004000 < kernel2.img
Overload - it works. The same trick with self-obtained uImage fails.
Even when unpacking the original kernel.img using RK29kitchen, it was found that the signature inside the image is different from the standard one according to the U-Boot version 27 05 19 56. All different kernel images from different firmware have the same header:
D3 F0 21 E3 10 9F 10 EE xx xx 00 EB 05 A0 B0 E1 xx xx 00 0A
The first thought - in the image went XOR'om. I’m checking, but, unfortunately, 8 and 16 bit are not suitable, and 32 bit in the fourth quartet produces too large a number to be the size of the image, and there are too many in the third quartet, which should have time matches between different images.
A search query for “D3 F0 21 E3” shows extremely few results, and even less interesting ones among them. Here in this thread of the Italian forum it is stated that the Odys sources do not create the correct image, unlike these kernel sources from Anypad.
And it is possible that the problem is in my use of mkkrnlimg from RK29kitchen, because the sources from Odys and easypix are attached (by the way, the same) mrkrnlimg, which is very different in size and can only convert in one direction. No, the images created by all three utilities are no different.
I collect the core from Anypad. It's 2.6, but it's interesting to see what the uImage will have. I got rid of the same error with the bcm4329 module.
I accidentally noticed that in my .config file I turned on the output to some kind of LCD panel, and the DEFAULT_OUT_HDMI option was turned off. This is a huge puncture. I would not be surprised if Linux booted, but did not show anything via HDMI, and I would never have known that it booted. A problem related to this DEFAULT_OUT_HDMI was found in rk29_fb.c, the hdmi_get_default_resolution function was not found, and it is not in the source from easypix either. I had to write it by touch, putting down more than a dozen parameters. In the structure that this function fills, there is a funny parameter for swapping the RGB color channels.
The image has gathered, but in it are the same ill-fated standard "27 05". And then I looked around, and in the same directory I noticed the Image image, and it contains the long-awaited title “D3 F0”. I looked at the results of the easypix kernel assembly - and there is one too. A pleasant surprise.
One cannot ignore such an interesting thing as zImage, a self-extracting archive with a kernel image. For the sake of interest, I collected zImage and the size difference is impressive. For the partition with the kernel, 8MB, with a large margin, would obviously be enough. By the way, it is almost twice as different from the so-called “zImage” (which is actually just Image), extracted from the device’s kernel image (5.8MB).
Well, now all you have to do is add headers and flash into the resulting image. I want to note that rkcrc -k and mkkrnlimg -a give the same result.
I asked for it, turned it on - the diode is off. Something does not come out with the kernel. He corrected the header bytes that diverged from the original (which was before CRC, of course), added the headers, requested it, and it did not work. He returned the old core to its place.
The thought crept in to look in the / kpanic section, it was not in vain that it was allocated. I downloaded it, but alas, there is only something related to the panic of the regular kernel 2.6.32.27.
I despaired of flashing my kernel.
Attempt number 4
Well, since the kernel could not be flashed, it may be possible to flash everything else, leaving only the kernel. As far as taking the raid did not work, I will do small steps.
A small digression into the theory. How does Android generally load on the device?
1. When you turn on NOR memory (directly, since it supports execute-in-place), the boot loader, U-Boot, starts.
2. U-Boot loads the MTD partition table and loads the Linux kernel from the image into memory.
3. Linux initializes device drivers, mounts partitions, etc., and then runs init from /.
4. init ...
it’s no longer interesting, because it’s Android’s init, and instead of it I want to write my own, from Arch Linux.
init is at the root, and in the Arch Linux distribution, it is at / sbin. There is nothing left to do but copy it to the root.
In the original Android, the init file is not in the system section, but in boot. That is, it is this boot partition that is mounted in the root, and the system is mounted in / system. I’ll leave it that way.
In the original boot section is rk29xxnand_ko.ko, a module obviously designed to work with NAND flash memory. The rest of the modules are in /lib/modules/3.2.18-1/kernel, and links to them are registered in /lib/modules/3.2.18-1/modules.order. I pack the enclosed ko with gzip, put the other modules related to nand in kernel / drivers / mtd / nand, put root.root on it, and write it in modules.order and modules.dep. It is unlikely that this will help the kernel find the right module, but I couldn’t get depmod to dig into ELFs of a different architecture and find dependencies.
The original kernel does not know anything about UBIFS, so the previously created image will have to be left aside, and I will collect using cpio, gzip and mkkrnlimg:
Alas, the boot section is a bit small, and you have to slightly tweak the parameters, expanding it and moving the remaining sections, for ease of editing, I will expand it to 512MB (0x00100000):
By the way, it is customary to erase the first 256KB from cache, kpanic, and userdata partitions, and do not touch the user partition at all, as I learned from the RK29kitchen sources, but the sections following the system do not bother me much. The misc and kernel sections are not changing. I upload Arch Linux to the boot, I grind the rest.
$ rkflashtool29 w 0 1 < parmnew.img
$ rkflashtool29 w 0x00000020 1 < parmnew.img
$ rkflashtool29 w 0x00000040 1 < parmnew.img
$ rkflashtool29 w 0x00000060 1 < parmnew.img
$ rkflashtool29 w 0x00000080 1 < parmnew.img
$ rkflashtool29 w 0x00008000 0x00082000 < boot.img
$ rkflashtool29 e 0x0008a000 0x006f6000
$ rkflashtool29 b
I was almost annoyingly mistaken in the size of boot.img and a further offset for erasing. I wonder how many similar errors I have already made? Maybe a non-native kernel would start normally?
After a reboot, 10 seconds pass, then the LED lights up. And lo! A penguin appeared in the upper left corner of the screen, hung for about ten minutes, and then a dark blue background remained, and nothing else happened. On subsequent downloads, the penguin appears almost instantly. A connected keyboard has no effect. The kpanic is pure (nothing but 00 and FF).
Conclusion
You need to be a good level specialist in order to cope with such a device without documentation and sources, and this specialist is clearly not me. Or the device is absolutely not what you need.
I really wanted to lay out the images that I got, upload screenshots and a short video with some new 3D game, but not fate. Agree, bad experience is also experience.
References
I present an abbreviated list of the interesting things that I read that for some reason did not fall into the links to the topic itself.
July 14, 2012 at 05:05
