jock

Enables the HS200 mode for the internal eMMC. Normally this is safe, because the kernel asks the eMMC is it is able to work in that mode. I have another board (rk322x) which has a HS200 eMMC and it is able to reach a sequential read speed of 130MB/s! Sometimes the eMMC or the board is not able to keep up, and activating the switch crashes everything. The same applies with emmc-ddr overlay, just that the mode here is DDR, which is yet capable of reaching considerable speeds (> 90MB/s). Note that it is just the bus speed, the eMMC should be of good quality, which is not always the case on tv boxes. edit: about the esp8089 issues, the driver is not yet included into mainline kernels like 5.14

When I toyed around with my S905 mainline u-boot was flawless for me. Of course, as @hexdump says, there are some things that need the proprietary one (like NANDs). But if you have eMMC, I think you won't need that old piece of code.

Yes, this is a very common situation when there is an issue during the boot process: it corrupts the armbianEnv.txt. I faced it dozen of times, unfortunately. There is an armbian service that read and then rewrite the damned file for a reason unknown to me. The kernel dump looks quite "generic". I may guess that I missed to update the led-conf3 dtb in the armbian sources because I was doing on-the-fly changes during the testing. I will do a double check soon, in the meantime just stay stick with 1.1Ghz frequency (I have to fix this too, since the dtb is set for 1.0Ghz....) Try this armbianEnv.txt, it should suits your configuration. You may need to fix the rootdev though: mine is from the Debian bullseye image. verbosity=1 bootlogo=false overlay_prefix=rockchip fdtfile=rockchip/rk3318-box.dtb rootdev=UUID=9c194bed-dcbd-4e24-885d-a8e504b5772b rootfstype=ext4 console=both overlays=rk3318-box-emmc-ddr rk3318-box-emmc-hs200 rk3318-box-led-conf3 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u

Oops, I'm sorry something didn't went well

Mmmh, I was not aware of this issue and have no issues with full-hd devices. I don't know if your particular case has been fixed with newest kernel, I usually import HDMI timing and multimedia patches directly from libreelec so I'm not directly involved into this kind of tweaks. About dvi -> hdmi conversion, maybe you mean the opposite (hdmi tv box -> dvi monitor/tv) ? I may do some tests with the appliances I have around if you say there are issues there.

@MX10.AC2N Discard u-boot package, it is not needed at all, although I don't understand why it complains...

Uhmm... it seems that the headers package is not installed in the images I shipped before. Well, I think I can remove the offending packages from the web directory However it's ok just to install linux-image and linux-dtb packages: those are the important ones. headers are needed if there is the need to compile kernel modules. edit: I changed the installation command with apt, so it will resolve automatically dependencies without complaining...

Good idea, the packages to hold are exactly those ones (plus the headers package). I will double check and add a clarification in the first page, thanks!

Well I was referring to a much less elegant approach, like using the remote and see if the leds are both on at the same time or if they just alternate like it is happening on armbian. Ok, dmesg is always helpful here. Is happening exactly the same as before or got worse? Unfortunately I don't have a board with esp8089 so can't test by myself the behaviour of this chipset, it turned out to be a bit picky

Building right now, will be ready soon edit: ready and available here: https://users.armbian.com/jock/rk322x/

@MX10.AC2N @curse That's true, the only way to update currently is to start from scratch and the reason is exactly the one hiphotesis by @curse is right: since the whole thing is not yet into mainline armbian, upgrading via apt is not possible. Even worse: upgrading via apt will install official armbian packages, and it would just break the installation because it would remove the existing dtbs. I'm going to add the .deb packages in the first page along the pristine images for manual upgrade, in the hope it will not break existing installations

Update! Images on first page have been updated to kernel 5.14.13

Looking into the u-boot source code I found this CONFIG_EFI_PARTITION_ENTRIES_OFF: @pista should be able to displace the GPT partition table away from sector 0 with this. It is configurable within u-boot .config under the Partition Types submenu edit: thinking about... maybe the kernel has to be informed about that displacement too...

@marshall Mmmh, thanks for the detailed summary! It looks to me that the two leds are just attached one the opposite to the other; are you sure in Android the two leds are controlled separately and not just switched as like happens in Armbian? Actually I found two led definitions, but also two other definitions for chips controlling front 7-segment panels: all were enabled in the dtb, but clearly the manufacturers put everything in the pot no matter what the hardware is. Mostly the wifi matters more, this other dtb restores the power gpio to the previous value, but keeps the lower bus speed and higher power gpios, so try this other and let me know... rk322x-led-conf6.dtbo

