Jump to content

CSC Armbian for RK3318/RK3328 TV box boards


jock

Recommended Posts

4 minutes ago, Huafu said:

@jockI've tried all combination of the uncovered copper without success. Even tried and with each of the 3 spots...

I also tried UART, nothing just some weird chars right when I touch tx and Rx to their spots, but nothing when I give power to the board, with or without the reset button pressed...

Thanks for tour time and if you can't take a deeper look nevermind.

 

Tho if you have a solution related to the overscan of the first board I'll take it 🙂

Well I would try to guess what's wrong with that.

I just checked the ddrbin and it the very exact same ddrbin that is currently shipped along the current images, so all the things I said in the previous post should not apply to your case.

 

You must see something intelligible from the serial, be sure to put it at 1,500,000 bps (1.5 mbps), otherwise you only get garbage.

 

About the overscan, I never faced such issue with the board. Had to fix that on my monitor/TVs usually setting the right option in the menu (some call it "16:9", some "Just Scan", "PC mode" or other fantasy names...), but never had to handle it at board level.

It happened to me that some older TVs just don't have the feature to remove overscan :unsure:

Link to comment
Share on other sites

Armbian & Khadas are rewarding contributors

@jock For my RK3318 box, everything works well but recently there is always error message during starting up.

The message is "[FAILED] Failed to start Resets System Activity Logs.",

 

Here is the detail status of this service:

 

root@mybox:~# systemctl status sysstat.service
● sysstat.service - Resets System Activity Logs
     Loaded: loaded (/lib/systemd/system/sysstat.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Thu 2021-11-25 12:10:54 +07; 26min ago
       Docs: man:sa1(8)
             man:sadc(8)
             man:sar(1)
    Process: 698 ExecStart=/usr/lib/sysstat/sa1 --boot (code=exited, status=2)
   Main PID: 698 (code=exited, status=2)
        CPU: 38ms

Warning: journal has been rotated since unit was started, output may be incomplete.

 

So I just confused how to fix this one.

 

Thank you.

IMG_4873.jpg

Link to comment
Share on other sites

On 11/16/2021 at 11:02 AM, fabiobassa said:

Anyway, just to answer , in my personal study case I have done on it:
voip pbx ( asterisk)
network nas
network firewall
pihole dns firewall
openvpv, wireguard and tinc vpn

home assistant
volumio
special ip cam monitoring and data acquisition

 

Hi Fabio, I would be interested to know how did you make Volumio work on a RK3328 Android box? I have a Bqeel U1 Max (RK3328) which I don't use and repurposing it for Volumio would be awesome.

Link to comment
Share on other sites

Good morning, thank you for having accepted me in the forum. I'm new to these adventures I installed Armbian on my HK1 Max Circle box with the RK3318 chip everything went fine but I don't have a browser installed, how can I install it? Thanks

Edited by mibi
Link to comment
Share on other sites

@kindgott 

this 3ad is more hardware operating-system oriented than user space applications oriented.

It cames by itself that if we would only try all the universe of application avaible for linux we loose the original  point of view :

working or not working on the most boards on the market


To answer to yor question , btw , I installed 2 years go  and I did step by step, not using a precompiled image. Now I see that many solutions are precompiled images and I don't like this approach

I guess google as alway can help solving the question at the actual state of art of volumio


 

Link to comment
Share on other sites

Hello @jock, thanks for helping again.

  

On 11/24/2021 at 7:29 PM, jock said:

You must see something intelligible from the serial, be sure to put it at 1,500,000 bps (1.5 mbps), otherwise you only get garbage.

What is weird is that the red led turns on directly when I give power to the board and nothing else happens, the red light remains on, period.

 

Thanks for the baud rate, I didn't have the good setting, but I might also plug it the wrong way.

I've tried with and without the GND. Either way I do not use the +5V as I don't know where to connect it. I'm only using TX and RX, and I've tried with and without the GND but I guess I don't need it if I'm not using the +5V.

When I make the contact between the UART cables and the board, I got garbage, then I give power to the board and nothing is shown anymore. Is this the right way to proceed?

 

image.png.9b1d75293f7222ac2b0d67b3767c88c2.png

 

On 11/24/2021 at 7:29 PM, jock said:

About the overscan, I never faced such issue with the board. Had to fix that on my monitor/TVs usually setting the right option in the menu (some call it "16:9", some "Just Scan", "PC mode" or other fantasy names...), but never had to handle it at board level.

It happened to me that some older TVs just don't have the feature to remove overscan :unsure:

Then I have an old TV :)

 

