jock
-
Posts
1847 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by jock
-
-
1 hour ago, RaptorSDS said:
maybe with a hint that after a apt-Upgrade procedure has to renew
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
-
36 minutes ago, RaptorSDS said:
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
The problem with this is that on next bootloader upgrade via apt upgrade, any custom solution will be wiped away and being overwritten by the regular bootloader.
I can reinstate the opensource optee as Trust OS, which seems to be more compatible, but we lose DDR clock scaling - that increases a lot the general performances - and virtual poweroff from the closed source rockchip Trust OS. Which one to choose?
-
@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.
-
it's a bit of choosing among liquid shit, solid shit or dry shit.
-
1 hour ago, Khadas said:
I wanted to write the post just to warn those like me who are happy to see the multitool loaded correctly and want to try the installation on eMMC. In my opinion the card is really of poor quality, all the HDMI VGA adapters in my possession with this card do not work, I was only able to see the screen working with HDMI monitors and this made me decide to send the bricked TV box back.
It is not just your opinion that they are poor quality, it is well known they are poor quality.
You can't expect quality from cheap 20$ chinese boards, whatever manufacturer, brand or version you look for.
-
Hello, I had a feedback from @ilmich and now I'm back with a couple of device trees you can test on the multitool and see if they change something.
I'm not sure they will fix your issue, because it may be necessary to recompile u-boot too and that would cost me a bit more time to setup the whole thing, but in the meantime you can try these two dtbs overwriting rk322x-box.dtb in extlinux folder of the multitool.
Try both of them and tell me if any (or both) do have any effect
-
@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.
-
-
@svdmk what you found is very interesting.
The issues regarding the automatic shutdown after 1 minute are probably related to a piece of closed source blob (the "Trust OS"). Most of the time it never causes issues, but on some systems it looks like it triggers this automatic shutdown or suspend state for unknown reasons.
Normally you don't need to do all this hassle to install armbian, neither there is the necessity for any reboot. It is the combination of the Trust OS and your board that triggers this unexpected behaviour.
Also your board is totally new on this forum, I have never seen such zq01-v1.3 board, if you can please post photos of the board and the original device tree (or the whole firmware, if you can).
So if I understand correctly, you flashed a piece of Armbian 21.02.1 on the eMMC, then you were able to boot armbian 24.2.0 from sdcard and it tooks 20 reboots to finally reach the user creation phase and login, but once you get there, it finally works for and indefinite time and does not reboot/turn off?
-
Nope, they are not useful. To identify the issue I need the serial logs from the board UART when you boot multitool to understand the reason why it does not proceed.
Did you try to burn a second multitool on a USB stick, plug both the sdcard with multitool and USB stick with multitool and see if it boots?
-
-
Hello, which one is your device? And no, MXQ 4K market name does not help at all, you have to open the tvbox and look for the name printed on the board PCB.
What you can do to is:
* downloaded and try the latest multitool
* take photos of the board (both sides)
* provide the output of the serial log for the failing condition
-
2 hours ago, HurlingSand said:
Has anyone ever managed to get SV6158 Wi-Fi chip working?
From the datasheet it seems interesting, but no, never seen such chip and never seen a driver for it
-
@audio kees if your need is just play video at 4k you probably won't go with armbian but rather with libreelec; if your goal is playing music you'd probably want to go with volumio either. Armbian is suited mostly for linux desktop replacement and server-like tasks.
Said so, tv boxes are the worst choice around in any case, especially if you choose among the lowest budget.
Much better if you go with properly supported Single Board Computer (SBC) and, as said, you'd better take a look to what libreelec suggests as preferred hardware (probably Raspberry Pi) if you want/need an out-of-the-box working system.
-
@audio kees Perhaps you can install armbian in eMMC and libreelec from sdcard/USB stick. It will work because armbian bootloader is capable of booting from several devices; altough it is quite strange libreelec bricks your board.
-
@audio kees the eMMC when the board is turned on is 400 KHz (no typo), then when it gets initialized (immediately, in practice) runs at 50 MHz.
The best thing you can do right now is find the TX/RX pins of the debug uart, attach an USB to TTL serial adapter and see what the board is saying during boot and understand why the board is bricked posting here the logs. Bitrate is 115000bps.
About 1T or 2T, it is the DDR Command Rate parameter. If you don't change that, current images have it set to 2T which is more compatible, but some board still don't like it and want 1T. That's exactly the reason I strongly suggest (in the first page tutorials) to first try and boot armbian from sdcard before installing it in eMCP/eMMC.
-
2 hours ago, audio kees said:
Maybe this link is interesting. I can desolder the memory chip, make a connection
to clock and resolder it, (balling) I have the materials for that like solderstation and
mask's.
For God's sake, don't!
You just need to find the eMMC clock pin, gate it to ground when turning on the board and then restore the normal condition right after the board has power. You don't need to do such an invasive procedure!
You said you have an oscilloscope, so then it would be a joke finding the clock pin. AFAIK, the eMMC default clock is 400khz.
More informations are in the first page of this thread, including how to find the clock pin on the NAND/eMMC pads.
I also wonder how did you brick the board. As @fabiobassasuggested, you can also try powering up the board keeping the reset button behind the audio jack pushed for 4/5 seconds and see if you get in maskrom mode.
-
@audio kees did you try to press "Enter" on your keyboard?
-
1 hour ago, audio kees said:
Because I am not such a advanced digital person I do ask you guys what I has to do
with multitool who get,s stuck on license massage open source etc, it will not go further
and bleu led blinks. I have the box in maskrom mode, maybe that is the issue and need
to switch it back.
Hello; I'm not exactly sure I understand... you say you're stuck at the license disclaimer but you managed to get a dmesg log?
-
-
As far as I understand, you used the multitool to install armbian on emmc; so it worked.
H20 boards are lousy, because manufacturers, to keep costs down, removed power regulators from the board; for this reason the CPU can't go over 1.0ghz, but regular armbian images are configured to boot at 1.2ghz so perhaps that is the reason your board does not boot anymore. That's why it is hardly suggested everywhere to follow the procedure and test the armbian image using an sdcard before burning to emmc.
Is the multitool able to boot if inserted into sdcard slot or not? You could do maintenance directly from the multitool because it allows to mount and modify the burned image.
It should be able to boot, otherwise you need to find the serial pads and attach a serial adapter to debug the problem.
-
32 minutes ago, Newest said:
This is first time i'm trying to install Armbian on MXQ PRO 4K 5G(8G+128G). Everything is ok
What do you mean with "everything is ok"? Did you run multitool, erase the emmc and try armbian from sdcard? did you install armbian on emmc?
Also specs are totally fake, your device is 1G + 8G, not sure is a rk322x also.
-
-
On 2/14/2024 at 6:08 PM, plainlethal said:
Its capable of h264 hw encoding?
No.
CSC Armbian for RK3318/RK3328 TV box boards
in Rockchip CPU Boxes
Posted
Yes they are "normal" errors: the brcmfmac driver probes for such firmware files, does not find them and proceeds with other filenames. It just reports what is an information as an error, and also does not report that it finally found a valid firmware file.
brcm4334 chip has no clm_blob binary; AFAIK only newer/bigger broadcom chips have it, but older chips like 4330/4334 don't have and don't need it.