ojogoperdi

I was curious if it was possible to boot from a file of the armbian image in the SD card (not flashed there, but as a normal file in a normal filesystem). That is not a very simple task. I know I would have to mount the file, chroot to the system, exec init. In the best scenario, I would have kexec'd the kernel inside the armbian image before exec'ing init. But kexec'ing (or booting) newer kernels doesn't work here if I booted from the SD card, from a modified multitool image. I'll provide some when I get a chance this week. Sadly, I cannot do that. They are government property. I'll still try to provide pictures of the internals of the devices. Sorry, I did not read it carefully. Instructions clearly say to erase the eMMC. They boot from SD if the eMMC is erased. I was trying to avoid doing that, because restoring the internal storage takes a while. Because multitool boots from the SD card, I thought there must be a way to boot armbian from the SD card without modifying the internal storage. I'll avoid talking about brand names from now on. Boards only, got it. Thank you for your patience. Sorry for all the confusion you had to deal with.

I haven't read the whole thread. Sorry for any information you had to repeat! I'll take some due time to read it when I enter school break. I meant it in a more of a "create custom images for our client" kind of way. (more on the client at the end) It's not in the scope of this thread, so don't worry about it! For the first question: not all devices. But I am sure they all have one thing in common: they are based on rk322x chips. I said they don't boot, but I should clarify. I mean they don't boot without further intervention. After flashing armbian, the board is "soft-bricked". Multitool doesn't boot from SD again. If I force them into maskrom and upload a bootloader you posted in this thread, they can boot armbian. For all that I tested, I could recover them. I don't have access to a serial adapter yet, sadly. As for why I'm sure they are all rk322x (at least the vast majority): this week we flashed some hundreds of the same model of device, and about 12 didn't boot completely, for reasons we have yet to investigate, and maybe 2 of those gave no video signal again. All other devices reached a desktop session. On these devices, building multitool from your repo (./create_image rk322x) or using a premade image, replacing the kernel with a newer one doesn't work for us. The devices never boot. Kernel seems to panic before starting the HDMI driver, or whatever makes the console output appear on the screen. I don't yet have access to a serial adapter, but I'll report if I have any output when I try. However, the mysterious part is that armbian images (with any kernel version) boot! (if installed into the eMMC) For some reason, booting from the SD card with a kernel version other than 4.4 doesn't work, but from armbian installed on the eMMC works. just armbian. I said eMMC image because I thought it was only meant to work there. Is armbian supposed to boot from the SD card? That never worked here. And I assumed it wouldn't because it doesn't contain the special images at the special offsets described here https://opensource.rock-chips.com/wiki_Boot_option But I read the first post again and you said it's supposed to work. Now I'm kind of confused as to why it doesn't work here. The Brazilian government confiscated (big) irregular shipments of TV boxes. They plan on repurposing some of them (the ones that are actually usable) as mini PCs for schools and other social causes. So our university got a portion of TX9-brand boxes to explore the feasibility of using these devices as PCs. They are very sluggish, and I don't expect them to be usable for this purpose.

hi @fabiobassa I'm part of a research team / group in my university. Our overall goal is to install Linux on TV boxes that we receive. Right now, we are creating, flashing and testing armbian images. Currently, we have a lot (hundreds) of TX9 boxes (based on rk322x chips). That's why we are using the tools you and jock created. I decided to focus on how the device boots, because some tests broke a lot of assumptions I had about the boot process. Some devices wouldn't boot after flashing, so there must be some nuance of the boot process that we don't understand. After a lot of rabbit holes trying to understand why some wouldn't boot, I only got more questions. Why is the eMMC image so barebones compared to the multitool image when it comes to the rockchip boot section? Why does multitool only work with an old kernel version, but armbian installed in the eMMC work with all kernel versions? The reason I am even trying to answer these questions is because I want to create something that would allow us to test armbian images without having to flash them to the eMMC, as that takes time (and can leave some TV boxes unusable). I ran into problems trying to run newer kernels from multitool in any way I tried. Because you two built these tools, I thought you also ran into similar problems, or had better insight to understand these problems than I have. But it's alright if you don't! I still plan on messing around with the TX9 TV boxes and figure out answers to these questions eventually.

Here are the dmesg logs. I didn't have time to test kexec from armbian on eMMC. Sorry about that! dmesg.log dmesg-kexec.log

Hey @jock and @fabiobassa, thanks for all the work you put on this! My team has been messing around with TV boxes (TX9) and the tools you made. I have some questions about the boot process of these TV boxes, and I'm hoping you could share some insights we don't have yet. Sorry in advance for the long post! Question 1. According to the rockchip wiki, the SD card boot process and the eMMC boot process are the same, only the boot device changes. We understand the first 16 MiB of the boot device should contain multiple stages of bootloaders (the rockchip miniloader, trust.img and U-boot) in specific sectors. Looking at the multitool image, we find the expected data at the expected offsets (sectors 0x40, 0x4000 and 0x6000). On the armbian image, there's a difference! We could find idbloader at sector 0x40, but the user partition starts at sector 0x2000, so there isn't any more rockchip-specific "magic" data after that! So my question is: why does the eMMC only need the idbloader, while the other boot stages are required for the SD card to boot? I have a theory that trust.img and u-boot are there in the eMMC, but offset behind what the operating system can access (for example, Linux wants to read sector 42 of the eMMC, and the controller translates that to a read to sector 42+0x8000). But that doesn't account for the need for the idbloader to be in the armbian image. In the end, the idbloader would be located at sector 0x8040, which isn't where it would be expected. Question 2. Armbian installed in the eMMC works. We tested kernel versions 4.4, 5.something and 6.1. All work as expected. We were able to extract the "magic" rockchip section from the multitool image and use that to create bootable SD card images from backups of the eMMC (armbian). We create a FAT partition similar to the multitool partition and put there an extlinux config and the kernel and DTB from multitool. The extlinux config is modified so it points to the correct rootfs, and the system boots (even the UI works)! However, replacing the multitool (or modified armbian) kernel.img with a more recent kernel doesn't boot. We expected that just changing the kernel and adding to the command line "console=tty1 verbose=1" should at least show something if the kernel is able to start the HDMI driver. (even if it would eventually panic because it couldn't find the rootfs or a initramfs) But because nothing shows up, either the kernel isn't being loaded at all or it isn't able to start the HDMI driver or it panicked very early in the boot. We tried using the DTB that comes with multitool and the DTB in the armbian image, to no avail. Why is it that the same kernel that works on armbian installed in the eMMC doesn't even boot on multitool installed on the SD card? Have you had luck with newer kernels + multitool? Questions 3.1 and 3.2. To work around the problem of only one kernel being sure to boot from the SD card, we tried kexec'ing newer kernels. We recompiled the kernel to enable the kexec feature and it boots from the SD card. We kexec the same kernel, to make sure it works, passing the same command line used to boot it. The HDMI output instantly turns off, but the device starts responding to pings after a while, so it's somewhat working. CTRL+ALT+DEL resets the device, as expected. Do you know why the HDMI output is instantly disabled and never turns on again? I don't have access to a dmesg log right now, but I can provide one on monday. But from what I read, there wasn't any difference in the HDMI related messages. And back to kexec: kexec'ing a newer kernel doesn't work! We don't have video feedback, the same as after the successful kexec, but it never responds to pings, and CTRL+ALT+DEL doesn't reset the device, so we assume it panicked. Have you had luck kexec'ing newer kernels? We still haven't tried kexec'ing after booting armbian. I will report on how that goes on monday.