jock
-
Posts
2077 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by jock
-
-
28 minutes ago, the_collector said:
@jock Thank you! That was enough of a clue to get this working (albeit an awful hack), while the loader on my SoC seems to not want to boot from a USB device I figured out that if a USB flash drive with the extlinux.conf is in the OTG port the boot process can proceed as expected. This workaround is fine, though I couldn't find the source for multitool to start debugging further.
The box I have is marked externally as a MXR 4k bought from a seller on Amazon UK September 2016. The board however is marked 'MXQ-RK3229-D16', version '0.9A' on the silkscreen. With a whole bunch of missing optional(?) components.
Top side
Bottom side
UART is on the group of three vias centre bottom: GND, TX, RX.
(I also feel I have to point out I had nothing to do with the mess of burnt flux on the IR-rx
, shonky cheap boards be shonky).
Glad you went a step further.
This looks definitely a new board I never dealt with.
The multitool sources are available on my repository https://github.com/paolosabatino/multitool
However if you can boot the multitool from the USB stick you can get a shell and look into dmesg for further details, like for example if the emmc and sdcard are seen by the kernel, it's a starting point to understand why u-boot does not detect the sdcard.
You should also be able to interrupt the u-boot bootstrap and use it's interactive shell to get further info about the mmc subsystem. Commands like mmc info and mmc list should be useful to start with. U-boot shell has its own shell commands, but you should be easily find them somewhere on the net.
-
1 hour ago, tediwildan said:
Many thanks@jock
Now I can upgrade the system, the only issue on my tvbox is wifi doesnt work after I install LXQT desktop On armbian buster
Sent from my SM-C9000 using Tapatalk
Be sure to have armbian-firmware package updated, try to run apt-get dist-upgrade to get all the packages. In case you are holding pack some packages (maybe with armbian-config), unhold them and then upgrade again.
-
@Alex83 @tediwildan I checked the issue with apt-get upgrade and actually it happens only on NAND boards due to some misbehaving code in armbian. I'm fixing the issue, in the meantime you can plug an sdcard in the sd slot and then run apt-get upgrade: the presence of the sdcard in the slot is sufficient to avoid the issue and the upgrade should install fine.
-
@the_collector looks quite regular, except for the fact u-boot does not see the sd card at all.
Device 0: unknown device message is very suspicious, maybe you get a different board that requires different gpio configuration. Could you provide some details, like a couple of photos, the board name (usually it is printed on the PCB, like R329Q_v3.0 or XT-MX1VR, etc...)
-
Ah ok, I did not understand you wanted composite tvout; well can't be really helpful here, I never tried it actually.
You may take a look to libreelec forum, @knaerzche tested it and it worked on his builds.
-
Just tested, it worked flawlessy.
If you're using from command line you may want to add:
defaults.pcm.card 2 defaults.ctl.card 2
to /etc/asound.conf to make the analog the default
-
Do you mean that you don't see the analog audio output device or the output is going to HDMI by default?
Didn't try recently, but all the three audio devices (HDMI, SPDIF and Analog) should be all there.
Depending on your application, you may need to change ALSA or Pulseaudio output device.
Output of aplay -L and aplay -l can be useful, you may also try alsamixer and see if analog audio is available and unmuted.
-
14 hours ago, fabiobassa said:
But Alex we are speaking of different products
you said 3328 3 3 2 8
we said 3228 3 2 2 8 there is one cipher differing
so right hierarchy of cpu is
3228 a3228 b
3229
3328 ( well exactly 3318 and then 3328 ) and those are 64 bit and gigabit ports
yes the board you speaking about is 3328 no mistery about tht because is widely used
Concerning 3228a/b and 3229 TOTAL mistery !!! Also the document you linked we have it since one year now but is useless without another manual that is called TRM and of it we have just spare partsRight one!
It's the rk3328 that has the USB3 port and two ethernet interfaces, one is gigabit and the other is fast ethernet. Usually on tv-boxes only the fast ethernet is wired in to keep costs down, but you can find SBCs (like the RockPi-E) with both.
-
On 10/6/2020 at 12:56 PM, Alex83 said:
For example I see a maximum performance of ~640 Mbit/s on my rk3229 V88 Mini 4k devices while my orange Pi PC pushes 2,5 Gbit/s over localhost if and my Banana Pi with 1Gbe Interface just pushes 1,4 Gbit/s and M2plus pushes 2 Gbit/s.
Measuring the performance over localhost is a bit pointless. You're measuring how much data the kernel TCP/IP stack is capable of pushing trough: fundamentally, the faster the CPU, the higher the number. Quality and speed of the ethernet interface is totally unrelated to this.
On 10/6/2020 at 12:56 PM, Alex83 said:Rk3228 is much more powerful of it's hardware than rk3229 products. I Can't tell you what's the difference between rk3228a and rk3228b.
I can tell you that I own a device Alfawise Z28 Pro which has 1000Mbit/s LAN and wifi ac with 5GHz and USB 3.0. Unfortunately not im use because im not sure if I can use the Z28 images from a similar box.
Anyway I think rk3229 has no USB3. 0 and 1000Mbit/s ETH support and maybe also no wifi ac. But with wifi I am not sure.
That's the opposite:
* rk3229 is the "big" brother,
* rk3228b is a trust-os stripped down rk3229
* rk3228a is a slower rk3228b (1.2ghz for cores, 400 Mhz for GPU)
At least this is what we are guessing, because there is no official documentation about the differences.
The attached peripherals (wifi/bluetooth mostly) are totally random, depending mostly on how much old is the board; but it is way impossibile that you get USB3 and Gigabit ethernet on these three SoC because they lack the physical interfaces. Sure, the manufacturers could add other chip to handle that, but it would be an added cost on machines that have their unique selling point of being cheap.
-
I will check this apt-get upgrade issue whenever I can... Unfortunately time is a very finite resource...
-
22 hours ago, Alex83 said:
But how can I get the true and only correct wifi mac? Doesn't this also change if it's not the correct one in efuse?
Do I get for sure the real wifi mac with ifconfig?
wifi never gave me issues with MAC address. ifconfig gives you the MAC address in use by the interface.
22 hours ago, Alex83 said:Is there any chance to get reboot work and to get rid of the kernel update error during each
yes, you can use armbian-config and freeze the kernel updates, so it won't update the kernel anymore.
You can also do hold packages manually using apt-mark hold
-
4 minutes ago, Alex83 said:
How can I actually get the real Mac address? It's not the one on the bottom of my box because I changed pcb once and did not write it down somewhere...
In my experience with ifconfig I get after each reboot the different Mac addresses as it is recognized in my DHCP.
Hehe, there is no real eth0 mac address
These tvbox don't have the MAC address stored somewhere, like proper SBCs do. The Asus Tinkerboard (an rk3288 board) for example has a small EEPROM where it keeps the MAC address and other details (like the serial number) things stored.
Our boxes can't afford the EEPROM to keep these things stored, so the MAC address is calculated from the SoC serial number during the boot process. U-boot is responsible for this and before the patch it was unable to read the SoC efuse (where the SoC serial number is stored), so the MAC address was calculated randomly at each boot.
Wifi mac address is stored in the Wifi chip efuse and the wifi driver is responsible for assigning that and this is rarely problematic.
-
2 hours ago, Alex83 said:
Is it maybe because I did it wrong with the option "burn flash to Rom"? But I didn't install the idbloader. It recommended not to install, so I didn't install it.
Ahhh... right, I forgot you have NAND
To make things work on NAND, it is needed to use the legacy u-boot which has not the right patch to make MAC address stable... so @fabiobassa workaround is the best way to go in your situation.
-
On 9/30/2020 at 11:19 PM, Alex83 said:
Can I also try to use ssv6x5x driver with ssv6051 chipset?
Unfortunately not, the ssv6x5x is only for ssv6256p chip. People at SSV company are not very well acquainted with names and IDs, in fact they used the very same ID 3030:3030 for both ssv6051 and ssv6256p wifi chips and the driver name is also confusing (looking at ssv6x5x you may think it works for ssv6051 too, but it doesn't
)
On 9/30/2020 at 11:19 PM, Alex83 said:BTW is there a solution for switching eth0 mac address after each reboot?
Did you download the image you installed recently? This was a problem of u-boot and has been solved months ago. LibreELEC had the same issue, but has been fixed. If you use a fresh image you should get a stable MAC address.
-
12 minutes ago, Alex83 said:
Dpkg: error processing package linux-image-legacy-rk322x (--configure) : installed linux-image-legacy-rk322x package post-installation scripts subprocess returned error exit status 1
Errors were encountered while processing :
linux-image-legacy-rk322x
E: Sub-process /usr/bin/dpkg returned an error code (1)
The output as-is does not provide any hint of what the problem may be unfortunately
13 minutes ago, Alex83 said:Also I noticed reboot is still not working unfortunately. I need to replug the power adapter...
Yes, this is an issue with almost all NAND devices, could not find a software workaround because I didn't understand the reason this happens.
About the iperf performances, I made some tests during the adaptation of the other ssv6x5x driver. I remember very well that the ssv6x5x was around ~60-65 Mbit/s, the ssv6051 was around ~40Mbit/s and the ethernet was steady around ~90Mbit/s.
Of course wifi drivers were tested in ideal conditions: the router and the box were in line of sight each other without obstacles and without interference from other routers/devices.
Also in the latest images the ssv6051 and ssv6x5x drivers have been compiled with compiler optimizations on (-Os), the hardware cyphers active, and the p2p interface deactivated so they should perform even better than before. p2p interface was causing a lot of performance degradation in the past because network manager was scanning the networks thus interfering with the wlan0 network.
Did you use one of the stable images from the armbian download page or one of my compiles in the first page of this post?
-
12 hours ago, Alex83 said:
Hey guys I just updated my V88 mini 4k with legacy kernel. During upgrade I saw some errors for rk3229-legacy-kernel update or something. After reboot try it didn't halt as usual, but after replug the box doesn't start anymore just the red led. I installed the armbian onto NAND and it worked quite well even with wifi I used it with around 30 Mbit /s up and down. I just wanted to keep on maintaining and did the upgrade. Now I guess I lost the correct upgrade path between legacy kernels since I haven't updated for at least around 5 months.
So what can you recommend and is there a chance to get back onto my data in NAND or do I need to start from zero again with multitool?
Uhm, I'm sorry about this, can't think about what went wrong... the legacy kernel is in practice frozen from the first publication day.
What may have happened is some kind of corruption of the trust or the bootloader.
The Multitool has a nice function to give you a bash shell to access the NAND partition and make the manual necessary checks, but of course you need to be aware of what you do.
These commands may be helpful to restore the trustos and u-boot on the NAND, in case they were somehow damaged:
mount /dev/mmcblk0p1 /mnt dd if=/mnt/bsp/legacy-uboot.img of=/dev/rknand0 bs=4M seek=1 oflag=direct dd if=/mnt/bsp/trustos.img of=/dev/rknand0 bs=4M seek=2 oflag=direct sync exit
then you can shutdown via multiboot menu and cycle power to see if it works
-
13 minutes ago, rna said:
Could you please share a reading about this? It doesn't matter if it is a complicated process for me. Anyway thanks for your reply
Sure. This is a description of the boot process I made in an earlier post. You have to follow the first process which uses the miniloader. The existing bootloader in the internal flash memory is always engaged first, but if you put the miniloader-based bootloader on the external sdcard, the internal miniloader will boot from external sdcard
This is the operative approach followed by LibreELEC source code which does the operation to create the bootloader with all the things in the proper places:
https://github.com/knaerzche/LibreELEC.tv/blob/master/projects/Rockchip/bootloader/install
-
1 hour ago, rna said:
Is there a way that does not involve erasing the original firmware? instead just using SD Card to boot Armbian while keeping the android in the eMMC.
Yes, there is a way but it is absolutely not really comfy and fast, plus requires some advanced skills to prepare the whole thing and involves the use os some proprietary rockchip tools and the rockchip miniloader
1 hour ago, rna said:It means I have to prepare an SD card that is bigger than 16GB to backup my entire eMMC content
Not necessarily, if you use the Multitool to make a backup, it will backup the eMMC content directly into a compressed file. It depends on how much data you already stored in your eMMC, but usually it fits into much smaller sdcards. Since the partition of the Multitool is FAT for maximum compatibility, the compressed file must not be bigger than 4GB but you may give it a try.
-
1 minute ago, mboehmer said:
The schematic is not under NDA; but under gentlemen's agreement. I have to ask first.
Of course!
I had a quick look to the device tree you posted, I see many similarities with xt-q8l-v10 and the act8846 seems wired at the same manner. You may give a chance to that image, it is possible it already works quite well!
-
1 hour ago, mboehmer said:
AFAIK it is possible to reflash the single sectors of eMMC later with newer Uboot and rootfs?
Yes, of course! You can do either from linux or via MaskROM mode using rkdeveloptool.
But from linux it's far easier.
1 hour ago, mboehmer said:Some help on how to backup and restore the current image would be great (I did some "backup" by rkdeveltool ( rkdeveloptool rl 0x0 $((7456 * 2048)) backup.data
Using rkdeveloptool as you did is a good way, but beware that rkdeveloptool works differently when you are in maskrom mode and loader mode.
- Maskrom is when your board didn't boot at all, the serial is silent, your board shows to your computer as an USB device and you need to first upload the bootloader using rkdeveloptool db
- Loader mode is when you interrupt the u-boot process and rkdeveloptool works without uploading the bootloader
The first one allows you to access the whole eMMC, instead the loader mode shift the first sector away by 0x2000 sectors, so you can't access the very first 0x2000 sectors, hence you can't backup and you can't restore them.
I may suggest you to check also the Multitool from the tvbox thread. If it works for you (it's tested just for xt-q8l-v10 board at the moment), it may give you a more reliable backup because it accesses the whole eMMC flash and produces a nice gzipped image.
1 hour ago, mboehmer said:For DTB work, I will need some help, but I have a complete schematics of the board, documentation on how to compile for that specific card, and I already asked the manufacturer for his DTS file.
I think - apart from DTS syntax - there is no problem to get all information.
If you have the schematics and the dts there is no problem, all the things will fit in a way or another. Are the schematics under NDA? If not you may ask the manufacturer if you could share them.
1 hour ago, mboehmer said:I have started now with rk3288-evb-act8846.dtb, and get ethernet working, other stuff not tried yet.
Maybe you can send me your DTS file to check about ACT8846 stuff first?
Everthing is available on the armbian github page.
The patch file that adds the dts for the xt-q8l-v10 to the kernel in particular is here if you want to take a look
-
Hello, I made some work on rockchip rk3288 tv box boards you can find it here:
The act8846 is the PMIC controlling the various power supplies of the board components. It decides the voltages of the CPU, logic, GPU, wifi, ethernet and so on.
The image of the above tvbox has already the act8846 kernel module wired and configured via device tree, but it is very important that you have at hand the device tree or the electric schematics of the board to properly configure all the details: as you probably already have seen, the act8846 has various DC-DC converters. The converters supplying high currents (~2A) are usually always wired to the CPU, logic and GPU, but the LDOs may have been attached to different devices, and this could be important to get external devices work, like ethernet, wifi, UHS sdcards, etc...
Rockchip has many options to boot, from the log you posted above you are using the rockchip ddrbin + rockchip miniloader. This older post of mine could be useful to understand the rockchip boot process. It refers to another chip (rk3228/rk3229), but it is very similar among 32bit rockchip SoCs.
Anyway you could try the images of the tvbox above (get them from here) and if you're lucky your board will probably boot.
Also in the forum thread above you can also find the Multitool, which is a handy image of a tool which is capable to backup, restore, burn images directly on the internal flash or erase it.
edit: the error you're facing during the boot process is due to the miniloader looking for kernel and trustos. You have to put the kernel on the sdcard at the right location (sector 0x2000) and the kernel must have been massaged first using the rockchip tool loaderimage with the --pack flag. Trustos is not really necessary, it should boot even without it.
The tvbox image instead uses mainline u-boot in place of the miniloader that reads the kernel directly from the ext4 filesystem, which makes kernel updates much easier.
-
6 hours ago, rna said:
Hi @jock & @fabiobassa, Thanks for supporting RK322x SoC.
I have read the manual, I want to use SD Card to boot to Armbian while keeping my android image in eMMC.
I had burned the multitool image, then insert my SD Card to to the box and now it boots to the multitool menu.However I cannot find the "Install Jump Start for Armbian".
Here's the menu that I got:1. Backuo flash
2. Restore flash
3. Erase flash
4. Drop to bash shell
5. Burn image to flash
8. Reboot
9. Shutdown
How can I find this "Install Jump Start for Armbian" from multitool?
Thanks for your help,rna
Hello, Jumpstart is for boxes with NAND flash memory. You're lucky because you have an eMMC, which is much less troublesome.
Anyway at the moment the Armbian bootloader is almost entirely based on open source software (u-boot), so when the original firmware is installed in eMMC, it just does not boot from sdcard. I know that this may seem a bit odd, but this way bootloader upgrades are safer and don't rely upon rockchip proprietary tools.
For this reason the Multitool has the ability to do backup and restore of the entire eMMC content with ease.
-
5 hours ago, megaduo said:
Thx,i've got log from amlogic s905d set top box that works fine with the stick which you can refer to.
Module Size Used by
hci_uart 34102 1
cifs 402687 0
bnep 15079 2
si2157 7659 1
si2168 11076 1
dhd 902634 0
8021q 21855 0
btsdio 4874 0
dvb_usb_dvbsky 11024 0
m88ds3103 22727 1 dvb_usb_dvbsky
dvb_usb_v2 24019 1 dvb_usb_dvbsky
dvb_core 125735 3 dvb_usb_v2,m88ds3103,dvb_usb_dvbsky
videobuf2_vmalloc 6593 1 dvb_core
videobuf2_memops 2012 1 videobuf2_vmalloc
frame_vector 3190 2 videobuf2_vmalloc,videobuf2_memops
bluetooth 372939 25 bnep,btsdio,hci_uart
videobuf2_common 43214 1 dvb_core
6lowpan_iphc 10231 1 bluetooth
cfg80211 417431 1 dhd
mali 224703 5
wireguard 126823 0
wifi_dummy 894 0
amlvideodri 13834 0
videobuf_res 5794 1 amlvideodri
videobuf_core 18415 2 amlvideodri,videobuf_res
videodev 201143 2 amlvideodri,videobuf2_common
mc 38700 5 si2157,dvb_usb_v2,videobuf2_common,videodev,dvb_core
dwc_otg 261556 0
fbcon 40863 0
bitblit 4820 1 fbcon
softcursor 1344 1 bitblit
font 7399 1 fbcondmesg | grep dvb
[ 5.907339@0] kernel-overlays-setup: processing conf /storage/.cache/kernel-overlays/50-driver.dvb.dvb-latest.conf
[ 5.940723@0] kernel-overlays-setup: added modules from /usr/lib/kernel-overlays/driver.dvb.dvb-latest/lib/modules/3.14.29
[ 11.147513@0] usb 1-1: dvb_usb_v2: found a 'MyGica Mini DVB-T2 USB Stick T230C v2' in warm state
[ 11.199443@2] usb 1-1: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer
[ 11.199474@2] dvbdev: DVB: registering new adapter (MyGica Mini DVB-T2 USB Stick T230C v2)
[ 11.200280@2] dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered.
[ 11.229182@2] dvbdev: dvb_create_media_entity: media entity 'Silicon Labs Si2168' registered.
[ 11.230396@2] usb 1-1: dvb_usb_v2: 'MyGica Mini DVB-T2 USB Stick T230C v2' successfully initialized and connected
[ 11.230551@2] usbcore: registered new interface driver dvb_usb_dvbskyOkay, the log from 905d was useful, I see that some modules have been loaded so I enabled them in the kernel config.
This is a development debian minimal image to test for you, kernel is 5.8.12:
https://drive.google.com/file/d/1WMEuJYW2tam-9y0eK4VLGAzoEFXmjQwJ/view?usp=sharing
-
7 hours ago, megaduo said:
I have tried to copy relate firmwares to lib/firmware,but didn't work.Looks like that certain modules or drivers wasn't build into kernel(si2157,si2168,si2141,m88ds3103,m88ds3103b,...).Maybe some kernel configuration options not being seleced.(CONFIG_MEDIA_SUBDRV_AUTOSELECT).Could you pls look into it?Thx.
I checked your dvb stick, it should have si2168 chip which surely is not enabled at the moment. si2141 is the tuner, but I see no references in the kernel.
I will try to compile a kernel with si2168 module soon
CSC Armbian for RK322x TV box boards
in Rockchip CPU Boxes
Posted
Well... it's pretty difficult to say if your board is borked or not, usually backpowering via USB is safe but manufacturers suggest to avoid.
Anyway mali blobs have always had a bad reputation, and Mali400/450 drivers are terrible, so it is expected that you get an unresponsive system after some tries, it happened to me too, expecially if you are running thing in X11.
NEON code should run pretty fine, didn't try by myself but I don't see a valid reason it should not. Also GBM consumers, like Kodi in fullscreen, should run better and be more stable than X11 applications.
You may give a chance to mainline kernel with Lima, maybe compiling the latest debian which has very recent Mesa.
About gcc, it is not detection, but it is more like configuration: it is probably configured as vpf3-d16 by debian people on armhf, but you can override using -mtune and the other command line options.