UPDATE: related to screen resolution, I've discovered that my big TV screen is recognized thru EDID as a 7' LCD, which is totally wrong. Manufacturer is good, but EDID says:

 

  Video Data Block:
    VIC   4:  1280x720    60.000 Hz  16:9    45.000 kHz  74.250 MHz (native)
    VIC  19:  1280x720    50.000 Hz  16:9    37.500 kHz  74.250 MHz
    VIC   5:  1920x1080i  60.000 Hz  16:9    33.750 kHz  74.250 MHz
    VIC  20:  1920x1080i  50.000 Hz  16:9    28.125 kHz  74.250 MHz
    VIC   3:   720x480    59.940 Hz  16:9    31.469 kHz  27.000 MHz
    VIC  18:   720x576    50.000 Hz  16:9    31.250 kHz  27.000 MHz

Tho the specs of the monitor says its max resolution is 1360x768.

 

I'll try to find the correct EDID info from linux hardware and rewrite it using https://github.com/linuxhw/write-edid

Edited by Huafu
wrong screen resolution
Link to comment
Share on other sites

@Huafu

The ground (GND) pin is the most important pin, you must absolutely connect it if you want a reliable result, otherwise you can get varying results starting from occasional garbage, total garbage or even adapter breakage.

If you have a common regular USB serial adapter, +5V is not needed at all and must be kept disconnected.

 

All the three pins (GND, TX and RX) must be connected before giving power to the board and possibly with the serial adapter disconnected from the computer too.

Once the hardware setup is done, you can connect the serial adapter to the computer and configure minicom with the right parameters: usually it is sufficient to keep defaults and change baud rate to 1.5Mbps.

 

Finally you can give power to the board.

 

Link to comment
Share on other sites

Hi, after having successfully had my H96Max+ working for a few days now with a single major hiccup I would like to inquire about three items.

 

  • The single issue that I encountered was a total freeze during intense activity on the SD card while copying files transferred through wifi.  This copying is something that I could have done in a much quicker way but that I purposely did this way to stress the machine with a 2+ hours of continuous activity.  However, because I had this single freeze, that did not happen again, it is difficult for me to say if this was due to some OS or hardware instability or maybe some external factor (e.g., a power fluctuation).  It would be interesting to me to know if someone else experienced similar issues.
  • I would like to know if RK3328 supports some form of hardware watchdog timer to be used with the watchdog daemon.
  • I understand that once the machine is installed (thanks for the great work of jock and possibly others), maintaining the machine up to date and secure should be relatively easy, since most of the OS can be updated through the regular armbian repos. In my understanding the notable exceptions are the kernel packages at https://users.armbian.com/jock/rk3318/upgrade/ namely those that had to be put on hold wrt apt (linux-image-edge-rockchip64 linux-headers-edge-rockchip64 linux-dtb-edge-rockchip64). If I understand correctly, these can only get updated thanks to jock's effort because rk3318 is not part of armbian (yet). Having these packages depending on a single person best effort means on one hand that gratefulness to Jock is huge but on the other hand may also represent a potential issue. I thus wonder how difficult is it to re-build them by https://github.com/paolosabatino/armbian-build/tree/rk3318 and the armbian kernel tree, how much does the rk3318 diverge from the mainline kernel, how easily/frequently do the rk3318 patches break against newer mainline kernels and how difficult would it be to recover from a bad kernel (in case one tries to build and deploy a kernel for learning how to do it and something goes wrong).

 

Thanks for any help!

Edited by callegar
Improving clarity
Link to comment
Share on other sites

@callegar

1) To me happen quite often  on 322x ( not ried on 3318 thought) , both on sd and on internal emmc/nand. It look like the ethernet o wifi is not adapting very well the speed  of the net related to the speed of writing/ reading from storage. I can confirm that this happened to me also and exactly when i tried to stress the board as you did.

2) waiting for better @jock answer

3) yes you are right , at the actual state kernel and related things are not part of official armbian neither debian , but also all of us should consider that this is very esperimental case of study so the best is auto-compile since is not very difficult.
The difficult part is patch things as soon as problems are dicovered

 

