jock
-
Posts
1857 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by jock
-
-
I resume this thread to see if anyone is still interested in this issue: I can provide a minimal testing image to see if some patches may reduce or eliminate the HDMI problem.
Please answer here if there is still interest in this topic
-
Thanks for noticing this, and sorry for being very late on answer. I will check and fix the trip points soon; also there could be room for improvement from stock/vendor based trip points with the granularity provided by devfreq framework for GPU and DMC (read: GPU and DDR can be controlled as well to lower temperature of the board).
-
Sorry for the very late answer, and sorry for not shipping good news, but the last time I checked the datasheets, I also found that no I2S bus is available on the GPIO header, hence no external I2S DAC can be used directly on Orange PI 4 LTS boards
-
-
@ANKH yes that's true what you found, but in mainline kernel there is no such thing like custom drivers for rockchip.
The problem is not the driver, but the communication with the wifi chip itself.
The kernel is not able to communicate the device via SDIO bus, so it is not even able to understand the vendor and device id of the chip.
Your problem is at the very hardware level, so the drivers are not yet involved in your case, and yet I don't understand if I did a mistake setting the GPIO strength values.
-
3 hours ago, LFPoulain said:
It works ! But I have green lines jumping on the screen sometimes
. But it's ok for configuring 
Ok but you should provide some additional info about the display you are using; it could be an HDMI issue (timings, cables, especially with 2K/4K displays) or a box memory issue (unlikely).
I made some cut work against the original libreelec patches, and I really hope that it is not the cause of the issue.
3 hours ago, LFPoulain said:Why is it 6.3 kernel instead of 6.4.7 ? And also 23.08 instead of 23.5 ?
Because the armbian patches have not yet been adapted to 6.4.x; everytime there is a new kernel it is not trivial to fix all the patches to make all the boards and all the wifi chips work, actually it is quite painful and time consuming task, especially for rockchip64 family which covers a huge amount of boards.
Also the armbian version is 23.08 because it is the next august release; the current release is 23.05 (not 23.5)
-
Here it is the experimental minimal image based upon kernel 6.3 with some video patches: https://users.armbian.com/jock/rk3318/Armbian_23.08.0-trunk_Rk3318-box_bookworm_edge_6.3.13_minimal.img.xz
I did not test it at all, but should be sufficient to put it on a sdcard and boot with the sdcard inserted.
-
11 hours ago, LFPoulain said:
Where could I find it ? Is it a specific branch ?
Yes, there is the old branch on my fork: https://github.com/paolosabatino/armbian-build/tree/rockchip64-patch-series , but your mileage may vary, I don't update it anymore.
11 hours ago, LFPoulain said:I have another question in mind, and I am greatly interested in the answer. I use Armbian because the power of these boxes is sufficient, their price is very reasonable, and also because the original Android firmware is riddled with malicious code. I am having a bit of trouble understanding the bootloader that allows the Multitool to start. Is it native to the CPU, or can it be modified by the box manufacturer ? I read that the Armbian image comes with U-Boot. Does this completely replace the original one? And most importantly, can there be malicious code at this level ? Thank you
There are various stages chained together to boot the boards.
The armbian bootloader completely replaces the board bootloader, the only rockchip proprietary thing is the DDR memory initialization, which is the very first step.
All the further steps (U-boot SPL, Trust OS, U-boot and finally the kernel) are binaries compiled from opensource code by armbian scripts during image building.
In the android original image, instead, malicious code can be injected in any of the steps; the Trust OS is the most dangerous piece of code, because it runs with highest security level in a piece of memory even the kernel does not have access to. Whatever code is inside the Trust OS binary, you can't know anything about of what it does.
On armbian images, both Trust OS and U-boot are compiled from the mainline open source code available on github.
-
54 minutes ago, LFPoulain said:
So the board is booting right ? Is there anyway to apply SSH on boot ? I don't need HDMI as I'd like to use the board with docker and portainer
You should try to access via ssh if you have a way to discover the IP address.
Some cases that have been discusses in the past, the board was reactive, just HDMI was not working right
54 minutes ago, LFPoulain said:I'm ok to send you one of the 2 boards to try yourself ! That's seem fair to me with all the work you've done so far
Actually I have to correct myself: I think that the real problem is related to the HDMI timings of the HDMI device and not exactly to the board itself. I don't know if this is exactly your case, but in the past reports people reported that the experimental image based upon a 5.19 kernel with the libreelec patches was working, where other kernels where not working at all.
Perhaps I could give a look into this weekend, and propose a minimal image with some tailored patches to see if they address the issue. This could be useful for other people with Orange Pi 4 LTS board (rk3399) that have lamented the same HDMI issues.
-
3 hours ago, LFPoulain said:
Do you have any idea why this might be happening?
Yes, it seems that recent kernels have some kind of HDMI issue that makes them not displaying anything.
Unfortunately my rk33x8 boards are both working fine with current and edge kernels, so I can't replicate the issue and can't fix it.
Some people reported that there are patches from libreelec project that fix the problem, but as long as I can't try it myself, I can't selectively incorporate them into armbian. I tried in the past to import the whole libreelec patches, which include many fixes and better support, and also did a lot of patch rebasing work, but some maintainers where not happy, so I gave up.
-
@Zacky Travis as already said, no, it is not possible. Also your board may not be able to boot from sdcard at all. Please refer to the support thread about that.
-
This is the support thread for these things: https://forum.armbian.com/topic/12656-csc-armbian-for-rk322x-tv-boxes/
As you already noticed, the board is very new and we've never had any chance to deal with that directly, so it happens that the board does not boot.
However, I will never stress enough the fact that, for reliability and compatibility, it is much better to buy an officially supported SBC: https://www.armbian.com/download/?device_support=Supported
-
-
@ANKH This is the last thing that can be changed, so try this other one and let's hope 🤞
-
No, I won't, and I don't suggest doing that: it will make device tree overlays unusable and will break the installation on next kernel/bootloader update.
-
-
Here come another, I hope this is the last one 🤞
-
@fangis It is not a good idea to cut the stack trace in the middle when you want to do debug. Also put the log in a "spoiler" section to make easier to read the thread.
@mattmar I don't understand the part about the usb adapter: if are you using it to program the sdcard on the PC then it does not matter. If you're using it on the box, then it won't work.
Also I don't understand what does not boot: the multitool or the armbian image?
AIDA is not useful, as usual we need the serial output and photos of the board.
-
12 hours ago, Energokom said:
With a DDR memory frequency of 533 MHz, I have no problems with LAN
Then use 533 Mhz! 🤷♂️
12 hours ago, Energokom said:My idbloader.img does not work with Armbian images (kernel update 5.19.15 and libreelec). But, with your other images, my idbloader.img works.
So I'm trying to ask you, maybe you used DDR_v1.19.bin?
Of course it does not work, as I already said, images don't use the rockchip miniloader but u-boot spl. I know nothing about those "other images" you talk about
And no, the ddrbin is v1.16; I don't even know there is a v1.19 around
-
29 minutes ago, Energokom said:
Tell me what could be the problem? Why do you think the LAN connection leads to a hang-up?
Of course I don't know, perhaps a bad power supply? Perhaps your router/switch is faulty and it is feeding a current back to the board? I can't answer such question.
30 minutes ago, Energokom said:Which version of rk3328_miniloader did you use in your Armbian images (5.19.15 kernel and libreelec patch)? - it work best with my DDR 666MHZ box
I want to understand how these boxes can be made to work at a frequency of DDR 666MHZ
miniloader has nothing to do with ddr frequency and armbian images are not using the miniloader at all. They use u-boot SPL for that boot stage.
About the 666 mhz ddr, I already explained it to you few posts ago.
35 minutes ago, Energokom said:Can the LED control chip affect the operation and cause it to hang?
Who knows? Look, I am not the Oracle of Delphi that has answers to all questions; if you have the doubt, you have to find a way to check it yourself!
After all of this, you did not post not yet any serial log output from the board. I don't have a crystal ball to tell you what's happening on your board 🤷♂️
-
@ANKH Ahhh I see a made a mistake in the last dtbo I sent you.
Please try this other one: rockchip-rk3318-box-led-conf5.dtbo
-
-
8 hours ago, fangis said:
It is indeed very possible to boot from sdcard without touching the internal storage, my sd image does it, and I know some others have done it too. My parents box has their Android intact and they still think android is so much better than linux
It's no secret indeed, but the armbian image has been engineered NOT to work that way on purpose because I did not wanted anything to do with existing old/buggy/limited bootloaders, miniloaders, trusts or whatever...
-
On 7/15/2023 at 6:01 AM, ojogoperdi said:
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!
Armbian already offers ways to customize the final image, it is used by SBC manufacturers to build their own images, for examples.
Don't understand why you should want to customize the boot process though, which is quite delicate thing.
On 7/15/2023 at 6:01 AM, ojogoperdi said: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.
If would be nice, since you got so many of them, if you open the box and make detailed photos of the boards.
And it would be even nicer to have samples of those boards that "don't boot" and those which give no video signal in my lab, since those issues are very niche cases and incredibly difficult to debug without the hardware.
There are a plethora of reasons they could not boot, there are at least 4 different pieces of software chained one after another during the boot, not just the kernel.
On 7/15/2023 at 6:01 AM, ojogoperdi said: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.
The serial adapter is essential to debug.
About the missing boot, as said, it is a very delicate thing and requires good knowledge about each piece in the equation (ddrbin, trust os, miniloader/uboot SPL, uboot, the device trees, the kernel drivers, ...).
You can't just swap the kernel and expect it magically works; and that's one of the reasons armbian exists: to ease the pain to boot SBCs and - as side effect - tv boxes.
On 7/15/2023 at 6:01 AM, ojogoperdi said: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.
Sorry to stress this thing, but never worked there because you did not read carefully the first post. There's a paragraph on booting from sdcard. And did you note you could also boot from USB stick/HDD ?
What are you confused about? Which pass of the step-by-step guide is not clear?
On 7/15/2023 at 6:01 AM, ojogoperdi said: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.
They are the lowest end product available on the market, yet TX9 means nothing. Chinese manufactures give them fantasy names no matter what's inside the box, that's the reason we always talk about the boards, trying to identify them by looking at the signature and markings on the PCB.
OPi 4 LTS - no HDMI output
in Orange Pi 4 LTS
Posted
I prepared an experimental minimal build for Orange Pi 4 LTS with some extra patches that may fix the HDMI issues:
https://users.armbian.com/jock/misc/Armbian_23.08.0-trunk_Orangepi4-lts_bookworm_edge_6.3.13_minimal.img.xz
Please try it and report if possible, thanks!