dfahren

@Hqnicolas: Thanks for the invitation! I have the impression, you overestimate my capabilities to participate in this project. NPU, for example, I'm completely blank, have no idea what it is about. May be I'm able to integrate this particular OpenVFD driver in the kernel, but that is something for the (hopefully not so distant) future. Panfrost, rkvdec and so on is for the DEVs with high stakes and - without any doubt - boat loads of time, which, very unfortunately, have not ... 😞 I'll get back to this forum once I have good news to share (or questions to ask). Till then: all the best to everybody!

@Hqnicolas I submitted a PR for you to review. Notice that it is somewhat fragmented and may not be mergable right away. I hope you can integrate it with your repo. Feel free to get back to me if you have questions or want amendments or the like ... 🙂 Best wishes, Deetsh

@Hqnicolas Thanks! Yes and yes. 😀 I'd like to have others test this u-boot, too, if you don't mind. In due time, you will get a PR for your repo and may include it in Armbian. However, I think it is too special for inclusion right into Armbian source code, but you can decide once you looked at the PR.

Hi folks, my pondering about whether or not it is sensible to boot into LOADER mode once you press the recovery button has reached a conclusion. I decided that entering LOADER mode is a silly idea because flashing an Armbian.img file always starts at sector 0x00 of the emmc chip. In LOADER mode flashing is allowed at address 0x2000 only so we can't flash Armbian or other IMGs. So if you press the recovery button, the board resets and enters BROM mode. After that you can use either "rkdeveloptool" (Linux) or "rkdevtool.exe" (Windows, version should be greater that 2.85, mine is 3.19). As an attachment you can find my freshly created u-boot.bin file for you to test. But hold on for a second, I have to tell you a couple of things so that you don't feel miserable after you did things whose implications you couldn't fully grasp. This new image is a conglomerate of u-boot, spl, and atf, no optee. It is based on u-boot tag 2025.01 and is applicable to kernel 6.12.10 (maybe it works for others, too -> please tell me.) It uses the rockchip blob for DDR chip training and configuration that was created for RK3568 chips by Rockchip themselves, the last frequence selected is 1536MHz, which seems to be ok for our SK hynix LPDDR4 chips that operate with 3733Mbps. --- DISCLAIMER --- In what follows, everything you are doing on your on risk! I will not be held accountable for any damage, lost time, broken plates, dead tv boxes whatsoever and other misery that may or might result from you doing the next steps mentioned below. Keep that in mind! Now you are on your own. I strongly encourage you to attach a serial converter UART-to-USB to the board so that you can see all the statements u-boot is going to output. This is especially important if something goes wrong. Most likely your tv box won't run your Armbian installation after completing the flashing procedure! Be aware of that. You may, however, press the recovery button on your board and restart it with a USB-A cable plugged in on both ends and enter MASKROM mode. Flashing procedure Unpack the archive that is attached to this post (e.g. "xz -d <archive name>") and store it for later use. Insert a USB-A-to-USB-A cable in your tv box. Short the pins CLK and GND on your board and insert the other side of the cable into a free slot of your pc. If you don't know where to find the pins on the board, please don't flash this u-boot and read this thread thoroughly. These operations here are not for novices! Open a shell (I prefer Linux, but you can do the same in Windows) and type "rkdeveloptool ld" (or doubleclick on "rkdevtool.exe" in Windows) You should see something like this "DevNo=1 Vid=0x2207,Pid=0x350a,LocationID=101 Maskrom". If not, repeat step 2 again until you can see the output. In Windows you would see something like "MASKROM device found". Find yourself a loader bin, this thread has one for 4gb and one for 8gb. We select the one for 8gb whose name is "H96-MAX-8gb-MiniLoaderAll.bin" but you equally well take the other one, it really doesn't matter. Issue the command "rkdeveloptool db H96-MAX-8gb-MiniLoaderAll.bin". After a short while you should get a success message Next issue the command "rkdeveloptool wl 64 <path-to-your-bin-file>/u-boot-2025-01-rockchip-6.12.10.bin", where <path-to...> is a placeholder you substitute with what it states, right? You should also get a success message. Unplug the USB cable and attach the UART-to-USB converter to your pc for reading serial console output. Notice, if you have a CP2102-based converter, you can't use it with standard drivers in Linux! Well, of course you can, but you would see garbled output only.) Power on your tv box and read the output on the serial console. If everything goes well, your Armbian should boot. Shutdown Armbian, power off your device. Press and keep pressed the recovery button, start your tv box by plugging the USB-A cable in both tv box and PC, read the output of the serial console. Once you see "resetting..." you can issue the command in step 4 to check that in fact you tv box is in MASKROM mode now. That's it, I hope this is useful for you and again: Please don't do this procedure, although it seems easy to follow, if you need a working tv box. Most likely you are going to brick it! Cheers! P.S.: Please post here and tell me your results, especially in case you are unable to enter MASKROM mode. Thanks! u-boot-2025-01-rockchip-6.12.10.bin.xz