Link to comment
Share on other sites

i use Armbian 21.11 - Debian Bullseye minimal - mainline kernel 5.15.2 from Jock

and i notice that

rsyslogd: file '/var/log/syslog'[7] write error - see
 https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: No spa
ce left on device [v8.2102.0 try https://www.rsyslog.com/e/2027 ]

log is in ram, and it's small , $ df :

/dev/zram1         49560    9120     36856  20% /var/log

but there is a cron job who clean var/log

Link to comment
Share on other sites

@dam74The issue with rsyslogd is a symptom. On my system, I think I managed fixing the issue by setting also the SystemMaxFileSize option in systemd journald.  Wonder if on a system with some good 32 or 64GB of resident storage having journal log meant to be permanent on zram is the right thing, though, given that journald already has volatile storage on /run.
 

Edited by callegar
Link to comment
Share on other sites

Hi @jock
I come back a bit on the led-conf3 that you provided me and which seemed to be correct however:
- There are physically on the front of my box 2 LEDs (1 red and 1 blue)
- when I run  " sudo du -a /sys | grep led | grep trigger "

      /sys/kernel/tracing/events/libata/ata_qc_complete_failed/trigger
0       /sys/kernel/tracing/events/dma_fence/dma_fence_signaled/trigger
0       /sys/kernel/tracing/events/kyber/kyber_throttled/trigger
0       /sys/kernel/tracing/events/btrfs/btrfs_failed_cluster_setup/trigger
0       /sys/kernel/tracing/events/ext4/ext4_journalled_write_end/trigger
0       /sys/kernel/tracing/events/ext4/ext4_journalled_invalidatepage/trigger
0       /sys/kernel/tracing/events/xdp/mem_return_failed/trigger
0       /sys/kernel/debug/tracing/events/libata/ata_qc_complete_failed/trigger
0       /sys/kernel/debug/tracing/events/dma_fence/dma_fence_signaled/trigger
0       /sys/kernel/debug/tracing/events/kyber/kyber_throttled/trigger
0       /sys/kernel/debug/tracing/events/btrfs/btrfs_failed_cluster_setup/trigger
0       /sys/kernel/debug/tracing/events/ext4/ext4_journalled_write_end/trigger
0       /sys/kernel/debug/tracing/events/ext4/ext4_journalled_invalidatepage/trigger
0       /sys/kernel/debug/tracing/events/xdp/mem_return_failed/trigger
0       /sys/devices/platform/gpio-leds/leds/ir/trigger
0       /sys/devices/platform/gpio-leds/leds/working/trigger
0       /sys/devices/platform/gpio-leds/leds/net/trigger
0       /sys/firmware/devicetree/base/gpio-leds/ir/linux,default-trigger
0       /sys/firmware/devicetree/base/gpio-leds/working/linux,default-trigger
0       /sys/firmware/devicetree/base/gpio-leds/net/linux,default-trigger

I therefore tried to modify the trigger on

> /sys/devices/platform/gpio-leds/leds/

Where can we find 3 leds? Either .. So I make some modifications on the 3 leds detected by the system and I find the red front led of my box (under the "net" value) I modify the value of the trigger on heartbeat and Hop the red led of my box starts flashing (cool ..!)
Unfortunately, it is impossible to modify the light state of the blue led which lights up when the box starts up, I have unsuccessfully modified the values of the triggers of the "ir" and "working" leds but nothing changes, currently the triggers in questions are on "none" and yet I still have the blue led on ..
Is there anything else to do?
Thanks in advance..

 

 

Link to comment
Share on other sites

On 11/28/2021 at 11:03 AM, callegar said:
  • The single issue that I encountered was a total freeze during intense activity on the SD card while copying files transferred through wifi.  This copying is something that I could have done in a much quicker way but that I purposely did this way to stress the machine with a 2+ hours of continuous activity.  However, because I had this single freeze, that did not happen again, it is difficult for me to say if this was due to some OS or hardware instability or maybe some external factor (e.g., a power fluctuation).  It would be interesting to me to know if someone else experienced similar issues.
  • I would like to know if RK3328 supports some form of hardware watchdog timer to be used with the watchdog daemon.
  • I understand that once the machine is installed (thanks for the great work of jock and possibly others), maintaining the machine up to date and secure should be relatively easy, since most of the OS can be updated through the regular armbian repos. In my understanding the notable exceptions are the kernel packages at https://users.armbian.com/jock/rk3318/upgrade/ namely those that had to be put on hold wrt apt (linux-image-edge-rockchip64 linux-headers-edge-rockchip64 linux-dtb-edge-rockchip64). If I understand correctly, these can only get updated thanks to jock's effort because rk3318 is not part of armbian (yet). Having these packages depending on a single person best effort means on one hand that gratefulness to Jock is huge but on the other hand may also represent a potential issue. I thus wonder how difficult is it to re-build them by https://github.com/paolosabatino/armbian-build/tree/rk3318 and the armbian kernel tree, how much does the rk3318 diverge from the mainline kernel, how easily/frequently do the rk3318 patches break against newer mainline kernels and how difficult would it be to recover from a bad kernel (in case one tries to build and deploy a kernel for learning how to do it and something goes wrong).

1) Yes, I experienced similar issues expecially with an rk322x board in the past. I did many tests and apparently reducing the current to the wifi gpio pin improved situation. The fact is sdcard, wifi and emmc are somehow bound together being all attached to mmc controllers. Often an issue in a device prevents another to work correctly. It could also be some buggy driver, an interrupt with bad timing and thousands more things.

