GNU / Linux and the device on Rockchip 2918
First, a little background. A small continuation of the story with the media player GV2B, which I described earlier that / m . Let me remind you that initially the box was not bought as an Android set-top box, but as a more powerful replacement for the Raspberry Pi, for which I left a request in April, but that will arrive only in August. And GV2B was in my hands 8 days after ordering, for only $ 100 and with a full set of cables (which is only $ 5 more expensive than a Raspberry Pi set with charging, cords and a case).
The reassurance of the spiteful critics from my previous post, that Youtube and other applications installed from Play, earned great, and the device found no more flaws.
Most recently, a couple of topics appeared, which described how Puppy Linux, Arch Linux and Ubuntu were installed on an ARM device. This is a unique feature of Allwinner A10, which is hard to underestimate, but still the system is physically run from an SD card, rather than a 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 flash memory of the device, which is encouraging and possibly opens a loophole for uploading full-fledged GNU / Linux. It is presumptuous to note that this is already the next step for the banal launch of a slightly doped image from an SD card.
- Install the Linux kernel on the device. Preferably the newest. Or the newest of those that contains all the drivers specific to the device;
- Put GNU;
- Set the desktop environment;
- Make a backup so that the device can be returned to its original state, if something goes wrong;
- Good fun with a difficult task (comparable to installing the first versions of USB downloaders on the Wii and passing NetHack or Dwarf Fortress).
')
GV-2B device from an unknown Chinese manufacturer , based on Rockchip 2918 (abbreviated RK29) (CPU ARM Cortex A8 1GHz + Vivante GC800 600MHz GPU), with 4GB of flash memory, 512MB of RAM and a fair amount of connectors.
16GB SD card class 10.
PC with Arch Linux.
Keyboard.
Monitor.
HDMI-DVI cable for connecting a monitor.
A bunch of USB cords, adapters and so forth.
Surely many of the readers would have done what is described in the topic, or at least some particular part, faster and better, but I did not find any mention of such a feat in the network. The topic contains a lot of practice and quite a bit of theory, only the most necessary to understand what is being said 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, pulls on a three-hour laboratory work. I also want to say that I am doing all this for the first time, if we exclude the connection of a disk with Ubuntu pre-installed on a desktop computer to a PC104 x86-compatible single-board.
In the model number G, there are about twenty different devices, on different processors, with different numbers of connectors, but about the same functionality.
At first, I was killed about not taking the device on the Allwinner A10, but after reading a few reviews about the openness of the kernel sources to it, I realized that the situation with Rockchip is not much worse.
There was an option to order a device of the same model range, but already with the Cortex A9, namely AmLogic 8726-M, but it does not have any significant advantages over the Rockchip 2918, and with the initial code for the latest chips, judging by the AmLogic website , everything also sadly
So, three ways were found to update the firmware of the device (the contents of that 4GB flash memory).
The first - from the manufacturer using one of the OEM models of the GV line, did not work, and it’s good, because their firmware is meant for a slightly different device, to which there are three USB ports, and the difference between them is so serious that the firmware usually turns into device conversion in brick
Two left. The second, from the hacker with AndroidForums , is that you need to make an additional, second reset button inside the box, while holding it to hold the power button for a few seconds. This method has opened 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
To my great regret, the keyboard, being connected to the device, and working perfectly well after loading Android, had no effect on the system recovery menu, and of the three buttons on the board (power, reset, reset), only one acted on the menu - the first reset, which either led him to the selection of the default active item Reboot system now, or else it just worked for its intended purpose. The rest of the cursor buttons, unfortunately, did not move. The way was precisely to fill the firmware from the SD memory card, which did not work.
Having formatted the SD card in fat32, I uploaded to it with difficulty downloaded from the file dump (god, have they not heard of Dropbox?) The downloaded update for Android. With a normal boot, Android cursed that there was an incorrect update.img on the SD card. But I still didn’t hurry to upload it, because backups are made not only by cowards, and it often happened on the forums that uploading one or another update.img, which I earned from one author, on a similar device led to a transformation into a brick from another author.
The thirdson of the way was closer to what I was going to do. It consisted in connecting the device to a computer using a USB cable.
At first, I was very embarrassed by the fact that in the system recovery mode the device was not detected from the computer at all, despite the fact that I connected all the necessary wires where necessary (and not even where I sent the opposite power of 4.57V and 5.08V via USB, which fortunately It did not have any consequences). As it turned out later, this is the way it should be, because they have their own protocol there, and the difference with the connection of external media is significant.
Under Windows, the Rockchip Flasher tool program was discovered, which the language doesn’t turn out to be called wonderful, because it’s done terribly and the only thing that it can do is flash new update.img. But I had to not only flash, but also download the existing one, in case something suddenly happened, so I had to give up the work of Chinese programmers.
With the legs, by the way, you need to be careful.
I want to save everything that is stored in flash memory to be able to restore everything to the original version, if that goes wrong. For this there are several different methods.
Titanium Backup . Android application with which you can take a snapshot of system partitions and copy it to an SD card. Everything is good, but the device needs to be ruled for this (get administrative privatization). In order to root the device on Android 2.3.1, Universal Androot is no longer suitable, and its author offers the choice to use Unrevoked , which is only suitable for HTC phones, or SuperOneClick , which seems to be all good, but in order to root the device It requires connecting it to a Windows computer. Everything is good, but it downloads the firmware, adds some files there and uploads it back. Change the firmware in order to make a backup copy of it - this is insanity.
It remained to take advantage of the Android Debug Bridge from the Android SDK, which is not a fact that would work with this particular device, and pulling a considerable amount of dependencies, which I did not want at all. Everything else to collect all this was necessary from the source (read AUR for Arch Linux).
Having already become sad, I suddenly discovered the wonderful utility RK29kitchen , announced here, which, judging by the description, absorbed a number of other equally remarkable utilities from the authors, which disassembled the clever protocol of communication of devices via USB, and a little less cunning file with the partition table.
It turned out not so easy. It turns out that the device should not be in system recovery mode, but in the off state, but always with the power connected. The problem is that it tries to turn on as soon as it feels that it is connected via USB. But you can cope with this. Holding both reset buttons for 5 seconds, let go first, then after 3 seconds, and the internal one. I start and try to be patient.
A little confused by the fact that the source flashdump'a says:
And in the output:
It is not entirely clear from which offset parm.img is read.
So, 5-10 minutes and thegolden key I have a flash memory image entirely and separately of all sections:
What happened? If you dig in the forums and source files of RK29kitchen, it becomes clear that I just read the contents of the flash memory of the device, starting with the partition table, which we have been disassembled on the shelves and recorded in the parameter text file, and using it, we recorded it separately.
It was here that an incredible amount of information was found that relates specifically to updating the flash memory of devices on the RK2918. All described devices are tablets, and connecting them to a computer for updating is somewhat easier (given the built-in microUSB port, also known as USB OTG).
This is how the parameter file looks like:
The last line using the hexadecimal system contains the lengths, the beginning of the sections, and in brackets their names. A required section is missing in which the partition table itself is actually stored. I'll try to decipher.
The size of the parameter block read is 0x200 (from the source files RK29kitchen), this 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 occupies the memory between 0x200 and 0x2000, and this is as much as 3.75MB is a mystery.
Now I have in my hands a set of img files, disk images that I downloaded. I wonder what's inside. I know from earlier knowledge that they make cramfs in flash format for writing files that are not meant to change (such as the OS kernel), but some particularly tricky Chinese manage to add more headers and footers to these images, then use gzip, apparently trying to make it difficult to read his own and create his own images.
It was this miracle, called cra p fs, that I saw:
When trying to connect with the same RK29kitchen, the result is about the same:
It is necessary to trim the first 8 bytes from the img file:
Fine. I came across the same case, when files are packed with gzip, and then the ridiculous header and basement are added to them, in which there is a CRC and, probably, something else.
Further more interesting:
There are a bunch of files inside, it’s not too clear, necessary or not. To collect this case in the reverse order, you need to be even more careful, 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 don’t want to delve into in this topic.
And here, in my hands is a customboot.img assembled with my own hands, which can be poured back into the device.
With kernel.img, this preparation does not work.
But what happened with system.img:
The Android app files were found in the app folder (the archive of the executable file). That is, you can add there any new programs or delete those that are, including some annoying and annoying. In bin, you can add su and busybox, which as I understand it, is enough to root the device. In etc change the configuration. And so on. In theory. In practice, you have to tinker a little with the fact that in the mounted image of cramfs you just can’t write anything down.
Well, it was possible to dissect something.
It would be great, of course, to try booting from the SD card by uploading an image carefully prepared by someone, but the RK29 doesn’t have such a possibility, so you have to create an image and flash it directly into the flash memory of the device. I hope that there is a backup.
The images prepared in the previous paragraph were all in different formats, namely:
boot.img was in the cra p fs format, and the rest, which are already loaded after it, are more digestible. From here I will assume that dances with a tambourine are coming only with this boot.img, and with the rest of the images everything will be more or less trivial.
I will refresh the memory, I will write what sections are needed to install Linux.
/ Root section. It contains an important / boot folder containing a kernel image. / boot can be made a separate partition, on the other, not journaling, file system (as it is used only when booting and updating the kernel). But for simplicity, you can keep it in the root section. Another important folder, / home, contains user data, and it's nice to allocate a separate section for it. Swap, is needed for virtual memory for devices with less than 1GB of memory, but it is at least unwise to use the built-in flash memory with a limited read-write cycle for this, it’s better to pick up an external SD card for this purpose. / 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 will make an image consisting of three sections:
/ boot, 16MB with file system cra p fs
/, ~ 4GB remaining space for root file system
We will not create a / home, we will live as long as root, and how we will mount an external SD card, so we will also mount it
/ swap will also be mounted on the external flash card
I downloaded and unpacked the latest open source kernel, which is sharpened for Rockchip 2918, from odys.de. Kernel version 2.6 saddened. Archlinux ARM kernel cross-compilation instructions made you feel like a dumbass, and upset the list of supported devices. Yoctoproject is slightly 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, confused. Already started glancing towards LFS . Is there really no universal thing that would have run out of poltychka on more or less standard equipment based on the Cortex A8 / A9? Uffff.
I haven’t left a choice, I’ll have to cross-compile the kernel from the sources and build the images myself. I downloaded the linux-linaro-3.5-rc3-2012.06.tar.bz2 source code and the cross-compilation toolkit gcc-linaro-arm-linux-gnueabihf-2012.06-20120625_linux.tar.bz2. The only shame is that a device-specific .config file is needed for compilation, which Linaro does not have for RK2918. Fortunately, in the previously mentioned odys kernel there are Rockchip-specific files, and they were also found in the newer source code from easypix.eu. I copied them to the source from Linaro, namely:
- folder arch / arm / mach-rk29
- 50KB arch / arm / configs / rk29_ddr3sdk_defconfig with a huge number of device-specific options
- last line from arch / arm / tools / mach-types
- section ARCH_RK29 from arch / arm / Kconfig
- mkkrnlimg from the source root
Pretty cute, but fixable. It turns out that someone carefully erased two lines and a comment. I remember, this is called memory optimization and refactoring, but this time it does not suit me, and I will have to return it to the place:
It worked. Interestingly, stable builds from Linaro generally try to compile, how do compile errors get through?
Another mistake:
The file was found in the source code from odys, but another error occurred, as well as a dozen others:
Exclude yaffs2 from the build? Edit C code in which I do not understand anything? I coped with the first error, then I found a patch that did not help a bit, and I had to fix it at random, focusing on inode.c. There were errors with the struct mtd, and I must say that in the kernel version from Android 3.4, everything is the same , and it has come that there’s no hope of waiting. It has come that day of early morning is wiser. But the desire to remove all the lines related to 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 fast:
Go ahead:
Everything went well, and only alerted that nothing specific was compiled RK29, and it is very suspicious. uImage is received.
In any spare case I decided to try to collect the source code from easypix.eu. Here you can clearly see that the source code for RK29 is compiled. There is no YAFFS in .config, nor is UBIFS. There are only read-only cramfs, which is suitable for / boot, but not at all suitable for the root partition. Build falls on:
Fixed .config, removed the BCM4329 WiFi module from there and added all possible file systems for flash memory. I did not understand whether the driver RTL8192 would be compiled, but that’s ok. I continue and come to success:
Dr. Frankenstein challenges nature and will cross the last nucleus with the remains that the easypix threw us.
It is tempting to create a HWpack for Linaro, but there is no experience in this matter, the desire to support alone - too. So we take the latest kernel from Linaro git and will gradually roll on it what is needed for normal operation of the RK29.
So, now .config and Kconfig from easypix.eu. I realized that last time I forgot to add a line to arch / arm / Kconfig:
and in the Makefile:
added the following to .config:
But that's not all. Searching for 'rk29' in source code gave 10707 matches in 358 files to be played, among them audio drivers, codecs, Makefiles, Kconfigs, scattered evenly throughout the project.
I leave it behind the scenes of this topic. As soon as it works out, I will definitely update the topic and post the source code and the results. If you want to join my impulse - write.
As you know, you will not be fed up with the core , and GNU is supposed to submit to it. It describes what and why you need to turn the kernel into a full-fledged operating system.
Ideally, you want Arch Linux, and as it is written on their website, you can take the distribution for any other device and just add your 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 big the self-made kernel is (almost 7MB) compared to the kernel for BeagleBone (2.7MB). The root folder, from which I am going to make an image of the root partition, occupies about 421MB, 10% of which occupy the kernel sources that are completely unnecessary in my situation (linux-3.2.18-1).
So, I have two folders, boot and root, of 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 came together with support for both JFFS2, and UBIFS, and EXT [2 | 3 | 4], and VFAT and MSDOS. On the network, they praise YAFFS2, it is a little faster than UBIFS and uses slightly less RAM, but the build again gave 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 takes 256K of memory at the beginning of flash memory, which I quoted at the beginning of the topic.
KERNEL_IMG, coincides with what the kernel issued at the end of the build, so there is no need to change. CHECK_MASK is the same for all the images I have seen, I don’t touch either. The rest of the lines, too, except for CMDLINE, containing the table of MTD partitions and loading arguments.
The site U-Boot says that the MTD partition table can be set in a simplified form, but I will not risk it, and I will be as close to the original as possible.
So, the memory in the device is distributed as follows:
256KB per parameters file
16MB on / boot (in case you suddenly want to reload only the kernel, but it will outgrow 8MB)
residue on /
It looks like this:
Before:
It seems to be in the Linux kernel, starting with 3.0, the console began to be called differently, tty01, etc., but leave it as it is.
we will not need androidboot.console and init. I decided not to do the initrd (a disk in memory that is used to assemble and dynamically load modules), perhaps in vain. It is necessary to establish the location of the root partition by sticking to it in the desired mtd partition (numbering starting from 0). You also need to specify the file system type for the root partition.
The total is:
I launch mkkrnlimg from RK29kitchen:
It is embarrassing 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 then only at the beginning of the file. Most likely, the Chinese were insured in case U-Boot would try to load this data at another memory offset, 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 occupied with anything, also contain 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
The hex editor from mc helps, and I correct the title to be like the original.
UBIFS supports data compression, and I limited the size of a 4GB volume to a similar physical media size, not sure if this is the right solution.
It is a little embarrassing that it is desirable to use a special algorithm for recording UBI images.
The parameters of the initial position and size to rkflashtool are specified in blocks of 512 bytes in size.
The image of the parameter.img partition table is written in five different offsets, like in Chinese. The rest is according to the partition table.
The first launch was not that not successful, but I’ll just say that it’s a failure. The device did not turn on the diode, did not react to pressing the buttons, and did not issue anything via HDMI. Very well, that still made a backup. Very well, the device is still able to receive data. Restore to original state:
The device continues to not work.
I launch ./menu.sh from RK29kitchen, change the size of the / system partition in the backup and flash it. The device turns on, and shows the string "Loading ...", but does not go further. Already not bad. I restore the original backup, after the second reboot, Android is still loaded in its original form.
After digging into the source code of RK29kitchen and on the forum where rkflashtool was announced , it turned out that I was not in vain attributing this image to five different shifts, and that it was necessary (90.flash.sh).
The parameter.img file contains “PARM” in the first four bytes, and the next two that 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 defined and U-Boot could not load the kernel), but does not explain why the light did not light up. Instead of trying on a hex editor, the rkcrc utility was found, which makes an image from the parameter file with the correct headers and a total size of 16KB, launched with the "-p" option. The "-k" option is used to create images with the tag "KRNL".
Rummaged in the original backup.img. It is not clear whether it was worth changing the partition table so radically, it is clearly readable in the file that dimensions, offsets and order (sections should go in order of offset) can be changed, and new sections can be created, but the names of sections cannot be changed. Who exactly sets such a restriction is not clear, but most likely a bootloader (U-Boot?).
It was also found that RK29xxLoader (L) _V2.08.bin is used (the binary version 2.04 clearly goes a little further), while versions 2.12, 2.14 and 2.18 are also found in the list of bootloaders RK29kitchen, and in Nextbook, in general, 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 it is not clear. In addition to the bootloader, there is also a package-file, containing a lot of interesting information.
I repeat the whole procedure of the firmware, but now with the correct parameter.img. Does not work.Restoring back.
At some point, foolishly instead of taking advantage of RK29kitchen, I recorded backup.img right at offset 0. Then I restored the backup, once again took the dump and redundant backups of the wipers. 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 erased that initial backup, with the correct backup.img. I wrote a script to restore from individual images, but it did not help. At least the light when the device turns on. But for HDMI there is no signal.
I thought about extundelete, but realizing that it would require chroot and umount, I abandoned this idea in fear of bogging down the system not only on an inexpensive Chinese device.
I stitched all possible firmware, from gbox (a bit of another device with only three USB ports), from the author of the firmware method, found here . Nothing helped. Anyway, brick, sometimes with the LED when turned on, and sometimes completely without. It was early morning, and once again I decided that the evening of early morning was wiser.
And how I was right. Connecting the device to the monitor, it turned out that everything works.
This experience, although not very pleasant, led me to the following conclusions and discoveries on the network:
- the device needs time to reformat partitions after the firmware
- some firmware have 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 may be 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 describing the device parameters
From one of the firmware:
First of all, I made a complete dump of all 4GB of flash memory.
I try to fill the kernel from the backup, unpacking it and packing it again. If it does not work, it means that something is wrong.
I unpack, pack and flash:
Reboot - it works. The same trick with self-generated uImage does not work.
Even when unpacking using RK29kitchen of the original kernel.img, it was found that inside the image the signature differs from the standard version of U-Boot 27 05 19 56. All the various kernel images from different firmware have the same header:
The first thought - in the image walked XOR'om. I check, but, unfortunately, 8 and 16 bit do not fit, and 32 bit for the fourth quartet gives out too large a number to be the size of the image, and that in the third quartet, which should be time, too much matches between different images.
The search query for "D3 F0 21 E3" shows very few results, and among them even less interesting. Here in this thread of the Italian forum it is stated that the sources from Odys do not create the correct image, in contrast to these kernel sources from Anypad.
And it is possible that the problem is in using my mkkrnlimg from RK29kitchen, because the source from Odys and easypix comes with (by the way, the same) mrkrnlimg, which is very different in size and can convert only in one direction. No, the images created by all three utilities are no different.
I collect the core from Anypad. It is 2.6, but it is interesting to see what title the uImage will have. I got rid of the same error with the bcm4329 module.
I accidentally noticed that in my .config file the output to the LCD panel was turned on, and the DEFAULT_OUT_HDMI option was turned off. This is a huge puncture. I wouldn’t have been surprised if Linux had booted, but hadn’t shown anything via HDMI, and I wouldn’t have known that it had booted. A related DEFAULT_OUT_HDMI problem was found in rk29_fb.c, there was no hdmi_get_default_resolution function, and in the source files from easypix either. I had to write it by touch, putting down more than a dozen parameters. In the structure that this function fills in, there is an amusing parameter of swapping the RGB color channels.
The image was assembled, but in it the same ill-fated standard "27 05". And then I looked around, and in the same directory I noticed the image Image, and in it lies the long-awaited title "D3 F0". I looked at the results of assembling the easypix core - and there it is. A pleasant surprise.
You can not 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 difference in size is impressive. For the partition with the core, 8MB would obviously be enough, with a large margin. By the way, it is almost twice as different from the so-called “zImage” (which is actually just an Image) extracted from the image of the device core (5.8MB).
Well, now in the resulting image it remains only to add headers and flash. I want to note that rkcrc -k and mkkrnlimg -a give the same result.
I flashed it, turned it on - the diode is off. Something does not come out with the core. I corrected the header bytes diverging from the original (which, of course, before the CRC), added headers, flashed it — it doesn't work. He returned the old core to its place.
The thought crept in to look at the / kpanic section, for good reason it was highlighted. I downloaded, but alas, there is only something related to the panic of the regular kernel 2.6.32.27.
Desperate to flash your core.
Well, since the kernel could not be flashed, it may be possible to flash everything else, leaving only the kernel. Since it was not possible to take a raid, I will take small steps.
A small excursion into the theory. How is Android loading on the device?
1. When turned on from NOR memory (directly, since it supports execute-in-place), the bootloader, U-Boot, starts.
2. U-Boot loads the MTD partition table and loads the Linux kernel from the image into memory.
3. Linux initializes the device drivers, mounts partitions, etc., and then starts init from /.
4. init ... is
not interesting anymore, because this is Android's init, and just in its place I would like to write my own, from Arch Linux.
init is at the root, and in the Arch Linux distribution it is in / sbin. There is nothing else left but to copy it to the root.
In the original Android, the init file is not in the system section, but in the boot. That is, this particular boot partition is mounted to the root, and the system is mounted to / system. So leave.
In the original boot section is rk29xxnand_ko.ko, the module, obviously, designed to work with NAND flash memory. The remaining modules are located in /lib/modules/3.2.18-1/kernel, and links to them are written in /lib/modules/3.2.18-1/modules.order. Packed with gzip, the accompanying ko, I put it on the other modules related to nand in kernel / drivers / mtd / nand, put root.root rights on it, and write it in modules.order and modules.dep. It is unlikely that this will help the kernel find the required module, but it is not possible to force depmod to delve into ELFs of another architecture and find dependencies.
The original kernel does not know anything about UBIFS, so the image created earlier will have to be left aside, and I will be collecting with the help of cpio, gzip and mkkrnlimg:
Alas, the boot partition is a bit small, and you have to tweak the parameters slightly, expanding it and moving the rest of the sections, for ease of editing, expand it to 512MB (0x00100000):
At the same time, there was also a path to the init file, corrected it also on / sbin / init. Package:
By the way, the cache, kpanic and userdata sections are used to erase the first 256KB, and not to touch the user section at all, as I learned from the RK29kitchen sources, but the sections following the system excite me a little. Sections misc and kernel do not change. In the boot I upload Arch Linux, I rub the rest entirely.
I was a little sad at the size of boot.img and further offset for erasing. I wonder how many similar errors I have already made? Maybe a non-native kernel would start up normally?
After the restart, it takes about 10 seconds, then the LED lights up. And, lo and behold! 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 clean (nothing but 00 and FF).
You need to be a good specialist at a high level so that without documentation and source codes you can cope with such a device, and this specialist is clearly not me. Either the device is absolutely not what you need.
I really wanted to lay out the images that I had, upload screenshots and a short video with some new 3D game, but no luck. Agree, bad experience is also an experience.
I present an abbreviated list of the interesting things that I read, which for some reason did not fall into the links to the topic itself.
androidforums.com/google-tv/505559-flashing-android-tv-box-one-four-usb.html
androidforums.com/google-tv/506298-rk2918-android-tv-box-4x-usb-rooted-firmware-manual.html
androidforums.com/google-tv/413090-r-box-rockchip-2918-google-tv-3.html
sites.google.com/site/rk2918tools
thomaspolasek.blogspot.com/2012/04/arch-linux-lxde-w-xorg-mouse-keyboard_16.html
cxem.net/comp/comp70.php
github.com/OlegKyiashko/RK29kitchen
4pda.ru/forum/lofiversion/index.php?t337784-50.html
4pda.ru/forum/index.php?showtopic=319345
4pda.ru/forum/index.php?showtopic=313261
forum.xda-developers.com/showthread.php?t=1286305
www.androidtablets.net/forum/rockchip-rk2818-tablets/21291-problems-getting-image-dumped-rkdump.html
www.androidtablets.net/forum/rockchip-based/439-how-unpack-repack-custom-firmwares-rockchip-rk28xx.html
www.freaktab.com/showthread.php?287-RockChip-ROM-Building-Tips-and -by--Tricks finless
www.freaktab.com/showthread.php?401-Dumping-ROM-using-ADB-guide
www.arctablet.com/wiki/index.php/Rockchip_2918_devices_MTD_partitions_mapping
yanzicjustnubie.wordpress.com/2011/09/ 10 / linux-installer-easy-way-to-install-debianubuntu-on-android chroot linux on android
wiki.debian.org/DebianInstaller/Arm/OtherPlatforms
www.arm.com/community/software-enablement/linux.php
code .google.com / p / beagleboard / wiki / LinuxBootDiskFormat
www.yoctoproject.org - build custom linux distro
www.freaktab.com/showthread.php?1053-RK2918-set-top-box-linux-installation
github.com/wendal/teclast_tools
wiki.archlinux.org/index.php/Partitioning#Partitions_in_a_GNU.2FUnix_system
A wonderful search query
Of particular note is www.cnx-software.com , an interesting site about everything related to ARM.
Selection with prices
olimex.com/dev/index.html
rhombus-tech.net/allwinner_a10
www.hardkernel.com/renewal_2011/products/prdt_info.php?g_code=G133999328931
www.technexion.com/index.php/products/development- kits / infernopack
www.advantech.com/products/ROM-1210/mod_D5882807-78CE-4A64-AADA-FAEAA099F2CB.aspx
www.sigmadesigns.com/products.php?id=38
www.renesas.com/press/news/2012 /news20120110.jsp
And the prototype of all these HDMI sticks on the processor is the line above.
www.cnx-software.com/2012/07/10/ippea-tv-android-4-0-3-hdmi-stick-based-on-ingenic-jz4770-mips-sells-for-50-usd
www.uplaytablet.com/compare-soc-cpus-used-in-ainol-elf-aurora-ii-amlogic-8726-mx-wopad-i7-i8-rock-chip-rk-2918-and-wopad-a10- allwinner-a10
rhombus-tech.net/evaluated_cpus - overview of various processors for use in compact devices
en.qi-hardware.com/wiki/Main_Page
www.wits-tech.com/pages/board-en.jsp
www.pineriver.cn /eshowProDetail.asp?ProID=1527
www.calao-systems.com/articles.php?lng=en&pg=6186
www.st.com/internet/mcu/product/251211.jsp
www.st.com/internet/evalboard/ product / 253211.jsp
archlinuxarm.org/forum/viewtopic.php?f=27&t=2709 Mele A1000 Archlinux
rhombus-tech.net/allwinner_a10/hacking_the_mele_a1000
www.cnx-software.com/2012/06/13/hardware-packs-for-allwinner-a10 -devices-and-easier-method-to-create-a-bootable-ubuntu-12-04-sd-card
gitorious.org/ac100/abootimg/blobs/master/README
The reassurance of the spiteful critics from my previous post, that Youtube and other applications installed from Play, earned great, and the device found no more flaws.
Most recently, a couple of topics appeared, which described how Puppy Linux, Arch Linux and Ubuntu were installed on an ARM device. This is a unique feature of Allwinner A10, which is hard to underestimate, but still the system is physically run from an SD card, rather than a 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 flash memory of the device, which is encouraging and possibly opens a loophole for uploading full-fledged GNU / Linux. It is presumptuous to note that this is already the next step for the banal launch of a slightly doped image from an SD card.
purpose
- Install the Linux kernel on the device. Preferably the newest. Or the newest of those that contains all the drivers specific to the device;
- Put GNU;
- Set the desktop environment;
- Make a backup so that the device can be returned to its original state, if something goes wrong;
- Good fun with a difficult task (comparable to installing the first versions of USB downloaders on the Wii and passing NetHack or Dwarf Fortress).
')
Facilities
GV-2B device from an unknown Chinese manufacturer , based on Rockchip 2918 (abbreviated RK29) (CPU ARM Cortex A8 1GHz + Vivante GC800 600MHz GPU), with 4GB of flash memory, 512MB of RAM and a fair amount of connectors.
16GB SD card class 10.
PC with Arch Linux.
Keyboard.
Monitor.
HDMI-DVI cable for connecting a monitor.
A bunch of USB cords, adapters and so forth.
Caution and self-flagellation
Surely many of the readers would have done what is described in the topic, or at least some particular part, faster and better, but I did not find any mention of such a feat in the network. The topic contains a lot of practice and quite a bit of theory, only the most necessary to understand what is being said 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, pulls on a three-hour laboratory work. I also want to say that I am doing all this for the first time, if we exclude the connection of a disk with Ubuntu pre-installed on a desktop computer to a PC104 x86-compatible single-board.
Device selection
In the model number G, there are about twenty different devices, on different processors, with different numbers of connectors, but about the same functionality.
At first, I was killed about not taking the device on the Allwinner A10, but after reading a few reviews about the openness of the kernel sources to it, I realized that the situation with Rockchip is not much worse.
There was an option to order a device of the same model range, but already with the Cortex A9, namely AmLogic 8726-M, but it does not have any significant advantages over the Rockchip 2918, and with the initial code for the latest chips, judging by the AmLogic website , everything also sadly
Methods
So, three ways were found to update the firmware of the device (the contents of that 4GB flash memory).
The first - from the manufacturer using one of the OEM models of the GV line, did not work, and it’s good, because their firmware is meant for a slightly different device, to which there are three USB ports, and the difference between them is so serious that the firmware usually turns into device conversion in brick
Two left. The second, from the hacker with AndroidForums , is that you need to make an additional, second reset button inside the box, while holding it to hold the power button for a few seconds. This method has opened 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
To my great regret, the keyboard, being connected to the device, and working perfectly well after loading Android, had no effect on the system recovery menu, and of the three buttons on the board (power, reset, reset), only one acted on the menu - the first reset, which either led him to the selection of the default active item Reboot system now, or else it just worked for its intended purpose. The rest of the cursor buttons, unfortunately, did not move. The way was precisely to fill the firmware from the SD memory card, which did not work.
Having formatted the SD card in fat32, I uploaded to it with difficulty downloaded from the file dump (god, have they not heard of Dropbox?) The downloaded update for Android. With a normal boot, Android cursed that there was an incorrect update.img on the SD card. But I still didn’t hurry to upload it, because backups are made not only by cowards, and it often happened on the forums that uploading one or another update.img, which I earned from one author, on a similar device led to a transformation into a brick from another author.
The third
At first, I was very embarrassed by the fact that in the system recovery mode the device was not detected from the computer at all, despite the fact that I connected all the necessary wires where necessary (and not even where I sent the opposite power of 4.57V and 5.08V via USB, which fortunately It did not have any consequences). As it turned out later, this is the way it should be, because they have their own protocol there, and the difference with the connection of external media is significant.
Under Windows, the Rockchip Flasher tool program was discovered, which the language doesn’t turn out to be called wonderful, because it’s done terribly and the only thing that it can do is flash new update.img. But I had to not only flash, but also download the existing one, in case something suddenly happened, so I had to give up the work of Chinese programmers.
With the 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 the original version, if that goes wrong. For this there are several different methods.
Titanium Backup . Android application with which you can take a snapshot of system partitions and copy it to an SD card. Everything is good, but the device needs to be ruled for this (get administrative privatization). In order to root the device on Android 2.3.1, Universal Androot is no longer suitable, and its author offers the choice to use Unrevoked , which is only suitable for HTC phones, or SuperOneClick , which seems to be all good, but in order to root the device It requires connecting it to a Windows computer. Everything is good, but it downloads the firmware, adds some files there and uploads it back. Change the firmware in order to make a backup copy of it - this is insanity.
It remained to take advantage of the Android Debug Bridge from the Android SDK, which is not a fact that would work with this particular device, and pulling a considerable amount of dependencies, which I did not want at all. Everything else to collect all this was necessary from the source (read AUR for Arch Linux).
Having already become sad, I suddenly discovered the wonderful utility RK29kitchen , announced here, which, judging by the description, absorbed a number of other equally remarkable utilities from the authors, which disassembled the clever protocol of communication of devices via USB, and a little less cunning file with the partition table.
Launch
It turned out not so easy. It turns out that the device should not be in system recovery mode, but in the off state, but always with the power connected. The problem is that it tries to turn on as soon as it feels that it is connected via USB. But you can cope with this. Holding both reset buttons for 5 seconds, let go first, then after 3 seconds, and the internal one. I start 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 ) A little confused by the fact that the source flashdump'a says:
rkflashtool29 r 0 0x200 And in the output:
reading flash memory at offset 0x00000100 It is not entirely clear from which offset parm.img is read.
So, 5-10 minutes and the
$ 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 dig in the forums and source files of RK29kitchen, it becomes clear that I just read the contents of the flash memory of the device, starting with the partition table, which we have been disassembled on the shelves and recorded in the parameter text file, and using it, we recorded it separately.
It was here that an incredible amount of information was found that relates specifically to updating the flash memory of devices on the RK2918. All described devices are tablets, and connecting them to a computer for updating is somewhat easier (given the built-in microUSB port, also known as USB OTG).
This is how the parameter file looks like:
FIRMWARE_VER:1.2.3 MACHINE_MODEL:SUNVEK MACHINE_ID:007 MANUFACTURER:rock-chips MAGIC: 0x5041524B ATAG: 0x60000800 MACHINE: 2929 CHECK_MASK: 0x80 KERNEL_IMG: 0x60408000 CMDLINE: console=ttyS1,115200n8n androidboot.console=ttyS1 init=/init initrd=0x62000000,0x300000 mtdparts=rk29xxnand:0x00002000@0x00002000(misc),0x00004000@0x00004000(kernel),0x00002000@0x00008000(boot),0x00004000@0x0000A000(recovery),0x00080000@0x0000E000(system),0x00082000@0x0008E000(backup),0x0003a000@0x00110000(cache),0x00100000@0x0014a000(userdata),0x00002000@0x0024a000(kpanic),-@0x0024c000(user) The last line using the hexadecimal system contains the lengths, the beginning of the sections, and in brackets their names. A required section is missing in which the partition table itself is actually stored. I'll try to decipher.
The size of the parameter block read is 0x200 (from the source files RK29kitchen), this 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 occupies the 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. I know from earlier knowledge that they make cramfs in flash format for writing files that are not meant to change (such as the OS kernel), but some particularly tricky Chinese manage to add more headers and footers to these images, then use gzip, apparently trying to make it difficult to read his own and create his own images.
It was this miracle, called 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 It is necessary 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 Fine. I came across the same case, when files are packed with gzip, and then the ridiculous header and basement 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 too clear, necessary or not. To collect this case in the reverse order, you need to be even more careful, you need to reset the dates on the files:
$ find . -exec touch -d "1970-01-01 01:00" {} \; $ find . ! -name "." | sort | cpio -oa -H newc | gzip -n >../customboot.gz $ cd .. $ rkcrc -k customboot.gz customboot.img For assembly of images cpio is traditionally used. Compared to the more popular tar, cpio has a number of advantages that I don’t want to delve into in this topic.
And here, in my hands is a customboot.img assembled with my own hands, which can be poured back into the device.
With kernel.img, this preparation does not work.
But 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 The Android app files were found in the app folder (the archive of the executable file). That is, you can add there any new programs or delete those that are, including some annoying and annoying. In bin, you can add su and busybox, which as I understand it, is enough to root the device. In etc change the configuration. And so on. In theory. In practice, you have to tinker a little with the fact that in the mounted image of cramfs you just can’t write anything down.
Well, it was possible to dissect something.
New image
It would be great, of course, to try booting from the SD card by uploading an image carefully prepared by someone, but the RK29 doesn’t have such a possibility, so you have to create an image and flash it directly into the flash memory of the device. I hope that there is a backup.
The images prepared in the previous paragraph were all in different formats, namely:
boot.img was in the cra p fs format, and the rest, which are already loaded after it, are more digestible. From here I will assume that dances with a tambourine are coming only with this boot.img, and with the rest of the images everything will be more or less trivial.
I will refresh the memory, I will write what sections are needed to install Linux.
/ Root section. It contains an important / boot folder containing a kernel image. / boot can be made a separate partition, on the other, not journaling, file system (as it is used only when booting and updating the kernel). But for simplicity, you can keep it in the root section. Another important folder, / home, contains user data, and it's nice to allocate a separate section for it. Swap, is needed for virtual memory for devices with less than 1GB of memory, but it is at least unwise to use the built-in flash memory with a limited read-write cycle for this, it’s better to pick up an external SD card for this purpose. / 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 will make an image consisting of three sections:
/ boot, 16MB with file system cra p fs
/, ~ 4GB remaining space for root file system
We will not create a / home, we will live as long as root, and how we will mount an external SD card, so we will also mount it
/ swap will also be mounted on the external flash card
I downloaded and unpacked the latest open source kernel, which is sharpened for Rockchip 2918, from odys.de. Kernel version 2.6 saddened. Archlinux ARM kernel cross-compilation instructions made you feel like a dumbass, and upset the list of supported devices. Yoctoproject is slightly 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, confused. Already started glancing towards LFS . Is there really no universal thing that would have run out of poltychka on more or less standard equipment based on the Cortex A8 / A9? Uffff.
I haven’t left a choice, I’ll have to cross-compile the kernel from the sources and build the images myself. I downloaded the linux-linaro-3.5-rc3-2012.06.tar.bz2 source code and the cross-compilation toolkit gcc-linaro-arm-linux-gnueabihf-2012.06-20120625_linux.tar.bz2. The only shame is that a device-specific .config file is needed for compilation, which Linaro does not have for RK2918. Fortunately, in the previously mentioned odys kernel there are Rockchip-specific files, and they were also found in the newer source code from easypix.eu. I copied them to the source from Linaro, namely:
- folder arch / arm / mach-rk29
- 50KB arch / arm / configs / rk29_ddr3sdk_defconfig with a huge number of device-specific options
- last line from arch / arm / tools / mach-types
- section ARCH_RK29 from arch / arm / Kconfig
- mkkrnlimg from the source root
Cross compiling 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 cute, but fixable. It turns out that someone carefully erased two lines and a comment. I remember, this is called memory optimization and refactoring, but this time it does not suit me, and I will have to return it to the place:
static void __put_css_set(struct css_set *cg, int taskexit) { struct cg_cgroup_link *link; struct cg_cgroup_link *saved_link; It worked. Interestingly, stable builds from Linaro generally try to compile, how do compile errors get through?
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 source code from odys, but another error occurred, as well as 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 the build? Edit C code in which I do not understand anything? I coped with the first error, then I found a patch that did not help a bit, and I had to fix it at random, focusing on inode.c. There were errors with the struct mtd, and I must say that in the kernel version from Android 3.4, everything is the same , and it has come that there’s no hope of waiting. It has come that day of early morning is wiser. But the desire to remove all the lines related to 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 fast:
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 Go ahead:
$ 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 only alerted that nothing specific was compiled RK29, and it is very suspicious. uImage is received.
3.0.8+ from easypix.eu
In any spare case I decided to try to collect the source code from easypix.eu. Here you can clearly see that the source code for RK29 is compiled. There is no YAFFS in .config, nor is UBIFS. There are only read-only cramfs, which is suitable for / boot, but not at all suitable for the root partition. Build 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] Fixed .config, removed the BCM4329 WiFi module from there and added all possible file systems for flash memory. I did not understand whether the driver RTL8192 would be compiled, but that’s ok. 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 nucleus with the remains that the easypix threw us.
It is tempting to create a HWpack for Linaro, but there is no experience in this matter, the desire to support alone - too. So we take the latest kernel from Linaro git and will gradually roll on it what is needed for normal operation of the RK29.
So, now .config and Kconfig from easypix.eu. I realized that last time I forgot to add a line to arch / arm / Kconfig:
source "arch/arm/mach-rk29/Kconfig" and in the Makefile:
machine-$(CONFIG_ARCH_RK29) := rk29 <source> : <source> $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- rk29_ddr3sdk_defconfig added the following to .config:
CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y CONFIG_TMPFS=y CONFIG_UBIFS_FS=y CONFIG_UBIFS_FS_ADVANCED_COMPR=y But that's not all. Searching for 'rk29' in source code gave 10707 matches in 358 files to be played, among them audio drivers, codecs, Makefiles, Kconfigs, scattered evenly throughout the project.
I leave it behind the scenes of this topic. As soon as it works out, I will definitely update the topic and post the source code and the results. If you want to join my impulse - write.
Distributive
As you know, you will not be fed up with the core , and GNU is supposed to submit to it. It describes what and why you need to turn the kernel into a full-fledged operating system.
Ideally, you want Arch Linux, and as it is written on their website, you can take the distribution for any other device and just add your 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 big the self-made kernel is (almost 7MB) compared to the kernel for BeagleBone (2.7MB). The root folder, from which I am going to make an image of the root partition, occupies about 421MB, 10% of which occupy the kernel sources that are completely unnecessary in my situation (linux-3.2.18-1).
Build and Fill
Training
So, I have two folders, boot and root, of 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 came together with support for both JFFS2, and UBIFS, and EXT [2 | 3 | 4], and VFAT and MSDOS. On the network, they praise YAFFS2, it is a little faster than UBIFS and uses slightly less RAM, but the build again gave 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 takes 256K of memory at the beginning of flash memory, which I quoted at the beginning of the topic.
KERNEL_IMG, coincides with what the kernel issued at the end of the build, so there is no need to change. CHECK_MASK is the same for all the images I have seen, I don’t touch either. The rest of the lines, too, except for CMDLINE, containing the table of MTD partitions and loading arguments.
The site U-Boot says that the MTD partition table can be set in a simplified form, but I will not risk it, and I will be as close to the original as possible.
So, the memory in the device is distributed as follows:
256KB per parameters file
16MB on / boot (in case you suddenly want to reload only the kernel, but it will outgrow 8MB)
residue on /
It looks like this:
mtdparts=rk29xxnand:0x00008000@0x00002000(kernel),-@0x0000a000(system) Before:
CMDLINE: console=ttyS1,115200n8n androidboot.console=ttyS1 init=/init initrd=0x62000000,0x300000 mtdparts=... It seems to be in the Linux kernel, starting with 3.0, the console began to be called differently, tty01, etc., but leave it as it is.
we will not need androidboot.console and init. I decided not to do the initrd (a disk in memory that is used to assemble and dynamically load modules), perhaps in vain. It is necessary to establish the location of the root partition by sticking to it in the desired mtd partition (numbering starting from 0). You also need to specify the file system type for the root partition.
The total is:
CMDLINE: console=ttyS1,115200n8n root=/dev/mtdblock1 rootfstype=ubifs noinitrd mtdparts=rk29xxnand:0x00008000@0x00002000(kernel),-@0x0000a000(root) Assembly
MTD partition table and kernel startup options
I launch mkkrnlimg from RK29kitchen:
$ mkkrnlimg -a parameter parameter.img F535BA01 $ ls -l 316 Jul 5 22:56 parameter 328 Jul 10 20:27 parameter.img It is embarrassing 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 then only at the beginning of the file. Most likely, the Chinese were insured in case U-Boot would try to load this data at another memory offset, 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 occupied with anything, also contain 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 hex editor from mc helps, and I correct the title to be like the original.
Core
$ mkkrnlimg -a uImage kernel.img 7DDF79C6 $ ls -l 7139328 Jul 5 22:49 uImage 7139340 Jul 10 20:42 kernel.img <source> 12 , 8 , , 4 . , boot.img ( 8, gzip' cpio) . <h5> UBIFS</h5> , <a href="http://www.linux-mtd.infradead.org/faq/ubifs.html#L_mkfubifs"></a> ( ), <a href="http://lists.infradead.org/pipermail/linux-mtd/2008-April/021189.html"></a>. , erase NAND . Samsung 201 K9GBG08U0A SCB0, <a href="http://gxwy.en.alibaba.com/product/530746803-213362683/IC_Samsung_Nand_Flash_Flash_Memory_K9GBG08U0A_SCBO.html"></a> 4, erase 128+4, 2. UBIFS UBI ubinize.cfg: <source> [ubifs] mode=ubi image=ubifs.img vol_id=0 vol_size=4000MiB vol_type=dynamic vol_name=rootfs vol_flags=autoresize $ mkfs.ubifs -q -r ~/gv2b/root -m 2048 -e 131072 -c 32767 -o ubifs.img $ ubinize -o ubi.img -m 2048 -p 128KiB ubinize.cfg $ ls -l 221904896 Jul 10 01:14 ubifs.img 229376000 Jul 10 01:17 ubi.img UBIFS supports data compression, and I limited the size of a 4GB volume to a similar physical media size, not sure if this is the right solution.
Firmware
It is a little embarrassing that it is desirable to use a special algorithm for recording UBI images.
The parameters of the initial position and size to rkflashtool are specified in blocks of 512 bytes in size.
The image of the parameter.img partition table is written in five different offsets, like in 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 <source> , 4 , , 50 . . : <source> $ rkflashtool29 b Trial and error method
First start
The first launch was not that not successful, but I’ll just say that it’s a failure. The device did not turn on the diode, did not react to pressing the buttons, and did not issue anything via HDMI. Very well, that still made a backup. Very well, the device is still able to receive data. Restore to original state:
rkflashtool29 w 0 0x00082000 < backup.img The device continues to not work.
I launch ./menu.sh from RK29kitchen, change the size of the / system partition in the backup and flash it. The device turns on, and shows the string "Loading ...", but does not go further. Already not bad. I restore the original backup, after the second reboot, Android is still loaded in its original form.
What did i do so and what is wrong
After digging into the source code of RK29kitchen and on the forum where rkflashtool was announced , it turned out that I was not in vain attributing this image to five different shifts, and that it was necessary (90.flash.sh).
The parameter.img file contains “PARM” in the first four bytes, and the next two that 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 defined and U-Boot could not load the kernel), but does not explain why the light did not light up. Instead of trying on a hex editor, the rkcrc utility was found, which makes an image from the parameter file with the correct headers and a total size of 16KB, launched with the "-p" option. The "-k" option is used to create images with the tag "KRNL".
Rummaged in the original backup.img. It is not clear whether it was worth changing the partition table so radically, it is clearly readable in the file that dimensions, offsets and order (sections should go in order of offset) can be changed, and new sections can be created, but the names of sections cannot be changed. Who exactly sets such a restriction is not clear, but most likely a bootloader (U-Boot?).
It was also found that RK29xxLoader (L) _V2.08.bin is used (the binary version 2.04 clearly goes a little further), while versions 2.12, 2.14 and 2.18 are also found in the list of bootloaders RK29kitchen, and in Nextbook, in general, 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 it is not clear. In addition to the bootloader, there is also a package-file, containing a lot of interesting information.
Attempt number two, panic and discouragement
I repeat the whole procedure of the firmware, but now with the correct parameter.img. Does not work.Restoring back.
At some point, foolishly instead of taking advantage of RK29kitchen, I recorded backup.img right at offset 0. Then I restored the backup, once again took the dump and redundant backups of the wipers. 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 erased that initial backup, with the correct backup.img. I wrote a script to restore from individual images, but it did not help. At least the light when the device turns on. But for HDMI there is no signal.
I thought about extundelete, but realizing that it would require chroot and umount, I abandoned this idea in fear of bogging down the system not only on an inexpensive Chinese device.
I stitched all possible firmware, from gbox (a bit of another device with only three USB ports), from the author of the firmware method, found here . Nothing helped. Anyway, brick, sometimes with the LED when turned on, and sometimes completely without. It was early morning, and once again I decided that the evening of early morning was wiser.
And how I was right. Connecting the device to the monitor, it turned out that everything works.
Conclusions and Surveys
This experience, although not very pleasant, led me to the following conclusions and discoveries on the network:
- the device needs time to reformat partitions after the firmware
- some firmware have 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 may be 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 describing the device parameters
From one of the firmware:
HWDEF 0x00000800 0x0000031B package-file 0x00001000 0x00000216 RK29xxLoader(L)_V2.08.bin 0x00001800 0x000225BE parameter 0x00024000 0x00000251 Attempt number three
First of all, I made a complete dump of all 4GB of flash memory.
I try to fill the kernel from the backup, unpacking it and packing it again. If it does not work, it means that something is wrong.
I unpack, pack and flash:
mkkrnlimg -r kernel.img kernelimg mkkrnlimg -a kernelimg kernel2.img rkflashtool29 w 0x00004000 0x00004000 < kernel2.img Reboot - it works. The same trick with self-generated uImage does not work.
Even when unpacking using RK29kitchen of the original kernel.img, it was found that inside the image the signature differs from the standard version of U-Boot 27 05 19 56. All the various 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 walked XOR'om. I check, but, unfortunately, 8 and 16 bit do not fit, and 32 bit for the fourth quartet gives out too large a number to be the size of the image, and that in the third quartet, which should be time, too much matches between different images.
The search query for "D3 F0 21 E3" shows very few results, and among them even less interesting. Here in this thread of the Italian forum it is stated that the sources from Odys do not create the correct image, in contrast to these kernel sources from Anypad.
And it is possible that the problem is in using my mkkrnlimg from RK29kitchen, because the source from Odys and easypix comes with (by the way, the same) mrkrnlimg, which is very different in size and can convert only in one direction. No, the images created by all three utilities are no different.
I collect the core from Anypad. It is 2.6, but it is interesting to see what title the uImage will have. I got rid of the same error with the bcm4329 module.
I accidentally noticed that in my .config file the output to the LCD panel was turned on, and the DEFAULT_OUT_HDMI option was turned off. This is a huge puncture. I wouldn’t have been surprised if Linux had booted, but hadn’t shown anything via HDMI, and I wouldn’t have known that it had booted. A related DEFAULT_OUT_HDMI problem was found in rk29_fb.c, there was no hdmi_get_default_resolution function, and in the source files from easypix either. I had to write it by touch, putting down more than a dozen parameters. In the structure that this function fills in, there is an amusing parameter of swapping the RGB color channels.
The image was assembled, but in it the same ill-fated standard "27 05". And then I looked around, and in the same directory I noticed the image Image, and in it lies the long-awaited title "D3 F0". I looked at the results of assembling the easypix core - and there it is. A pleasant surprise.
You can not 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 difference in size is impressive. For the partition with the core, 8MB would obviously be enough, with a large margin. By the way, it is almost twice as different from the so-called “zImage” (which is actually just an Image) extracted from the image of the device core (5.8MB).
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- zImage $ ls -l arch/arm/boot 7135268 Jul 13 03:37 Image 7139328 Jul 5 21:41 uImage 3408472 Jul 12 00:20 zImage Well, now in the resulting image it remains only to add headers and flash. I want to note that rkcrc -k and mkkrnlimg -a give the same result.
I flashed it, turned it on - the diode is off. Something does not come out with the core. I corrected the header bytes diverging from the original (which, of course, before the CRC), added headers, flashed it — it doesn't work. He returned the old core to its place.
The thought crept in to look at the / kpanic section, for good reason it was highlighted. I downloaded, but alas, there is only something related to the panic of the regular kernel 2.6.32.27.
Desperate to flash your core.
Attempt number 4
Well, since the kernel could not be flashed, it may be possible to flash everything else, leaving only the kernel. Since it was not possible to take a raid, I will take small steps.
A small excursion into the theory. How is Android loading on the device?
1. When turned on from NOR memory (directly, since it supports execute-in-place), the bootloader, U-Boot, starts.
2. U-Boot loads the MTD partition table and loads the Linux kernel from the image into memory.
3. Linux initializes the device drivers, mounts partitions, etc., and then starts init from /.
4. init ... is
not interesting anymore, because this is Android's init, and just in its place I would like to write my own, from Arch Linux.
init is at the root, and in the Arch Linux distribution it is in / sbin. There is nothing else left but to copy it to the root.
In the original Android, the init file is not in the system section, but in the boot. That is, this particular boot partition is mounted to the root, and the system is mounted to / system. So leave.
In the original boot section is rk29xxnand_ko.ko, the module, obviously, designed to work with NAND flash memory. The remaining modules are located in /lib/modules/3.2.18-1/kernel, and links to them are written in /lib/modules/3.2.18-1/modules.order. Packed with gzip, the accompanying ko, I put it on the other modules related to nand in kernel / drivers / mtd / nand, put root.root rights on it, and write it in modules.order and modules.dep. It is unlikely that this will help the kernel find the required module, but it is not possible to force depmod to delve into ELFs of another architecture and find dependencies.
The original kernel does not know anything about UBIFS, so the image created earlier will have to be left aside, and I will be collecting with the help of cpio, gzip and mkkrnlimg:
$ find . -exec touch -d "1970-01-01 01:00" {} \; $ find . ! -name "." | sort | sudo cpio -oa -H newc | gzip -n >../boot.gz $ cd .. $ mkkrnlimg -a boot.gz boot.img $ ls -l boot.img 155166888 Jul 13 20:55 boot.img Alas, the boot partition is a bit small, and you have to tweak the parameters slightly, expanding it and moving the rest of the sections, for ease of editing, expand it to 512MB (0x00100000):
CMDLINE: console=ttyS1,115200n8n androidboot.console=ttyS1 init=/sbin/init initrd=0x62000000,0x300000 mtdparts=rk29xxnand:0x00002000@0x00002000(misc),0x00004000@0x00004000(kernel),0x00082000@0x00008000(boot),0x00004000@0x0008A000(recovery),0x00080000@0x0008E000(system),0x00082000@0x0010E000(backup),0x0003a000@0x00190000(cache),0x00100000@0x001ca000(userdata),0x00002000@0x002ca000(kpanic),-@0x002cc000(user) At the same time, there was also a path to the init file, corrected it also on / sbin / init. Package:
$ rkcrc -p parameter parmnew.img $ ls -l 16384 Jul 13 21:13 parmnew.img By the way, the cache, kpanic and userdata sections are used to erase the first 256KB, and not to touch the user section at all, as I learned from the RK29kitchen sources, but the sections following the system excite me a little. Sections misc and kernel do not change. In the boot I upload Arch Linux, I rub the rest entirely.
$ 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 a little sad at the size of boot.img and further offset for erasing. I wonder how many similar errors I have already made? Maybe a non-native kernel would start up normally?
After the restart, it takes about 10 seconds, then the LED lights up. And, lo and behold! 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 clean (nothing but 00 and FF).
Conclusion
You need to be a good specialist at a high level so that without documentation and source codes you can cope with such a device, and this specialist is clearly not me. Either the device is absolutely not what you need.
I really wanted to lay out the images that I had, upload screenshots and a short video with some new 3D game, but no luck. Agree, bad experience is also an experience.
Links
I present an abbreviated list of the interesting things that I read, which for some reason did not fall into the links to the topic itself.
Firmware, images, iron
androidforums.com/google-tv/505559-flashing-android-tv-box-one-four-usb.html
androidforums.com/google-tv/506298-rk2918-android-tv-box-4x-usb-rooted-firmware-manual.html
androidforums.com/google-tv/413090-r-box-rockchip-2918-google-tv-3.html
sites.google.com/site/rk2918tools
thomaspolasek.blogspot.com/2012/04/arch-linux-lxde-w-xorg-mouse-keyboard_16.html
cxem.net/comp/comp70.php
github.com/OlegKyiashko/RK29kitchen
4pda.ru/forum/lofiversion/index.php?t337784-50.html
4pda.ru/forum/index.php?showtopic=319345
4pda.ru/forum/index.php?showtopic=313261
forum.xda-developers.com/showthread.php?t=1286305
www.androidtablets.net/forum/rockchip-rk2818-tablets/21291-problems-getting-image-dumped-rkdump.html
www.androidtablets.net/forum/rockchip-based/439-how-unpack-repack-custom-firmwares-rockchip-rk28xx.html
www.freaktab.com/showthread.php?287-RockChip-ROM-Building-Tips-and -by--Tricks finless
www.freaktab.com/showthread.php?401-Dumping-ROM-using-ADB-guide
www.arctablet.com/wiki/index.php/Rockchip_2918_devices_MTD_partitions_mapping
yanzicjustnubie.wordpress.com/2011/09/ 10 / linux-installer-easy-way-to-install-debianubuntu-on-android chroot linux on android
wiki.debian.org/DebianInstaller/Arm/OtherPlatforms
www.arm.com/community/software-enablement/linux.php
code .google.com / p / beagleboard / wiki / LinuxBootDiskFormat
www.yoctoproject.org - build custom linux distro
www.freaktab.com/showthread.php?1053-RK2918-set-top-box-linux-installation
github.com/wendal/teclast_tools
wiki.archlinux.org/index.php/Partitioning#Partitions_in_a_GNU.2FUnix_system
A wonderful search query
Other
Of particular note is www.cnx-software.com , an interesting site about everything related to ARM.
Another interesting iron
Selection with prices
olimex.com/dev/index.html
rhombus-tech.net/allwinner_a10
www.hardkernel.com/renewal_2011/products/prdt_info.php?g_code=G133999328931
www.technexion.com/index.php/products/development- kits / infernopack
www.advantech.com/products/ROM-1210/mod_D5882807-78CE-4A64-AADA-FAEAA099F2CB.aspx
www.sigmadesigns.com/products.php?id=38
www.renesas.com/press/news/2012 /news20120110.jsp
And the prototype of all these HDMI sticks on the processor is the line above.
www.cnx-software.com/2012/07/10/ippea-tv-android-4-0-3-hdmi-stick-based-on-ingenic-jz4770-mips-sells-for-50-usd
www.uplaytablet.com/compare-soc-cpus-used-in-ainol-elf-aurora-ii-amlogic-8726-mx-wopad-i7-i8-rock-chip-rk-2918-and-wopad-a10- allwinner-a10
rhombus-tech.net/evaluated_cpus - overview of various processors for use in compact devices
en.qi-hardware.com/wiki/Main_Page
www.wits-tech.com/pages/board-en.jsp
www.pineriver.cn /eshowProDetail.asp?ProID=1527
www.calao-systems.com/articles.php?lng=en&pg=6186
www.st.com/internet/mcu/product/251211.jsp
www.st.com/internet/evalboard/ product / 253211.jsp
Installing GNU / Linux on hardware
archlinuxarm.org/forum/viewtopic.php?f=27&t=2709 Mele A1000 Archlinux
rhombus-tech.net/allwinner_a10/hacking_the_mele_a1000
www.cnx-software.com/2012/06/13/hardware-packs-for-allwinner-a10 -devices-and-easier-method-to-create-a-bootable-ubuntu-12-04-sd-card
gitorious.org/ac100/abootimg/blobs/master/README
Source: https://habr.com/ru/post/147793/
All Articles