@Hqnicolas: Very good finding, this is the location where one should investigate further ... which I did. This litte posting is to let you all know that I was able to tweak u-boot so that when pressing the recovery button our tv box enters (at least for now) MASKROM mode. Stay tuned for an advanced u-boot.bin for you to test! So in the future we no longer need soldered wires to short the test points, which, at least in my opinion, is a good step forward. I'm still in the test phase of my amendments to u-boot and I'm still unable to enter LOADER mode, but I hope I'm able to solve this (hopefully little) issue, too. Until then, cheers and I'll keep you posted.

@Hqnicolas That means before May 2024 (the time the source code has been tagged) pressing the reset button on our board makes Uboot go into LOADER mode, correct? After that commit, it won't show this behavior anymore. If it were a fault in the dtb/dts files, it would be easy to spot the changes in your source code, but I think your DTS file hasn't changed since then at least not with respect to the reset button. So it must be a source code change, presumably in the Uboot source. Can you give me a pointer to the source code where I can take a look and check if there is something I can revert so that we get this reset-and-boot-in-LOADER functionality back. My small pads CLK and GND start to get worn out ... Ouch! @paradigman I spotted errors in my build (e.g. used a 6.6 config for 6.12. and other mishaps), so I'd rather build again and upload later. Thanks for the hint at Cinnamon, will give it a spin!

Nope, it was me that didn't copy the files from your GitHub repository correctly to the Armbian build tree correctly. Rebuilt the whole image yesterday and lo and behold, it works like never before! Even Wifi and Bluetooth. Cool! 😁 Now I only need to find out how I can accelerate mit xfce desktop which is really sluggish ...

Thanks for your many answers @Hqnicolas! I feel, many more questions are coming. Right now I'm struggling with Wifi. I put the files brcmfmac4335-sdio.txt and fw_bcm4335b0_ag.bin which I found in brcm4335_drivers in the root dir in /lib/firmware/brcm and created the following links: brcmfmac4335-sdio.h96-TVbox,rk3566.bin -> fw_bcm4335b0_ag.bin and brcmfmac4335-sdio.h96-TVbox,rk3566.txt -> brcmfmac4335-sdio.txt Now I'm getting this output in kernel messages: [13467.075537] usbcore: deregistering interface driver brcmfmac [13476.449214] brcmfmac: F1 signature read @0x18000000=0x16014335 [13476.453795] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4335-sdio for chip BCM4335/1 [13476.454051] usbcore: registered new interface driver brcmfmac [13476.457822] brcmfmac mmc2:0001:1: Direct firmware load for brcm/brcmfmac4335-sdio.clm_blob failed with error -2 [13479.399014] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout [13479.403176] ieee80211 phy4: brcmf_c_preinit_dcmds: retrieving revision info failed, -110 [13479.403231] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available [13479.403259] brcmfmac: brcmf_c_process_txcap_blob: no txcap_blob available (err=-2) [13479.405299] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4335/1 wl0: May 18 2014 16:56:54 version 6.34.171.58.2 Nowhere can I find files that end with clm_blob or txcap_blob. Also Wifi doesn't start (of course). Do I have the right drivers or what is missing or wrong? BTW, I'm running Armbian 6.12.9 with Ubuntu noble.