2) There should already be a watchdog driver, nonetheless it complains in dmesg about something and I never really tested it

3) rk3318 and more generally all 64-bit rockchip armbian kernels differ quite a lot from mainline. There are plenty of patches applied over mailine kernel to make these socs work better and more stable. This is the list of patches applied to rk3399 and rk3328/18. Many of them just add device trees for various supported boards, but many others also add functionality and fix broken things in mainline kernel. Rebuilding the kernel packages is quite easy, armbian build scripts are all automatized and you just need to run a script and select what you want for which board. Armbian documentation explains all the process briefly. When you are done, you will find the deb kernel, headers and dtb packages in output/debs directory of armbian installation. Just copy them on your board and install with dpkg. If something goes wrong, multitool allows access to existing mmc via shell to do maintenance, but also can be used to made a backup of the existing content that can be restored in case something goes wrong.

 

21 hours ago, callegar said:

Noticed that systemd journal fills up /var/log apparently ignoring the SystemMaxUse=20M using the bullseye image.  Anyone else experiencing this? Is this an rk3318 bug and armbian bug or a debian bug?

yes, me too. It seems to happen only with bullseye, buster is fine.

I don't know which one is the offending party, but I guess it is a bug in armbian since it uses a special zram partition to keep the log during runtime to reduce flash memory wearing.

Link to comment
Share on other sites

9 hours ago, MX10.AC2N said:

Hi @jock
I come back a bit on the led-conf3 that you provided me and which seemed to be correct however:
- There are physically on the front of my box 2 LEDs (1 red and 1 blue)
- when I run  " sudo du -a /sys | grep led | grep trigger "

      /sys/kernel/tracing/events/libata/ata_qc_complete_failed/trigger
0       /sys/kernel/tracing/events/dma_fence/dma_fence_signaled/trigger
0       /sys/kernel/tracing/events/kyber/kyber_throttled/trigger
0       /sys/kernel/tracing/events/btrfs/btrfs_failed_cluster_setup/trigger
0       /sys/kernel/tracing/events/ext4/ext4_journalled_write_end/trigger
0       /sys/kernel/tracing/events/ext4/ext4_journalled_invalidatepage/trigger
0       /sys/kernel/tracing/events/xdp/mem_return_failed/trigger
0       /sys/kernel/debug/tracing/events/libata/ata_qc_complete_failed/trigger
0       /sys/kernel/debug/tracing/events/dma_fence/dma_fence_signaled/trigger
0       /sys/kernel/debug/tracing/events/kyber/kyber_throttled/trigger
0       /sys/kernel/debug/tracing/events/btrfs/btrfs_failed_cluster_setup/trigger
0       /sys/kernel/debug/tracing/events/ext4/ext4_journalled_write_end/trigger
0       /sys/kernel/debug/tracing/events/ext4/ext4_journalled_invalidatepage/trigger
0       /sys/kernel/debug/tracing/events/xdp/mem_return_failed/trigger
0       /sys/devices/platform/gpio-leds/leds/ir/trigger
0       /sys/devices/platform/gpio-leds/leds/working/trigger
0       /sys/devices/platform/gpio-leds/leds/net/trigger
0       /sys/firmware/devicetree/base/gpio-leds/ir/linux,default-trigger
0       /sys/firmware/devicetree/base/gpio-leds/working/linux,default-trigger
0       /sys/firmware/devicetree/base/gpio-leds/net/linux,default-trigger