@hexdump Thanks for the explanation! I tinkered years ago with gxbb... I found amlogic has the same "maskrom mode" similar to rockchip; the first thing I did was erase the flash (that just some months ago I discovered to be NAND ) and then let it boot from sdcard. I heard that the amlogic ROM could also boot from USB, but did never try by myself. I remember the issues about the ddr blob initialization, once I tried one made by Odroid for their C2 board (if I remember well): the ddr blob detected it was not an odroid and refused to boot on my board. I used @TonyMac32 repository https://github.com/Tonymac32/Amlogic-u-boot/tree/master/fip (requires two different older gcc toolchains) to produce the series of ddr blobs that were generic enough and run fine on my board (see https://github.com/paolosabatino/armbian-build/tree/mxq-s905-v20/packages/blobs/meson/mxq-s905-v20 ); then just applied the known blob mangling things that were already in armbian sources and finally could compile a running mainline u-boot. Actually my mxq-s905-v20 repository is a bit abandoned but should compile and produce a working image for S905 tv box with mainline u-boot. I don't know if it boots on eMMC though, since I have NAND I couldn't try. Dunno if this may be helpful somehow, but this was my experience...

@marshall Ok, this is the first attempt. Led configuration looks similar to led-conf5 you were using, but I don't understand why you had problems. Anyway I fixed a minor thing and switched leds. The DTB says there is a red and a blue led: working is now the red led and configured by default to stay always on; auxiliary is the blue led and is configured to react on access to internal flash. dtb may tell the wrong labels by the way. About wifi, I followed the original dtb, swapped some ACTIVE_LOW <-> ACTIVE_HIGH gpios and brought more power to them, reduced bus frequency to 37.5Mhz. I hope that now it works! Put the file in /boot/dtb/overlays directory and change led-conf5 with led-conf6 in /boot/armbianEnv.txt rk322x-led-conf6.dtbo

@paradigman I don't what to say, that's just a problem that has been rarely seen before and I don't have such a problematic board to investigate further. I see that your board has "R29-MXQ" marking, but we have only seen "R28-MXQ" which is indeed different. I may suggest you, if you didn't already, to try an image with the mainline kernel.

@marshall Thanks for the 32 bytes of the image, but actually I meant the first 32 megabytes eheheh . No problem however, I managed to extract the original dtb from the tvbox image. I took a look into and yes, there is the need to adjust the secondary led and something seems to be a bit different for wifi too. I will craft a special overlay so you can test the whole thing.

Sorry for breaking into discussion, but I'm puzzled about u-boot chainloading. What problem does it solve?

Of course, fell free to try and report

Yes thanks, indeed the original firmware will be very useful! Actually I just need the original device tree overlay, but if you're not able to extract it by yourself, just post the first 32 megabytes of the original firmware and they will suffice. Most surely the led problem on the second board is a misconfiguration: that's something I can adjust taking a look into the dtb. esp8089 driver and firmware are already into the package, but it is very probable that your board has a particular gpio configuration to let it work, and the dtb can reveal that to us. Curious is the fact that it is randomly detected: maybe you can check if the device is correctly detected after warm reboots and not detected after cold reboots, or things like that. Any hint of this kind (plus some dmesg) are helpful with such situations. By the way, I see a big 26MHz crystal near the esp8089 on the board, so surely the .conf file has to be set accordingly.

@MX10.AC2N Great, happy that we're very close to the solution To get 1.3Ghz, just add rk3318-box-cpu-hs overlay. If I read the dtb correctly, also the wifi is attached to the extra sdio bus on your board, so you'd better add rk3318-box-wlan-ext overlay too! Reboot and you should get these two other things. BTW: you can also use rk3318-config to do all the necessary overlay configuration with the comfy menu interface. Just need to manually edit armbianEnv.txt before rebooting and set rk3318-box-led-conf3 in place of any other led-conf (there must be only one led-conf overlay). In the next update I will add the led-conf3 to rk3318-config so coming people with boxes like yours will find the recipe ready-made

@MX10.AC2N Thanks for the dmesg log and the whole diagnostic Despite I said the previous dtbo was the latest for today, here I propose another one. I spotted a subtle error in the dtb that I fixed: I was too zealant to give a voltage to the ddr regulator, while documentation says I should not do that. Install this other dtbo whenever you want, reboot and please post again diagnostics. I will check dmesg for any residual errors. I hope this is the last time. I don't know what's wrong with armbian-config. You may try to update it with apt install armbian-config and see if the error disappears, but from what I read you already updated packages. It could however be a side effect of the slightly wrong dtb, so maybe try again with this other one and then try again to change the governor. rockchip-rk3318-box-led-conf3.dtbo

@MX10.AC2N Here it is another attempt, last one for today I rewrote the overlay and double checked anything I could simulate on my board. If the system boots, please send back a dmesg log! rockchip-rk3318-box-led-conf3.dtbo

@MX10.AC2N Hmm, would try with this other dtbo? rockchip-rk3318-box-led-conf3.dtbo