oh yeah, that seems to be the chip, an original SK Hynix listed on LCSC website for < $6. Wow! Impressive. Thanks for the datasheet. Hey @Deoptim, you can save a bit, if you buy at LCSC ! Ha! That's why we are with Armbian and not with evil Android anymore, right! 😆 I'm also unsure whether or not we are able to finetune (aka tweak) the timeings and clock frequency of our LPDDR chip. Unfortunately, the ram training blob is proprietary and we don't have any source code for this. So, at the moment, there is not much we can do. Good to know: Today I thought I had bricked my box ... When in "RkDevTool" in Windows and in MASKROM mode I wasn't able to flash any file. I tried to flash the loader only or the Armbian.img and the program always gave an error. I tried the same on Linux with "rkdeveloptool db MinloaderAll.bin". The tool said download successful, but did not enter LOADER mode. It was very good, I had console output and searched the Internet. The latter, however, wasn't very helpful, unfortunately. What I know now is this: Once the tv box enters MASKROM mode, this doesn't mean it runs any loader! Because there is no loader in the CPU. It means, it jumps to an address in the emmc that should contain a loader. If there isn't any or the wrong one or whatever, it refuses to boot and outputs "please reset". So if you want to flash a new Armbian.img file you first need to "download" (in fact it is an upload to the tv box from your PC) a loader (e.g. MiniLoaderAll.bin). Then this loader runs and only now you can use the RkDevTool or RkDevelopTool to "download" an Armbian.img file to emmc via USB. Once the Armbian.img file contents are written to emmc and the tv box restarts, it restarts most likely with a complete different loader, namely, the one that was packaged in the Armbian.img file. The first one you "downloaded" to the tv box in step 2, is no longer active or anywhere in RAM or emmc because it was downloaded to RAM only! So if you want to renew the loader on your tv box, you have to issue these two commands in exactly this order: ./rkdeveloptool db H96-MAX-8gb-MiniLoaderAll.bin ./rkdeveloptool ul H96-MAX-8gb-MiniLoaderAll.bin BTW, flashing this loader is not a good idea because it is appropriate to Android.img only, but it does its job perfectly when it comes to downloading new Images. I hope these explanations help other people when they get stuck during flashing. Other Questions: It is true, that once we flash Armbian on our TV box, we lose the ability to press the reset button and enter LOADER mode. The only way to flash with rkdeveloptool now is to flash via MaskROM mode, correct? This is gruesome in particular because we need to access the CLK and GND pads every time we want to flash and keep the case open if we don't want to solder wires to them. I'm thinking about cutting through the lead from the reset switch to a tiny resistor and solder a wire from one pin of it over to the CLK pad on the other side of the board, but I'm not quite settled for this right now. Is there some other way, to re-flash the whole Armbian IMG file (without having to solder an SD card slot and without LOADER mode)? Fun fact: @Hqnicolas mentioned that those cheap little UART-to-USB converters with CP2102 chips on them are in fact (contrary to popular belief and specification!) capable of operating at 1.5 MBaud and above. Now, that statement holds true for Windows and Windows only! Once you run Linux and tio (name your favorite terminal software), you only get garbage on the screen regardless what you configure or tweak. But how is that? Easy! If you look at the generic Linux source code that is responsible for interfacing with a CP2102-based converter, you see that the software restricts baud rates above 921000! And all you guys thought was you were too stupid to setup a proper configuration under Linux .... No, you aren't, but you can't.