I therefore tried to modify the trigger on

> /sys/devices/platform/gpio-leds/leds/

Where can we find 3 leds? Either .. So I make some modifications on the 3 leds detected by the system and I find the red front led of my box (under the "net" value) I modify the value of the trigger on heartbeat and Hop the red led of my box starts flashing (cool ..!)
Unfortunately, it is impossible to modify the light state of the blue led which lights up when the box starts up, I have unsuccessfully modified the values of the triggers of the "ir" and "working" leds but nothing changes, currently the triggers in questions are on "none" and yet I still have the blue led on ..
Is there anything else to do?
Thanks in advance..

 

 

If I remember correctly, the dtb of your board was exporting four leds. I managed to include all of them, but I don't how many leds the board has.

Take in consideration that not all leds may be addressable: some may be just fixed leds, some others are mounted in antiparallel (so you can't get both of them on or off, just switch one or the other); some others just don't exist.

 

Setting trigger is just enough you need to change the led behaviour. If the led does not change, it means the dtb has a wrong reference to it.

 

 

Link to comment
Share on other sites

Thank you @jock
I have indeed noticed that when the red led turns on it turns off the blue led.
On the front of my box I only have 2 LEDs so 4 LEDs, yes if I count the 2 LEDs which are with the RJ45 connector (green and orange) otherwise I do not understand ..
Otherwise when I start on my emmc where I still have the armbian-station M1 image using

https://paste.yunohost.org/odozesogaz.hs

I can independently control each led, the basic dtb file used was rk3328-box.dtb I just invert the values of the leds for a good operation with my box, and I renamed it to rk3328-mx10.dtb I made this modification via armbian-config i am attaching a copy of this dtb.
thanks again

rk3328-mx10.dtb

Link to comment
Share on other sites

This is a great project. Thanks for all the hard work

 

I have successfully installed on a X88 pro 10 aTv box following the instructions here. Its running off the internal  eMMc flash. But I cannot get WIFI or LEDs to run. When using rk3318-config I get a message "No WIFI chip has been detected". I select rk3318-box-led-conf2 form the board configuration but noting happens. I have also tried the other 2 options but nothing. Even generic is not working. And I rebooted after each try. Below are links to photos of my board. Hope someone can help 

 

Thanks in advance

 

https://photos.app.goo.gl/gEdZEi6wsZWT1Y7S9

https://photos.app.goo.gl/yMLYRP1EP9fPtZTg8

Link to comment
Share on other sites

13 hours ago, MX10.AC2N said:

Thank you @jock
I have indeed noticed that when the red led turns on it turns off the blue led.
On the front of my box I only have 2 LEDs so 4 LEDs, yes if I count the 2 LEDs which are with the RJ45 connector (green and orange) otherwise I do not understand ..
Otherwise when I start on my emmc where I still have the armbian-station M1 image using

https://paste.yunohost.org/odozesogaz.hs

I can independently control each led, the basic dtb file used was rk3328-box.dtb I just invert the values of the leds for a good operation with my box, and I renamed it to rk3328-mx10.dtb I made this modification via armbian-config i am attaching a copy of this dtb.
thanks again

rk3328-mx10.dtb 38.05 kB · 0 downloads

 

Sorry it was not 4 leds, but 3 leds in the original dtb:

leds {
    compatible = "gpio-leds";

    power-green {
        gpios = <0xfb 0x00 0x00>;
        linux,default-trigger = "none";
        default-state = "off";
        mode = <0x23>;
    };

    net-green {
        gpios = <0xfb 0x01 0x00>;
        linux,default-trigger = "none";
        default-state = "off";
        mode = <0x05>;
    };

    ir {
        gpios = <0xa5 0x12 0x00>;
        linux,default-trigger = "ir";
        default-state = "off";
        mode = <0x00>;
    };
};

 

0xfb is the phandle to rk805 node and 0xa5 is the phandle to gpio2 node.

 

This instead is the content of the led-conf3:

&gpio_led {

	pinctrl-names = "default";
	pinctrl-0 = <&ir_led>;

	working {
		gpios = <&rk805 1 GPIO_ACTIVE_LOW>;
		default-state = "on";
		linux,default-trigger = "mmc2";
		mode = <35>;
	};

	net {
		gpios = <&rk805 0 GPIO_ACTIVE_LOW>;
		linux,default-trigger = "eth0";
		default-state = "off";
		mode = <5>;
	};

	ir {
		gpios = <&gpio2 RK_PC2 GPIO_ACTIVE_LOW>;
		linux,default-trigger = "ir";
		default-state = "off";
		mode = <0>;
	};

};

 

The two leds controller by rk805 are working (net-green on old dtb) and net (power-green). Working and net already match the order in the dtb you just sent me, so they should already fit your need.

Moreover there is the specification of this other ir led, which I don't know if it is present on your board or it isn't.

 

From what I can see, working and net are pointing to the same rk805 device and pins in both mine, yours and original dtbs, so they should work with led-conf3.

 

Maybe triggers are not exactly what you want, but they should not be changed in the dtb: it is expected you change them for your needs using /sys/class/leds filesystem objects at startup.

I have proposed a boot script to armbian developers to stash led state at shutdown and restore it as startup, so once you configure the leds for your tastes, they will be automatically restored at boot and there will be no hassle to do that manually.

Link to comment
Share on other sites

1 hour ago, markst said:

This is a great project. Thanks for all the hard work

 

I have successfully installed on a X88 pro 10 aTv box following the instructions here. Its running off the internal  eMMc flash. But I cannot get WIFI or LEDs to run. When using rk3318-config I get a message "No WIFI chip has been detected". I select rk3318-box-led-conf2 form the board configuration but noting happens. I have also tried the other 2 options but nothing. Even generic is not working. And I rebooted after each try. Below are links to photos of my board. Hope someone can help 

 

Thanks in advance

 

https://photos.app.goo.gl/gEdZEi6wsZWT1Y7S9

https://photos.app.goo.gl/yMLYRP1EP9fPtZTg8

 

Once rk3318-config tells you that no wifi chip has been detected, it proposes you to reboot and run again rk3318-config to finish configuration.

Make sure there is rk3318-box-wlan-ext in overlays= line in /boot/armbianEnv.txt before you reboot: this will enable the right sdio bus for your wifi chip.

 

Nonetheless, from the photos I see a very unknown chip there: LG642 A039 :ph34r: Never seen anything like that, maybe it is a clone of some other common chip otherwise there are not so many chances it is supported.

 

By the way photos are useful, but first page reports a bunch of things that are useful as well to be able to do some debug.

Link to comment
Share on other sites

13 hours ago, markst said:

This is a great project. Thanks for all the hard work

 

I have successfully installed on a X88 pro 10 aTv box following the instructions here. Its running off the internal  eMMc flash. But I cannot get WIFI or LEDs to run. When using rk3318-config I get a message "No WIFI chip has been detected". I select rk3318-box-led-conf2 form the board configuration but noting happens. I have also tried the other 2 options but nothing. Even generic is not working. And I rebooted after each try. Below are links to photos of my board. Hope someone can help 

 

Thanks in advance

 

https://photos.app.goo.gl/gEdZEi6wsZWT1Y7S9

https://photos.app.goo.gl/yMLYRP1EP9fPtZTg8

 

Hi @markst, sounds like we've got the same board, apart from that wifi chip as @jock said. I've built a custom image using edge kernel and gnome. As soon as I'll have more time I'm planning on including IR and LCD stuff directly into the image for the X88 pro 10. If I remember well, there is some post in this topic explaining how to install/configure LCD and IR.

 

@jock, I still didn't get the time to weld the UART correctly/process as you told me btw, I'll keep you informed. Tho I realized after looking at @markst's photos that there are some GND, TX and RX labels on the top side of the board next to the IR (bottom right on hist photo). The ones I've tried were on the bottom side next to the USB3 port. Which ones should I use? I think the ones next USB port are the right ones tho.

Link to comment
Share on other sites

@Huafu I saw the same labels on the top side on your board but could not find the pads/holes. Looking better at @markst's board, they are probably the four vertically aligned pads just a bit on the left.

I don't know which group is the right one, it may be those on the top side or those on the bottom side as well, so the only way to know is experimenting ^_^

 

Note also that you are not forced to connect the GND pin of the adapter to the GND pin on the board: you can connect it anywhere to the ground plane of the board. The shield of the ethernet/HDMI/USB connectors, for example, share the same ground plane. If you have a multimeter, you can easily discover that the GND pad and all the shields are just connected together.

 

Having those small pads is a bit of a hassle because soldering is not easy with them.

Link to comment
Share on other sites

3 minutes ago, markst said:

Looks like I bricked my X88 pro 10. I flashed the wrong file to the eMMc now it will not boot at all. Even will not boot off the sdcard. Any idea how to unbrick? I read about unbricking but I do not have a clock pin exposed on the board

@markst, I've bricked one of my 2 boards which sounds to be the same as your board. Read from this post (the paragraph which starts by "Now comes the failing part:"):

Read @jock and my messages from there, maybe you'll be able to get something from UART. I need to do this as well but no time for now :-/

Link to comment
Share on other sites

1 hour ago, markst said:

Looks like I bricked my X88 pro 10. I flashed the wrong file to the eMMc now it will not boot at all. Even will not boot off the sdcard. Any idea how to unbrick? I read about unbricking but I do not have a clock pin exposed on the board

:unsure: Don't know, you didn't even said what you did to brick the board. "Wrong file" is way too generic.

In the previous post you said you successfully installed armbian, now the board is bricked?

 

General unbrick instructions are in the first page, but you may need something specific for your board (see @Huafu posts)

Link to comment
Share on other sites

No luck can't get anything out of the box. I'm going to just buy another one and load it again.

 

Here is my use for the box. I'm making a Digital Signage Player. The Player autoloads chromium inside a openbox-session and plays content on a webpage.

When the box was working I had installed "Armbian 21.11 - Debian Bullseye minimal - mainline kernel 5.15.2  Build date: 2021-11-12" and it ran fine

EXCEPT Video playback was very choppy. So I looked at the ROCKCHIP-LEGACY MULTIMEDIA INTEGRATION but could not get it to work with Bullseye

 

Is there a way to get smooth video running the above OS image?? Videos are very slow and choppy.

 

Second problem No WIFI or LEDS. But this is not top priority for me as any box I use will be hard wired ethernet

 

If interested i used the following webpage to AutoStart chromium and get the display up

https://golb.hplar.ch/2019/01/kiosk-mode-nano-pi.html

Link to comment
Share on other sites

I bricked the board using Armbian_21.05.1_Rk322x-box_buster_current_5.10.34_minimal.img  I just uploaded it to emmc with the Multitool and did not first test by booting it off an sd card. The screen is now Black and I can no longer boot form SD. I even tried a usba-usba cable and nothing. The PC will not recognize the board connected. I do get a red led when powering the board. 

 

My first flash of the emmc was using Armbian 21.11 - Debian Bullseye minimal - mainline kernel 5.15.2  Build date: 2021-11-12 and that worked no problem (except choppy video)

Link to comment
Share on other sites

22 hours ago, markst said:

I bricked the board using Armbian_21.05.1_Rk322x-box_buster_current_5.10.34_minimal.img  I just uploaded it to emmc with the Multitool and did not first test by booting it off an sd card. The screen is now Black and I can no longer boot form SD. I even tried a usba-usba cable and nothing. The PC will not recognize the board connected. I do get a red led when powering the board. 

 

My first flash of the emmc was using Armbian 21.11 - Debian Bullseye minimal - mainline kernel 5.15.2  Build date: 2021-11-12 and that worked no problem (except choppy video)

Well, putting the image for rk322x on rk3318/28 is definitely not a smart move. Never tried myself, now we know it definitely bricks the board :wacko:

I bet your only chance is to go with maskrom mode, you have to find the eMMC clock pad on your board and put it to ground.

 

edit: ah, about videos in chromium, they will be choppy until a lot things required for multimedia are squared out. Can be next year or can be never, surely accelerated video in browsers is a complex task.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines