fabiobassa

I sent them a message, even sent an email and a whatsapp to the manufacture ( junuo ? hehe) , will see if I get a reply, google sadly doesn't help as seems it's the latest version of the board (v3.0), I really want to make this wifi work 😂 

The thing about SBC is that I already have one, the thing is that I spent some good time searching for a chip that would have multiple usb hosts instead of just one, and that's not easy to find, specially not below 50 euros, I came across the rk3228, that somehow is available at those tv boxes :(.

@Blyato From dmesg I see the wifi chip is just turned off:
 
[ 1.716294] mmc1: Failed to initialize a non-removable card  
I'm pretty confident that the issue is related to the GPIO power pin of the wifi chip being incorrectly set.
You mentioned you are using led-conf7, which is the right device tree for R29 boards, but it seems that your board is a different version/revision and requires some adjustment.
 
To do such adjustment, I definitely need the device tree or the backup of the stock android.
 
A possibility is to try other led-conf options and see if the wifi chip is at least recognized, but I don't suggest to do so because led-conf7 is vital for the stability of the R29 boards: without it, your board will probably be unable to boot at all.

BCM433x are normally good supported , do have rk322x-config and setup the right led config its help also with wifi enable signal
 

@fabiobassa@jock

 

@Socram Hello, it's definitely an rk322x. Despite the kernel is the same for rk322x and rk3288, the socs are profoundly different and so are the device trees. An image for rk322x would not boot on rk3288 and viceversa.
 
Anyway, you should run rk322x-config and use the appropriate led-conf for your board. AFAIR you should have two options: led-conf8 for h20 boards with two voltage regulators (better, looking at the board photos this should fit) and led-conf7 with r29/r2b/h20 boards with single voltage regulator (worse but more compatible).
 
You may go with led-conf8 first, see if it is stable under load. If not, go with led-conf7. Both the configs should make HDMI work

You're right! It's a RK3288. I thought it was a RK3228A because that's what the vendor advertised.
 
I realized the thing was actually replying to pings, removed the MicroSD, chrooted into the machine and created an user and enabled ssh, connected to it and sure enough:
[ 9.831684] rk3288-crypto 100a0000.cypto-controller: will run requests pump with realtime priority [ 9.831930] rk3288-crypto 100a0000.cypto-controller: Register ecb(aes) as ecb-aes-rk [ 9.832042] rk3288-crypto 100a0000.cypto-controller: Register cbc(aes) as cbc-aes-rk [ 9.832082] rk3288-crypto 100a0000.cypto-controller: Register ecb(des) as ecb-des-rk [ 9.832112] rk3288-crypto 100a0000.cypto-controller: Register cbc(des) as cbc-des-rk [ 9.832139] rk3288-crypto 100a0000.cypto-controller: Register ecb(des3_ede) as ecb-des3-ede-rk [ 9.832170] rk3288-crypto 100a0000.cypto-controller: Register cbc(des3_ede) as cbc-des3-ede-rk [ 9.832199] rk3288-crypto 100a0000.cypto-controller: Register sha1 as rk-sha1 [ 9.832232] rk3288-crypto 100a0000.cypto-controller: Register sha256 as rk-sha256 [ 9.832261] rk3288-crypto 100a0000.cypto-controller: Register md5 as rk-md5 I do see RK3288 references. Thanks for the tip!
armbian-hardware-monitor.zip
 
EDIT: No, I think this is actually a RK3229 based on the DTS. I also opened the device and, while I cannot read the specific part number because it is hidden under the heatsink, it's a plastic IC so it cannot be a RK3288 which was sold in a metal BGA package.
 
An except from the multitool dmesg log regarding the DRM:
[ 2.648953] [drm] Initialized drm 1.1.0 20060810 [ 2.656047] [drm] Rockchip DRM driver version: v1.0.1 [ 2.661464] rockchip-drm display-subsystem: devfreq is not set [ 2.668188] rockchip-drm display-subsystem: bound 20050000.vop (ops 0xb0d05b78) [ 2.676005] i2c i2c-0: of_i2c: modalias failure on /hdmi@200a0000/ports [ 2.682689] dwhdmi-rockchip 200a0000.hdmi: registered DesignWare HDMI I2C bus driver [ 2.690553] dwhdmi-rockchip 200a0000.hdmi: Detected HDMI TX controller v2.01a with HDCP (inno_dw_hdmi_phy) [ 2.701808] rockchip-drm display-subsystem: bound 200a0000.hdmi (ops 0xb0cfe0d8) [ 2.709310] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 2.715950] [drm] No driver support for vblank timestamp query. [ 2.722040] rockchip-drm display-subsystem: failed to parse display resources [ 3.353464] rockchip-vop 20050000.vop: [drm:vop_crtc_enable] Update mode to 1920x1080p60, type: 11 [ 3.354145] dwhdmi-rockchip 200a0000.hdmi: HDMI infoframe: Auxiliary Video Information (AVI), version 2, length 13 [ 3.354154] dwhdmi-rockchip 200a0000.hdmi: colorspace: RGB [ 3.354161] dwhdmi-rockchip 200a0000.hdmi: scan mode: Underscan [ 3.354168] dwhdmi-rockchip 200a0000.hdmi: colorimetry: No Data [ 3.354174] dwhdmi-rockchip 200a0000.hdmi: picture aspect: 16:9 [ 3.354181] dwhdmi-rockchip 200a0000.hdmi: active aspect: Same as Picture [ 3.354188] dwhdmi-rockchip 200a0000.hdmi: itc: IT Content [ 3.354194] dwhdmi-rockchip 200a0000.hdmi: extended colorimetry: xvYCC 601 [ 3.354202] dwhdmi-rockchip 200a0000.hdmi: quantization range: Full [ 3.354209] dwhdmi-rockchip 200a0000.hdmi: nups: Unknown Non-uniform Scaling [ 3.354216] dwhdmi-rockchip 200a0000.hdmi: video code: 16 [ 3.354223] dwhdmi-rockchip 200a0000.hdmi: ycc quantization range: Full [ 3.354230] dwhdmi-rockchip 200a0000.hdmi: hdmi content type: Graphics [ 3.354236] dwhdmi-rockchip 200a0000.hdmi: pixel repeat: 0 [ 3.354245] dwhdmi-rockchip 200a0000.hdmi: bar top 0, bottom 0, left 0, right 0 [ 3.430974] Console: switching to colour frame buffer device 240x67 [ 3.598766] rockchip-drm display-subsystem: fb0: frame buffer device In the case of the latest version of Armbian:
[ 1.557514] inno-hdmi-phy 12030000.hdmi-phy: error -ENXIO: IRQ index 0 not found [ 1.558040] inno-hdmi-phy 12030000.hdmi-phy: phy_flag is: 0 [ 1.560579] rockchip-drm display-subsystem: bound 20050000.vop (ops 0xb1179c70) [ 1.560740] dwhdmi-rockchip 200a0000.hdmi: supply avdd-0v9 not found, using dummy regulator [ 1.561045] dwhdmi-rockchip 200a0000.hdmi: supply avdd-1v8 not found, using dummy regulator [ 1.561515] dwhdmi-rockchip 200a0000.hdmi: Detected HDMI TX controller v2.01a with HDCP (inno_dw_hdmi_phy2) [ 1.563057] dwhdmi-rockchip 200a0000.hdmi: registered DesignWare HDMI I2C bus driver [ 1.563492] rockchip-drm display-subsystem: bound 200a0000.hdmi (ops 0xb117d958) [ 1.564699] [drm] Initialized rockchip 1.0.0 20140818 for display-subsystem on minor 0 [ 1.564912] rockchip-drm display-subsystem: [drm] Cannot find any crtc or sizes [ 1.565125] rockchip-drm display-subsystem: [drm] Cannot find any crtc or sizes Seems it is unable to find the CRTC?
device-dtb-and-dts.zip multitool-dmesg.zip
 
EDIT 2: I can guarantee 100% this is a RK3228. Reading the eFuses:
root@multitool:~# cat /sys/bus/nvmem/devices/rockchip-efuse0/nvmem | od -tx1 -An 52 4b 23 82 81 f0 70 55 52 4b 58 32 32 30 33 33 00 00 00 00 0c 0e 26 05 00 04 01 00 00 78 00 00 Note bytes 0x02 and 0x03 are 0x23 0x82, which indicate a RK3228

this looking not as rk322x , i thing thats another main chip like rk328x or newer  , we see some box that boot multitool without rk322x
 

@primoitt thanks for those Infos, even if not strictly hardware related , they are usefull for building new distros
 
Could be also interesting open a specific thread related ti repositories issues and leave this for hardware specific

@primoitt thanks for those Infos, even if not strictly hardware related , they are usefull for building new distros
 
Could be also interesting open a specific thread related ti repositories issues and leave this for hardware specific

So VY 73 and Grazie, de LZ4TU  taaa ti ti taaa
*Excuse me for the offtopic but could not resist, for those not knowing Morse code and are not HAMs each CW QSO finish with TU, on morse: _  .._ meaning Thank You!
Good team here: @jock, @ilmich, @fabiobassa and so much great contributors, ofcourse the leading @Igor , Thanks again, wish you all good luck!

@suser
your avatar is a smith cart about impedence, I suppose.. Italian HAM here

This make me think that you have the right approach to problem : WHY IS NOT WORKING !!!
And not the simple " ok it will work in othe manner" but " what hell is going now"
 
This is the spirit that animated @jock @ilmich and myself when we approached to rk322x world

Unfortunately lack of documentation = trial and errors and understand code and compilation !! And again unsuccess and again trial and errors. Even actually the evil nand driver is ONLY proprietary, even if jock and ilmich actively searching for months a workaround

Welcome in the club 😅
 

I have few USB dongles working, bough for 1.5EU each, it was not a matter of money, nor WiFi desperately needed. It's was a matter of "make things working" or at least "to know why it is not working". Thanks everybody here, you are such a talents !

@suser 8723 are pain in the a**
On other boards we have had even 8723cs but ONLY working with 8723bs driver.
And many other strange combinations 
My suggestion :
IF wifi strictly needed buy a few dollars external USB wifi dongle.
ask here which are the best supported

Please can you be more clear did armbian boot befor without hdmi but with wifi ?
or only android had wifi ?
 
did you have a bootlog or dmesg with
dmesg | grep 8723 or
dmesg | sdio ; maybe dmesg | grep - i 8723
 
 
if this is positiv than only a driver issue , else also DTS/DTB maybe dont activate the wifi sdio

@moddien Why did you try to burn the image in the eMMC without being sure it would have worked?
If you can boot multitool again, clean the eMMC and start fresh.
 
I have prepared an armbian bookworm image with opensource optee in place of the proprietary one, you can download from here; I have not tested it at all, so can't guarantee it works.
If you want to try it, first clean the eMMC with multitool and then try to run the image from an sdcard to see the outcome.
 
 

Two same boards but different cpu.
Rockchip labeled works fine with armbian, multitool and libreelec.
The board with huawei labeled cpu has the previously described problem, multitool and armbian stop working after a minute.
Method of switching bootloaders suggested by @jock  works.

I have successfully booted the  Armbian_community_24.5.0-trunk.93_Rk322x-box_bookworm_current_6.6.18_minimal.img on my new MXQ PRO 4k rk3229, first I use the MultiTool to flash the armbian to internal storage (if it doesn't find the internal storage reboot the device in the menu), then download the LibreELEC-RK322X.arm-11.0-nightly-20240218-d7324fb-rk322x.img and flashed to an sd card, I booted on this sdcard and use the SSH to copy the rk322x-box.dtb to the internal storage, then it boots just fine, here is the .dtb file I use rk322x-box.dtb

You are so right.
 
What a surprise when I removed the heatsink!
 Probably that's why this board has trouble during booting process.

Nope, because this is a very specific problem of tvboxes; regular single board computer users and maintainers don't have to mess with such unknown variables.
That is the main reason why tv boxes, along the funny and always changing hardware they carry, are not and will never be officially supported by armbian, but just by community members.

It looks to me way too complex from the maintenance point of view: users may create unwanted mixtures installing things from the multitool over already installed systems (for example 24.02 bootloader on an older armbian release); and also when armbian advances I have to keep the multitool binaries updated as well. It is already very tiring keeping the thing aligned against mainline kernel on every release I don't want to add another burden.
 
One thing that solves all the boot problems is to reintroduce the OPTEE trust os: it surely does not unwanted things in the background, but then we lose some useful features.
Otherwise I would keep the "manual" procedure for the time being for the problematic boards, until I get the hands on one of them and can study the issue with detail, or some bright idea pops out.
 
 

@Tiago Nogueira

You asked an info, but let me make a question to you:

did you read the whole thread ???

Or just you came in with this question " never made before" ? 😅

It is not possible unfortunately. The bootloader is built and packaged by armbian scripts, it is not supposed to have two different boot loaders for the same "board".
Once the deb package with the bootloader is downloaded, it is unpacked and a script is run to upgrade it.
The only thing I may think about is a flag somewhere on the filesystem that is checked by the script and avoids the real bootloader upgrade.
 
Or people can manually do apt-mark hold linux-u-boot-rk322x-box-current to avoid the bootloader upgrade and that's it

When we now see thats is a moreover need part maybe it is also a good idea to integrate a point in Multitool where a this 2MB part is flash to emmc or nand to replace the bootloader from normal Armbian image

@svdmk ok so that gpio-poweroff is a leftover or some copy/paste from another board done by the manufacturer.
 
The more I read the more I think it is related with the trust os: when you leave the first 8192 sectors from armbian 21.02.1 on the eMMC, you actually leave all the boot pieces there. The boot process is made of 4 pieces: ddrbin, u-boot SPL, Trust Os and u-boot.
Rockchip devices always boot from eMMC first, so whatever you put in the sdcard, the boot process always happens in the eMMC, then u-boot steers to the sdcard.
 
My best guess for your problem is that armbian 21.02.1 bootloader still had OPTEE opensource Trust OS I was using in the past (see here for source code); it is the same base that also rockchip uses for its Trust OS, but rockchip proprietary trust os has some closed-source code that is added on top for added features like DDR clock scaling and virtual poweroff and who knows what else... Nowadays I use the rockchip proprietary optee for those added features, but very seldom it causes issues like yours and it is impossible to debug because it is closed source.
 
What you can do in the meantime, hoping it works
install armbian 24.02 on the emmc via multitool using the regular burn to image function then get a shell and do a dd to copy the bootloader from armbian 21.02.1 image over the 24.02 u-boot and Trust Os are "packaged together". The package starts at sector 0x200 AFAIR and is around one megabyte large, but I suggest to you to copy all the bootloader that starts at 0x20
 
A command like this would do the trick: (of course change armbian21.img with the actual image)
dd if=armbian21.img of=/dev/mmcblk2 skip=32 seek=32 count=8160 sync  
Or, if you have the .xz compressed image:
xz -c -d -k armbian21.img.xz | dd of=/dev/mmcblk2 skip=32 seek=32 count=8160 sync  
Then you should be able to boot multitool, libreelec and armbian from sdcard and also armbian should boot from eMMC without issues.
I will have some confrontation with @fabiobassa and @ilmich to see if there is a viable general solution.

@svdmk Thanks for posting the photos and the firmware!
I took a look to the device tree and found something that could be somehow intersting. I'm not absolutely sure it may be related to your issue, but there the device tree contains this gpio switch which is not usual:
 
gpio_poweroff { compatible = "gpio-poweroff"; gpios = <0xb3 0x11 0x01>; status = "okay"; }; it maps to gpio3 bank and pin 17 (PC1, in the rockchip documentation). That string says that the pin is active low, it means that when it is 0, the poweroff is active; when it is 1 the poweroff is inactive.
 
I may assume that gpio pin is used by the operating system to power off the system.
On other board that pin is not mapped in the device tree, so I may also assume it is not used anywhere.
In your case may (or may not) be related to the weird behaviour you're experiencing.
 
With this command (to be run as root), you can see how the pins is configured. In my case, the pin is set to output at 0 level, but since it is not wired on my board it just does not do anything. Could you please execute the same command on your board?
# grep 'gpio3-17' /sys/kernel/debug/pinctrl/pinctrl-rockchip-pinctrl/pinconf-pins pin 113 (gpio3-17): input bias pull down (1 ohms), output drive strength (8 mA), pin output (0 level)  
You can also control that pin:
# cd /sys/class/gpio # echo 113 > export # cd gpio113 # cat direction in # cat value 0 # echo out > direction # cat direction out # echo 1 > value # cat value 1 # echo 0 > value # cat value 0  
with echo 113 > export you will make the pin available for userspace, then a directory gpio113 will spawn and you can echo to direction and value to change the pin as input or output and switch levels.
If the pin is actually wired to something, it may be that when you switch direction of level the board may suddenly turn off.
 
Now you can also do another test: erase the emmc and verify you still have the shutdown issue. If that is the case, it may be interesting to see what is the pin state in that condition and if switching its condition causes the weird behaviour to stop or does not change anything.