Could anyone read the label of the LPDDR-RAM chip beneath the heatsink. I have the nagging feeling that it's not a 64 GBits (my tv box claims to have 8GB RAM) LPDDR4 chip ... How did I get to this impression? Easy, since there aren't any LPDDR3 chips (at the moment afaik) with 64 Gbits and 1056Mhz the first ones are of type LPDDR4. Second, LPDDR4 with 64 Gbits allows clock rates of at least 1.8Ghz, so why would the dram training routing in the very first loader stop at 1056 Mhz? Third, those chips are around $30 in quantities of 30+. You can't manufacture a tv box that costs $55 with such an expensive component. That doesn't make any sense! So what does the mean? Well, either we can clock this chip higher and we have to test if it's really a 64 Gbit RAM Chip or not.

Oh, that's sad for that guy. I'm sorry, but I can't help him because my board has a RTL8211F ethernet transceiver not a JL2101. 🤷‍♂️

Good to know. Safety first, I gonna try and suck the booloader from my current firmware. Oh wait! You can take any of the bootloaders that are destined to run on any board with a RK3566? Could be and I can test that, but better safe than sorry, so I need to have my current bootloader, reflash it on my device and if it is booting up normally like before, you can test until the eMMC starts to puff away ... 🙂 I think you mean "rkdevtool", correct? I plan to use version 3.19 (latest, I think). Hope that's ok. If I'm not totally mistaken, I saw a button on the page that shows if you click on the "Advanced ..." tab that has a label meaning extract firmware or the like. But you have to provide an address range. I think it has to be from 0x00 to ???. Do you know the upper bound? Absolutely my box is a H96 Max V56, nothing else, rest assured. 🙂 But what is this "LAN problem", why do I need to fix something? I thought Armbian has everything in place, doesn't it? We'll see, we'll see. First things first and after that come experiments. @Hqnicolas many thanks for your answers! They help me a lot. @GBEM Great tutorial! I'm loving it, also helps a lot. All the best to everyone! Keep up the good work! Cheers, Deetsh

Hi everyone, I'm a rather new and proud owner of one of these nice H96 tv boxes and I also got the 8GB version that's why I'm in this thread. Now I want to reflash it with Armbian and I want to thank and congratulate all who made this happen with their knowledge and sweat! First of all, let's talk about the hardware. I cracked open the case and had a look at the PCB. Build quality is good, but nothing to write home about. There is, however, one interesting phenomenon you get to know if you look closer. You can see a rather smallish heat sink atop of the CPU which also covers the RAM chip. Now, if you tilt the board and look from one side to the other, you can see that the RAM chip is, say, 1mm higher than the CPU, which directly translates to the heat sink not fitting snugly to the CPU ... Oh man, who on earth did such a design? Do you know or have encountered any heat problems with your box? Can you tell me about your temperature range you see during operation? When it comes to flashing new firmware I'm kinda burnt child (pun intended!) ... a lot of things can go wrong and if one is not prepared for this case, you can easily brick your phone or your new tv box right away, which in fact isn't the nicest thing you want to experience, to put it mildly. I had a look at the flashing guides in this thread and they all comprise of one step of flashing a pre-loader (aka. H96-MAX-xg-MiniLoaderAll.bin). This is IMHO a very risky operation! So I have a couple of questions: 1) Where did these loaders come from? Did anyone suck them from a tv box or did you find it in an Android firmware distribution? 2) The 4gb and 8gb version are actually different! 4gb version is "DDR Version V1.09 20210630" and 8gb version is "DDR Version V1.06 20210326". I did a string grep on those files. You can't run them interchangeably, right? But why? 3) Why is there a need to flash a new pre-loader? Why can't we use the existing pre-loader that comes with the box itself? 4) Is there a way to save the original pre-loader, so that if anything goes really wrong, it can be flashed back to the box? As we all know chinese tv box assemblers quickly change components without giving any notice. It could happen, but need not, that you flash one of the pre-loaders mentioned above and your box refuses to boot your Linux or Android. What then? So if anybody has some answers, they would be highly appreciated! All the best and keep up the good work! Deetsh