jock
-
Posts
2077 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by jock
-
-
17 minutes ago, mkultra said:
making a bit of progress lol
It goes into 'mask mode' without shorting anything.....just toothpick and diy bodged male to male USB cable in the USB2 port
Bus 005 Device 008: ID 2207:320c Fuzhou Rockchip Electronics Company RK3328 in Mask ROM mode
BUT when I try and flash I get an error that I can't solve at the mo
sudo ./flash_tool.sh -c rk3328 -p system -i image/image.zip
PARTITIONS OFFSET: 0 sectors.
The device does not support this operation!
That is not maskrom mode, lsusb is telling you a wrong information.
You are in rockusb mode, which is provided by u-boot and allows limited operation.
To enter maskrom mode from rockusb mode, you need to get rkdeveloptool from rockchip github repository and run rkdeveloptool rd 3
-
45 minutes ago, RetroFan90 said:
so it appears that the rk3318/rk3328 are more or less the same so it is a possibility to get lakka / libreelec to work
use the os image with the trust file and correct dtb file and it should work pretty normal, but there needs to be more digging into the rk3318 trm and datasheet
does anyone anywhere have the technical reference manual in its entirety?
all i can find is the datasheet....
I don't have the entire TRD of rk3318/rk3328, just the partial one available on rockchip official opensource page.
-
4 hours ago, Maker39 said:
Hello Jock !
I need to connect i2c-tiny-usb. As far as I understand, this requires an appropriate kernel module.
modprobe i2c-tiny-usb responds :
modprobe: FATAL: Module i2c-tiny-usb not found in directory /lib/modules/4.4.194
Do I need to rebuild the firmware myself with the necessary modules or is there some one already compiled?
Hello @Maker39
since the module is not shipped with the image, you need to compile the module yourself.
There is no need to rebuild the whole kernel and all the modules, but you may want to install the kernel headers to compile the module alone.
-
1 hour ago, curse said:
And perhaps try with different SD cards. I first used some expensive recommended 64GB SanDisk card and nothing worked then I tried a "no-name" cheap 8GB card and it worked perfectly. I think it's up to luck when it comes to the SD cards. The recommended expensive cards might work more often than the cheap ones, but sometimes it's the other way around.
Well, since the sd controller on his board is swapped I don't think it will ever work.
But sometimes is true, more expensive cards are not always better.
-
7 minutes ago, chinhhut said:
@jockI've tried but not success, may be I'm not lucky man :D.
By the way, is there a way to restore the backup.gz from multitool to new box using "rkdeveloptool wl 0X0 yourimage.img" command? I mean change yourimage.img file with backup.gz.
Maybe with another USB stick or drive it may work. Also consider to use all the USB ports of the board, since they are not all the same. u-boot is picky.
About the backup, indeed you can burn the multitool backup with rkdeveloptool. You just need to decompress it first.
-
1 hour ago, paradigman said:
I tried that libreelec picture and i don't see any change, still no picture on HDMI.
Now I can't to attach a UART log either because my interface is not capable of 1.5 Mbps.
Don’t worry, I have the patience to tests, I’ve been dealing with this for almost a year.
Now the main problem is the non-functioning HDMI, followed by eMCP and finally Ethernet, Wi-Fi and analog audio. LEDs can be lit from me in any way. That will be a bonus if the IR will work.Ok, so apparently there is something wrong with libreelec HDMI patches for legacy kernel.
Now you can proceed with the instructions I gave and try an image with the mainline kernel.
In the meantime I will remove the HDMI patches from the legacy kernel image and make an experimental image so you can test it.
edit: here there is a debian bullseye minimal image with legacy 4.4 kernel and HDMI patches removed. I only kept the fixes for HDMI audio. Take a chance to try it and let me know if something changes for you.
-
On 11/2/2021 at 12:16 PM, paradigman said:
Unfortunately, I couldn't back up the box's own firmware, but I found another firmware that also works well. I attached the first 32 MB of this.
R29_MXQ_LP3_V2.3_firmware_part
@jock: thank you if you look into.
Yes, I'm looking into.
I read your previous messages and as far as I remember you have
twothree problems:- HDMI is not working
- eMCP flash is not working
- only one led is working
The first two are unexpected problems. If I remember correctly @marshall also had an eMCP board. He had a problem with SDIO, but eMCP flash is working fine.
You instead have a problem with eMCP flash, which is pretty unusual, strange and worse.
Could you please try this libreelec image and tell me if you see anything on HDMI? Armbian uses the same libreelec HDMI timing patches, thus we could discover if the problem may be related to those patches. You can just burn the image and sdcard, plug it in and ti should boot. If possible, please post dmesg output you get over serial too (don't remember if baud rate is 1.5Mbps or 115Kbps)
About the development process on testing armbian images, there are some things that I want to make clear:
- we need to do several tests, it may be a slow process and results are not guaranteed
- you should already be able to put Android back on the board with rockchip tools in case you want to go back
- accept the very remote risk to brick the board
The plan is to first erase completely the internal eMCP flash, either using rkdeveloptool for linux of the rkdevtool for windows. For the former tool, instructions are in the paragraph Erase the flash memory in the first page of the thread.
Once flash is erased, the board always boots from sdcard. sdcard is far easier to use for testing.
First of all, try both the legacy 4.4 and current 5.10 kernels and see if results are the same. dmesg log is always appreciated, even better is to paste the link produced by armbianmonitor -u
Images can be downloaded from armbian download page, just use a suitable burner tool like balena.etcher or whatever you prefer to burn the image on the sdcard.
This are two overlays to use for your board. They should provide at least working leds, hopefully the eMCP flash should work too.
This overlay rk322x-led-conf7.dtbo is for legacy 4.4 kernel.
This other overlay rk322x-led-conf7.dtbo is for mainline 5.10 kernel.
Use one or the other In dependency of which kernel are you testing.
The overlay must be put in /boot/dtb/overlay directory of armbian installation and must be activated adding a line overlays=led-conf7 in /boot/armbianEnv.txt file.
You should be able to do that with no hassle directly on the sdcard.
I hope this fixes led and eMCP flash problems. It is improbable that anything changes with HDMI. For that problem I need to know if the libreelec image is working right for you or it isn't.
-
8 hours ago, chinhhut said:
After booting from eMMC successfully, I try to boot from SD card again to try the multitool but not success. At current, my box still only can boot from eMMC.
That's true, because the sdcard controller is not where u-boot and kernel are told by device tree to look for.
Adapting the device tree for the kernel is easy, but u-boot dtb requires a recompilation.
When armbian is installed, u-boot is totally responsible for the boot process. It scans the devices to find a valid bootable system and the order is first sdcard, then USB and finally internal eMMC.
If you have a lucky USB stick, you could try to put the Multitool on a USB stick and see if boots from there. I say "lucky USB stick" because u-boot USB code is buggy and does not always work.
All kind of regular images (armbian, multitool, libreelec if available too...) can be burnt on USB stick or USB external hard drive: u-boot should prefer booting from there (if the buggy code doesn't kick in).
-
Hello, yes I think you're right about the chip: it is not recognized at all by the brcmfmac driver.
It seems to be a variant of bcm4334 and not yet in the brcmfmac table.
Not sure if adding it will just let the driver recognize and work, it depends on what is so much different that requires a new chip variant.
About compiling the module, I'm not sure sure if you already can, because there is the need for kernel headers of your specific kernel version that are not included into regular images.
You may try and take a look in this directory: https://users.armbian.com/jock/rk3318/upgrade/ and install just the kernel headers package.
I don't remember if the packages there are already up to date with the latest published image.
In case they are not, we need a new kernel and new kernel headers package I can provide for you.
-
Hello,
did you run rk3318-config?
Without logs I can't help.
Pictures are broken though.
-
-
30 minutes ago, curse said:
Did you try multitool? Oh, now when I think of it. Didn't we had to press the "reset button" while plugging in the power, the first time? Toothpick in the headphone jack. Or it might have been my other box.
Normally no, you don't need to push the reset button to boot the multitool.
But I totally forgot about the reset button: stock u-boot will put itself in "rockusb" mode, which is a sort of maintenance mode.
@chinhhut may connect the USB OTG port of the box to a computer (usually with a male-to-male cable). The box will show up in lsusb as in "maskrom mode".
More instructions will follow later...
-
2 hours ago, chinhhut said:
So according to your hint, there should be a solution to install the customized u-boot to the Android firmware then try to boot from USB port, right?
If so, could you give me the suggestion to do? I have some experience with ADB and some Linux/shell command like dd to extract/replace the bootloader before.
Thank you.
Well, the problem about the alternative controller is guesswork. Can't be sure that it is your issue. I have no such board to test and verify if the boot process with an adapted u-boot would work.
The only thing that can be done right now with the tools we have is to wipe the first megabyte of the eMMC via adb using dd and then use rkdeveloptool to burn an armbian image directly on the eMMC.
Yet the original dtb of the board and the serial logs would help a lot to identify the real issue.
-
I agree with @fabiobassa: there is an attitude problem here, and your frustration is clear.
I'm not happy about your work being late, but that's not my fault, nor a fault of the Armbian project.
If you were in the nearby I would you offer a beer and try to find a solution about your problem, but I guess you're not in the neighborhood.
The only thing I can suggest you right now, is to find an officially supported board from Armbian here and pursue your business project forgetting tv boxes. -
@chinhhut
ProbablyPerhaps your h96 max is unable to boot from sdcard because the sdcard is allocated to the "alternative" controller. Much more important than the box name is the board name/signature though.From what I have seen on the forums, this breaks any kind of sdcard boot or update. I guess it is just not supposed that the tvbox manufacturers use this alternative controller for sdcard, so there is the need to find an alternative solution to boot, which I'm not yet aware of.
USB boot is available only if u-boot from armbian image is installed in the eMMC. The stock u-boot does not care about USB devices.
This is the most serious issue that is preventing me to ask to merge rk3318/rk3328 tvbox support in main Armbian source code.
-
46 minutes ago, paradigman said:
@jock: I’m not unethical, at most outspoken. I believe that 20+ years in the profession entitle me to judge certain projects and I've spent hundreds of hours with it.
Here I see the armbian team heroically struggling with time and lack of capacity (and money) while keeping the most important info that the tools of reverse engineering need for themselves.This demonstrates that you know very little about Armbian. Official support is granted for boards which have official specs and whose manufacturers provide datasheets. Hopefully those manufacturers also provide fundings, sponsorship or any kind of support. There is no reverse engineering with officially supported boards: manufacturers provide specs, in form of openly available electrical diagrams and general documentation.
Tv boxes don't provide any datasheet about board specs, often chinese manufacturers even provide fake specs to buyers to sell their crap. They definitely does not sponsor the project in any form, thus Armbian does not endorse any tv box, nor do I: you need something for a serious project? Buy serious hardware, not chinese cheap and unsupported crap.
53 minutes ago, paradigman said:"Want to do everything by yourself? You can." No, I can't. The "docs.armbian.com" is all about building images, changing some parameters, and running a script. You are also well aware that when a new pcb comes out it is too little.
If you think Armbian purpose is to tell you how to understand boards and their chips, understand datasheets, write proper device trees, configure and compile the linux kernel, and whatever it requires to properly support a board, you're out of context.
I spent time doing all of these things above, so everyone else can do that. If you don't have enough skills to do that, that's not a fault of the project. You can still build up those skills, if you have enough time and will to sacrifice for the purpose.
58 minutes ago, paradigman said:"Want to talk about business?"
I have no objection to paying for it. In fact, it would even be good if there were different payment options posted in this forum for different support needs. Perhaps this would immediately solve the ongoing funding problems of this community.There is a donation and help providing page, not just money, but whatever people can do is appreciated, even writing documentation.
Plus the community does not need to be funded with money, it is funded by will of people who wants to do something useful for others.
Armbian is not a company that does things on people request and I don't think you can "hire" someone from inside the project for your particular needs.
But again I repeat: you can still contact and pay developers - ANY developer, not necessarily an Armbian developer - for your needs.
-
3 hours ago, paradigman said:
I just want to point out that the slightly neglected (side-handled) RK3228A CPU is equipped with TV boxes sold on Aliexpress for approx. 75%. If that’s not a big deal, I’d like to ask you to pay a little more attention to this, because there’s a growing deficit between the boxes that are commonly used here successfully (or officially supported by the Armian) and the specimens that occur in real life. As I indicated earlier, there is a new series of inserts starting with "R29". It would be important to me because I would buy hundreds of such boxes for business purposes, but slowly for a year I have been unable to find one on which the armbian would run flawlessly and the price would be right.
I am a software developer and would love to cut into making custom armbian images, but the documentation found here is unsuitable for learning the operation.Sorry but I have to be sincere about this: I don't like the reasoning, I found it unethical.
Believe it or not, I don't receive any kind of money from anyone; Armbian team also does not receive anything from these no-name boards, instead has to pay electricity, bandwidth to host images and forums.
It is just courtesy of Armbian guys if all of this is possible, they ask nothing in charge; although Armbian does not officially support any TV Box - as clearly and boldly stated in the first posts of all my threads.
My role in all of this is just driven by passion and learning, not money. I decided to share my work and studies with others because I think that if other people does the same, the world will become a better and funnier place.
As you see, the learning curve is pretty steep, and trying to build an out-of-the-box working solution for boards whose specifications and datasheets are kept secret is a huge time wasting job.
What I expect in change is usually a "Thank you": most of the time it suffices.
Here I read, and I really hope I misunderstood the post, that someone is going to make business around this.
That's pretty ok to me: I do support tv boxes for passion. I also use Linux which is free and made by others for passion and work and I pay nothing to anyone; nonetheless I contribute to opensource the way I can.
Now if your concern is missed support, don't ask community what can do for you and point out what community is not doing for your business; start thinking about what you can do for community that helps both community and your business.
In all of this long thread I don't know how many people donated to Armbian project - I'm not part of the official team.
But I'm totally sure that, except for the very generous board donations from @fabiobassa to whom all people here should as well be very grateful, I never ever received a penny or one board from anyone. And note that I don't ask boards as gratification - I already have several of them taking dust - but to study them. Nonetheless I am still here available for free support and for fun.
Asking me, or anyone else, to spend money to buy cheap crap and spend time reverse engineering that crap for your business is just unethical. It's parasitizing.
You need good Linux support for your tv boxes? Ask the manufacturers of those boxes, and see what they answer to you.
The problem about the "right price" is that the price can't be right if you don't include software developing and maintaining costs. Chinese tv boxes manufacturers are fetching "just working" Android distro into their products. If they would want to support a full linux environment, the price would be three or four times the actual price.
Want to talk about business?
Send a precise request to the developer of your choice (me included) and wait for a proper price quotation.
Want to do everything by yourself? You can.
Armbian developers spent hours to write proper documentation, available on docs.armbian.com. Source code is publicly available on github repository.
If you find it difficult navigate into, spend hundreds of hours lo learn things, as me and several others did, to raise your skills to keep up with your business.
-
1 hour ago, dorin said:
Hmm but it sounds like the rockchip cannot provide a sustainable solution this way. Even if I got a source playing and sized correctly in each plane, I would have a hard limit of 2-3 streams.
My goal is to monitor cctv cameras, like the rpi can play 16 streams quite easily (example), which I guess it's possible due to the arbitrary number of hw planes you mentioned.i think you have to find a different solution than connecting hardware video decode to hardware plane directly for such use case.
Ideally it should be possible to do hardware decode into a buffer that is then available for OpenGL to blit wherever you wish on your plane, I guess that drmprime is all about this, but you need to ask people with more knowledge than me. Maybe mpv forums can help you and mpv as is does not suit your task.
Such job would involve GPU and you should be capable of getting it to work on rk322x too.
How well in terms of FPS rk322x would perform is something that has to be discovered later.
16 hardware planes are probably too much for any SBC and, for your particular use case, are not needed.
-
1 hour ago, dorin said:
Thanks, I tried this and it works.
Now I am trying to play a couple of video streams simultaneously and display them in a grid. This is possible to achieve with omxplayer (https://github.com/popcornmix/omxplayer) but omxplayer works exclusively on raspberry pi GPU.But I cannot find how to do this with mpv, I had a look on the mpv documentation and the window geometry flags are ignored in gpu mode, and gpu rendering flags are a bit esoteric for me: https://mpv.io/manual/master/#gpu-renderer-options
It's actually possible to start multiple mpv processes but since the window is always fullscreen, the image flickers between the sources.
Any idea?Uhm, never actually tried to play two videos together on any rockchip box; I don't know the capabilities of rkmpp and what are the available switches and options to handle such situation.
With mainline kernel it could be more viable, because it uses drmprime which is the standard and tidy way to render an hardware decoded stream, and uses the regular DRM capabilities.
You should be able to get hardware video decoding on mainline kernel with instruction and mpv compiled available in this github post: https://github.com/armbian/build/pull/3152#issuecomment-922757262
The interesting arguments of mpv for you are --drm-draw-plane and --drm-drmprime-video-plane (see documentation here).
The former allows you to select which is the plane mpv should use to render the GUI (seek bar, elapsed time, title, volume indications, info, etc...), the latter is the plane used to render the video.
A plane is a hardware resource: the SoC provides one, two or more planes. The SoC, also, composes the planes in hardware to render the final output.
As an example, when you run X server, the desktop is displayed on primary plane (which is rendered first, so it appears "below"), and videos are displayed on overlay plane (which is rendered next, so it appears "above").
rk322x unfortunately has just three hardware planes: two of them are full-featured planes, the remaining is for hardware cursor. The plane for hardware cursor is always rendered as last plane and is very limited (up to 128x128 pixels).
About the two full-featured planes, one is allocated by the kernel as primary, and the other as overlay.
Now, what you can try to do is run mpv rendering the first video on primary plane and the second video on the overlay plane.
You should find a way to disable the GUI though, because otherwise one mpv instance will get control of both planes, leaving no available planes for the other.
Another task is to find a way to tell mpv it has to resize the plane to wanted dimensions: since primary plane is below and overlay is above, if you run both videos fullscreen, the video allocated to primary plane will never be visible because it is always below.
Other rockchip SoC are more capable in this sense: rk3328 has three full-featured planes. Bigger SoCs (like rk3288 or rk3399) have even more.
Raspberry Pis are peculiar from this point of view. They have an hardware compositor which is capable of handling an arbitrary number of planes. You can create and destroy hardware planes at runtime and even change the z-order of them. The hardware compositor will render all of them until it is hardware limits are reached; after then, the HDMI output will start flickering and the monitor loses synchronization.
Usually with raspberry Pi (even the oldest Pi1) you can at least run with two full-hd hardware planes without having issues.
Good luck and keep us informed with the progress
-
13 hours ago, chaka said:
Ha Ha HA.
Congratulations, I did run it on my TV box. It's strange, but after I erased the flash not with a multitool, but with an android tool, it started. But now another problem has appeared, the wifi does not work. writes an unknown device. I opened and looked at the marking of the chip and the marking of S9012P. W
hoever faced such a problem, how to solve it?
Congratulations, but no logs, no photos, no dtbs, no original firmware => can't help
-
7 hours ago, chinhhut said:
I did not run the rk3318-config yesterday, just keep default. But I run the "apt get upgrade" and also forgot to run the following command after installing to eMMC:
Run apt-mark hold linux-image-edge-rockchip64 linux-dtb-edge-rockchip64 to avoid the upgrade of kernel with the armbian official one, since it still does not contain rk3318That would be the reason the kernel of my box was updated to the latest one from armbian official. It did not contain 3318 dtb so the box was unable to boot.
Today, I just re-install from scratch again then run the hold command to prevent to upgrade the kernel. The "black screen" error is not happened again up to now even unplug/plug about 3 times.
Thank you very much for your quick response.
ook thanks for reporting! Much better to know that it wasn't a dtb/kernel fault
-
36 minutes ago, chinhhut said:
I have a T9 box (2G memory & 16GB flash) and just install Armbian 21.11 - Debian Bullseye minimal - mainline kernel 5.14.14 successfully to eMMC according to the guide.
Everything seems to work well until I tried to unplug the adapter and then replug the adapter again. After that, the box unable to start even I tried to unplug/replug the adapter several times again. There is only black screen via HDMI output.
Of course, I can install Armbian to the eMMC from scratch again but I'm afraid the "black screen" error above will happen.
@jockdo you have any suggestions to fix this? Please let me know if you need any detail steps or log to debug.
Thank you very much for your great work again.
The mysterious adapter is the power plug?
However yes, logs are important (expecially those coming from the serial port). You should clarify what you did in your first session: for example, did you run rk3318-config and what settings you enable?
edit: of course all other details described in paragraph "How to partecipate" in first page are useful
-
Hello.
both tv box and rk3318 are bad choices.
For the remaining questions:
-
@marshall sorry for taking so long in answering. At the moment I'm a bit busy and a bit tired too. Your issue seems to require more attention than expected, still could not figure out what is wrong.
From the log you posted I see something very odd: I don't see the eMMC card (mmc2), the sdio wifi chip (mmc1) is not detected at all and the sdcard (mmc0) has problems getting into high speed mode. This is the hardest combo ever!
Basic doubt regarding multiboot and armbian
in Rockchip CPU Boxes
Posted
I guess you mean multitool and not multiboot.
The answer to the question is yes: armbian could boot the same way the multitool do.
These are the reasons behind the choice to not have such option:
What we lose:
The responsible for sd boot is the rockchip miniloader, initrd is not involved at all in the process.