CSC Armbian for RK3288 TV Box boards (Q8)

[jock]

13 hours ago, DRAGO4k said:

@jockGreat work on the project.

I am having a little bit of trouble reversing engineering the uboot configuration so I can get other distros to boot. I did look over the official documentation but I am stuck at this point. Maybe you can lend a hand. What method did you use ? miniloader or spl ? I would say spl since we erased all the memory. How is the params file stored in your setup and how can we modify it.  Can you give some insights on how you configured and wrote uboot to the card ?

 

The final target would be to get Libreelec to boot on this.

I can help with great pleasure!

I use the rockchip proprietary SPL to do the DDR memory initialization because the box uses LPDDR2 which u-boot is not able to initialize.

 

U-boot configuration produces:

• the TPL (Third Program Loader, does some clock and memory initialization)
• the SPL (mainly sets the power hold GPIO pin of PMIC to keep the box turned on)
• the main u-boot binary

The boot process starts with the Rockchip proprietary SPL, which chains to the U-boot SPL, which chains to the main u-boot binary, and then the kernel + initramfs. The u-boot TPL is not used because the rockchip proprietary SPL does the clock and memory initialization.

 

Here you can see how the three blocks are assembled together (the board is xt-q8l-v10) in Armbian.

Here there are the patches that can be applied to the stock u-boot (tested and proved to work up to v2018.11). They include xt-q8l-v10-rk3288_defconfig and all the necessary bits to let it appear as a supported device by u-boot.

 

[DRAGO4k]

@jock, sorry for the off-topic but: https://forum.libreelec.tv/thread/17857-rk3288-xt-q8l-v10-aka-chiptrip-q8-9-1-001-image/ in case you are interested.

 

http://www.mediafire.com/file/dnddh7vy81goc99/LibreELEC-XT-Q8L-V10.arm-9.1.001-rk3288.img.zip/file

[jock]

@DRAGO4k Great work, thank you!

 

 

[Sergei Steshenko]

I think there is a problem with timeout of detection of external HDD. The following text probably looks convoluted - I've tried my best.

 

I have a number of HDD USB <-> STAT adapters - a USB-3.0 one and a USB-2.0 one. My last experiment was with the USB-2.0 one - quite possibly it consumes less current from USB port than the USB-3.0, but results are the same.

 

If I take my HDD connected to the USB-2.0 adapter, and connect the adapter with the HDD to my DESKTOP Linux PC, the HDD is detected, albeit with a delay of several seconds, and contents of the HDD can be read without a problem.

 

If I connect the same USB-2.0 with the same HDD (with Armbian RK3288 system) to my RK3288 box, there are repetitive attempts to reset the drive (squeaking sound about once per second), and the system fails to detect the drive. The power supply I'm using is 5V 4A (however one can believe the rating) power supply. I have also a 5V 3A power supply - the same results.

 

I have soldered a special USB port adapter which is USB male -> USB female connector with GND, D+, D- soldered straight from the male to the female connector and +5V line goes USB male pin -> SS34 Schottky diode anode -> SS34 cathode -> +5V pin of the USB female connector. In addition to this there is a 5.5mm/2.1mm power connector soldered to the USB female connector, and I connect the 5V 4A power supply (using a Y-splitter) to the 5.5mm/2.1mm power connector. There is also a 3300uF electrolytic capacitor connected to +5V and GND pins of the output female USB connector. The capacitor is intended to buffer voltage drops due to impulse current consumption by the HDD. In such a manner I completely bypass the USB port current limit - now current is limited by the +5V 4A power adapter I'm using. I.e. the current limit (assuming 4A is true) is 4A - current_consumed_by_the_RK3288_box. Still the same repetitive attempts to reset the HDD with squeaking sound. The USB male -> USB female adapter I've soldered definitely works - I tested it with USB mouse and with HDD on my desktop.

 

But if I additionally use another power supply - 5V 2.5A (which came with the RK3288 box) to power the box and the 5V 4A power adapter with the USB adapter I've soldered to connect the USB-2.0 HDD adapter + HDD to the RK3288 box, I am able to boot. Alternatively instead of self-soldered USB male -> USB female adapter I can use ready made powered USB hub - the system also boots. Again, the main point being TWO power supplies working at the same time: the 5V 2.5A + 5V 4A.

 

My theory is the following. On desktop the timeout is long enough, so even with the standard USB port without any external power supply the system manages to detect the drive, albeit slowly. In the Armbian image the timeout is too short, so the system is able to detect the drive only when it spins up quickly enough, and it happens with two power supplies working in parallel.

 

So I can order a more powerful power supply - say, 5V 5A. And/or I can try to change timeout, but I do not know in what file it's coded. @jock, do you know what the file is and what is the procedure ? I mean I need to create a new SD card boot image with the modified file setting. I.e. I need to modify the file and then to run something to modify the image, correct ? Thanks in advance.

[jock]

Hello @Sergei Steshenko, I'm in your very same situation: I have a external 2.5" HDD connected to a non-OTG USB port that contains the whole armbian rootfs. U-boot is installed in internal eMMC, so I don't required the sdcard to boot from the USB.

My HDD enclosure has a convenient barrel power connector for auxiliary 5V power. The non-OTG USB port itself is not able to spin-up the hard disk (neither the OTG port is), so auxiliary power is required.

I use a 12V 2.0A PSU which feeds a very small DC-DC switching power converter outputting 2A at 5V, which in turn feeds the box and the HDD. I thought that 2A are way too low for both the devices, in fact the DC-DC power converter gets quite hot, but after a couple of months of work it has not yet failed.

 

I have the same problem as you: if I turn on the box too soon, the hard disk is not detected. I have to wait a couple of seconds letting it initialize and then I can turn on the box. It's clearly a timeout issue.

 

After a quick look into u-boot compilation config file I could not find the USB timeout we are looking for, I guess I need to check better.

 

If the USB timeout is stored into an u-boot variable, it can be changed very easily setting it into /boot/armbianEnv.txt, otherwise it is necessary to recompile u-boot. Stay tuned, I'll look into it.

[Sergei Steshenko]

@jock, thanks for the update.

 

My OTG port is dead from the getgo - the seller didn't even put the cable for it. Several weeks ago I discovered that the port didn't work at all.

 

Regarding the USB HDD timeout value - maybe it's somewhere in UDEV rules ? I have never looked into UDEV, but I think it's responsible for detachable devices.

[Sergei Steshenko]

And my HDD enclosure doesn't have a separate power port, so I have to provide the necessary current through the only port present - which is USB.

[DRAGO4k]

it looks to me like a problem regarding the negotiation of amps over usb.

 

1) check power consumption of the hdd in a normal pc - or try to see how much is negotiated

2) check what power you get via Q8 or what is negotiated

 

as a last resort splice a usb cable, get the VCC and GND from a proper power supply.

 

PS: might be also a limit in the device tree for the usb(s) - or a limit of the hardware itself

 

@Sergei Steshenko - your power setup is a bit shady...if I have the time and find a working HDD I will try a spliced usb cable with external 5v power.  what type of HDD did you use ? 3.5 ? or 2.5 ?

[Sergei Steshenko]

9 minutes ago, DRAGO4k said:

it looks to me like a problem regarding the negotiation of amps over usb.

 

1) check power consumption of the hdd in a normal pc - or try to see how much is negotiated

2) check what power you get via Q8 or what is negotiated

 

as a last resort splice a usb cable, get the VCC and GND from a proper power supply.

 

PS: might be also a limit in the device tree for the usb(s) - or a limit of the hardware itself

Again, I power the USB port from a separate power supply - which is 5V 4A. When the HDD is powered from 5V 4A and at the same time TV box is powered from 5V 2.5A, everything works.

 

When both the HDD and the TV box are powered from 5V 4A, the drive is not detected.

 

With my USB port adapter I completely bypass whatever limits of USB - the only limits are the ones of power supply I'm using.

 

FWIW I am an electronic engineer by trade.

[DRAGO4k]

@Sergei Steshenko - nobody is doubting you. it just looks like a weird power issue. What type of HDD did you use ? 3.5 ? or 2.5 ?

[jock]

13 hours ago, DRAGO4k said:

it looks to me like a problem regarding the negotiation of amps over usb.

 

1) check power consumption of the hdd in a normal pc - or try to see how much is negotiated

2) check what power you get via Q8 or what is negotiated

 

as a last resort splice a usb cable, get the VCC and GND from a proper power supply.

 

PS: might be also a limit in the device tree for the usb(s) - or a limit of the hardware itself

 

@Sergei Steshenko - your power setup is a bit shady...if I have the time and find a working HDD I will try a spliced usb cable with external 5v power.  what type of HDD did you use ? 3.5 ? or 2.5 ?

 

@DRAGO4k I also thought it could a software issue, I mean some kind of power limit to prevent issues from too demanding devices. So I tried the very same HDD with the original firmware and the motor failed to spin up, exactly the same way it happens on armbian. I guess that's a limit of the hardware.

 

A thing I noticed is that, while taking the photo above, the box is able to be backpowered from USB: while moving the things to arrange the photo, by the barrel connector slipped outside from the box but the box didn't turn off: the other barrel connector feeding the hdd was backpowering the box via USB

[Sergei Steshenko]

17 hours ago, DRAGO4k said:

@Sergei Steshenko - nobody is doubting you. it just looks like a weird power issue. What type of HDD did you use ? 3.5 ? or 2.5 ?

2.5 inch HDD.

[Sergei Steshenko]

@jock, this is what I found: "Increase disk detection timeout at boot with Linux/Systemd" - https://serverfault.com/questions/938506/increase-disk-detection-timeout-at-boot-with-linux-systemd  :

 

"

I've finally found it! It's of course but a simple kernel parameter, found here https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html

The parameter I was specifically looking for is rootdelay, I had already tried rootwait but apparently that wasn't enough, as it still aborted the wait after 10 seconds. Now it actually does not wait the full 30 seconds specified, but only about 10-15 seconds depending on how long it takes for my disks to show up, so setting a really high value doesn't seem to hurt, although I've only set 30 for my use case, which so far seems to have completely resolved the issue!

You can add it to your kernel boot parameters in Grub or systemd-boot.

Grub: /etc/defaults/grub -> GRUB_CMDLINE_LINUX_DEFAULT="rootdelay=30 quiet"

systemd-boot: /boot/loader/entries/yourentry.cfg -> options rootdelay=30 [other options]

".

 

So, is there 'rootdelay' in /boot/armbianEnv.txt ?

[Sergei Steshenko]

Another related thread: 

  ->

- pay attention to "sleep 5".

[DRAGO4k]

I used a 5v 2.5A Logitech power adapter (so it should be real 2.5A or close enough).

1) the power for the USB devices go through the power management chip and is 0 while the unit is turned off

2) the voltage dropped in a range of 4.3-4.8v under load meaning even 2.5A is not enough for the unit alone.

3) a ~0.20mA load on the usb dropped the voltage to 4.5v during idle.

4) a ~0.60mA load on the usb dropped the voltage to 4.2v during idle.

 

I will probably power this from an ATX PSU and measure the amps and usb load.

 

When i have the time I will test with an actual hdd.

 

[Sergei Steshenko]

Here:  https://iotbyhvm.ooo/boot-up-raspberry-pi-external-hard-disk/  it's stated that 'rootfdelay' is in /boot/cmdline.txt .

[Sergei Steshenko]

@jock,  the following are contents of my /boot/armbianEnv.txt file:

 

"

verbosity=1
overlay_prefix=rockchip
fdtfile=rk3288-xt-q8l-v10.dtb
rootdev=UUID=<whatever>
rootfstype=ext4
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u

".

 

I.e. there is no 'rootdelay'.

[DRAGO4k]

@jock I noticed a 1s where the USBs are powered off after 8s during boot, I suspect it is between first and second stage of the boot process ? I did not had time to add a serial to mine to see what is going on. will continue to debug this when I will have the time. It might be that the usb to sata bridge is powered off and needs a bit of time to initialize.
 

@Sergei Steshenko I think we should find the actual reason if possible and see how we can fix it. Also you can edit the /boot/armbianEnv.txt file and add rootdelay.
As a last point: what you suggested adding a rootdelay (Time to delay before attempting to mount the root filesystem) will not fix "repetitive attempts to reset the HDD with squeaking sound" it will just prolong the wait time and will still fail.

 

PS: ~3A the voltage is 5V as normal. Using 4A to power both unit and hdd leaves 1A for the usb to sata bridge and the HDD itself

 

[Sergei Steshenko]

40 minutes ago, DRAGO4k said:

I used a 5v 2.5A Logitech power adapter (so it should be real 2.5A or close enough).

1) the power for the USB devices go through the power management chip and is 0 while the unit is turned off

2) the voltage dropped in a range of 4.3-4.8v under load meaning even 2.5A is not enough for the unit alone.

3) a ~0.20mA load on the usb dropped the voltage to 4.5v during idle.

4) a ~0.60mA load on the usb dropped the voltage to 4.2v during idle.

 

I will probably power this from an ATX PSU and measure the amps and usb load.

 

When i have the time I will test with an actual hdd.

 

I've checked my 5V 4A power supply. Well, it's fake 4A. With HDD attached voltage drops sometimes to less than 4.5V. It's hard to say what the voltage exactly is - because the HDD squeaks every second or so, and DMM integrates, but there shouldn't be more than 0.5V of voltage drop.

[Sergei Steshenko]

24 minutes ago, Sergei Steshenko said:

I've checked my 5V 4A power supply. Well, it's fake 4A. With HDD attached voltage drops sometimes to less than 4.5V. It's hard to say what the voltage exactly is - because the HDD squeaks every second or so, and DMM integrates, but there shouldn't be more than 0.5V of voltage drop.

 

24 minutes ago, Sergei Steshenko said:

I've checked my 5V 4A power supply. Well, it's fake 4A. With HDD attached voltage drops sometimes to less than 4.5V. It's hard to say what the voltage exactly is - because the HDD squeaks every second or so, and DMM integrates, but there shouldn't be more than 0.5V of voltage drop.

I have also checked my 5V 3A power supply - the same.

[jock]

4 hours ago, Sergei Steshenko said:

@jock,  the following are contents of my /boot/armbianEnv.txt file:

 

"

verbosity=1
overlay_prefix=rockchip
fdtfile=rk3288-xt-q8l-v10.dtb
rootdev=UUID=<whatever>
rootfstype=ext4
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u

".

 

I.e. there is no 'rootdelay'.

@Sergei Steshenko You can add kernel command line parameters using the extraargs argument. They will be appended to the command line as is:

extraargs=rootdelay=30

If you are booting the kernel from the sdcard/emmc and the root filesystem is on the external HDD this may work. Of course if the HDD is suffering power outages (like you're describing), it won't work anyway.

[jock]

4 hours ago, DRAGO4k said:

@jock I noticed a 1s where the USBs are powered off after 8s during boot, I suspect it is between first and second stage of the boot process ? I did not had time to add a serial to mine to see what is going on. will continue to debug this when I will have the time. It might be that the usb to sata bridge is powered off and needs a bit of time to initialize.

 

hmm that's interesting. I guess I should take some care about that. For example the kernel device tree contains these lines

 

Maybe adding regulator-boot-on and removing the pinctrl-* properties from the vcc_host_5v and vcc_otg_5v sections will prevent the USB ports to be powered off

 

5 hours ago, DRAGO4k said:

used a 5v 2.5A Logitech power adapter (so it should be real 2.5A or close enough).

1) the power for the USB devices go through the power management chip and is 0 while the unit is turned off

2) the voltage dropped in a range of 4.3-4.8v under load meaning even 2.5A is not enough for the unit alone.

3) a ~0.20mA load on the usb dropped the voltage to 4.5v during idle.

4) a ~0.60mA load on the usb dropped the voltage to 4.2v during idle.

 

I will probably power this from an ATX PSU and measure the amps and usb load.

 

When i have the time I will test with an actual hdd.

 

1) I guess that there is a mosfet or whatever that controls the power to the USB ports, controlled by GPIO lines. You can see from the piece of the device tree I highlighted previously that GPIO 14 of bank 0 controls the power of the two non-OTG  ports and GPIO 12 of bank 0 controls the OTG port. In theory it could be interesting to find the part on the board, read the signature on it and try to understand how much current it can sink.

2) True, under heavy load the chip and the board can draw quite an amount of current. Definitely an ATX power supply is a good way to benchmark this.

3) and 4) Very interesting! Where did you sample the voltage, I guess near the USB port? Clearly so much voltage drop even with modest load could not sustain any external hard drive.

[Sergei Steshenko]

1 hour ago, jock said:

@Sergei Steshenko You can add kernel command line parameters using the extraargs argument. They will be appended to the command line as is:

extraargs=rootdelay=30

If you are booting the kernel from the sdcard/emmc and the root filesystem is on the external HDD this may work. Of course if the HDD is suffering power outages (like you're describing), it won't work anyway.

"You can add kernel command line parameters" - do you mean to add them to /boot/armbianEnv.txt or I can add them interactively while booting ? If the latter, how do I do this ? I.e. what keys should I press in order to be able to add 'extraargs' ?

[Sergei Steshenko]

I've ordered a 5V 6A power supply in metal enclosure. It typically takes 2 .. 3 weeks for such orders to arrive. If and when the supply arrives and I test it, I'll report my findings and the URL to the item.

 

The supply has voltage adjustment, is also for LEDs, the description claims it underwent burn-in test under 100% load, blah, blah, blah.

 

Ironically the 5V 6A is cheaper than 5V 5A.

[jock]

On 8/1/2019 at 12:31 AM, Sergei Steshenko said:

"You can add kernel command line parameters" - do you mean to add them to /boot/armbianEnv.txt or I can add them interactively while booting ? If the latter, how do I do this ? I.e. what keys should I press in order to be able to add 'extraargs' ?

@Sergei Steshenko yes, add extraargs=... to /boot/armbianEnv.txt to append options to the kernel command line.

 

@DRAGO4k I prepared a debian buster image (kernel is the very latest 5.2.6, u-boot is v2019.04) with the changes to the device tree I mentioned some posts ago. I'm currently using the modified device tree and I see no regressions. You can download the image from here to see if the power down/power up event still happens.

In the meantime I had a session with the serial attached to see why I had issues with my USB-to-SATA adapter. In practice it looks like there is no issue at all: my adapter takes some seconds to initialize. The box just does not enumerate the USB device because it is not ready yet. More of that, I found no evidence of any configurable timeout in u-boot not in the code nor in the environment variables. Eventually it looks like there isn't any issue from the box side, it's just the adapters that expose themselves after a timeout, probably to wait for the SATA disk to fully spin-up.

[martinayotte]

17 hours ago, jock said:

I found no evidence of any configurable timeout in u-boot

Isn't what you wish to set in U-Boot : INITIAL_USB_SCAN_DELAY

 

EDIT: Ouups ! INITIAL_USB_SCAN_DELAY seems to be only for AllWinner SoC ...

But maybe some of this code could be copied to other USB drivers ?

 

EDIT2: Oh ! It seems that there is a more general way to delay on any plateforms in common/usb_hub.c using the env variable "usb_pgood_delay" ...

[Sergei Steshenko]

On 8/5/2019 at 4:58 PM, martinayotte said:

Isn't what you wish to set in U-Boot : INITIAL_USB_SCAN_DELAY

 

EDIT: Ouups ! INITIAL_USB_SCAN_DELAY seems to be only for AllWinner SoC ...

But maybe some of this code could be copied to other USB drivers ?

 

EDIT2: Oh ! It seems that there is a more general way to delay on any plateforms in common/usb_hub.c using the env variable "usb_pgood_delay" ...

Is "usb_pgood_delay" in small letter or in capital ones ?

[martinayotte]

12 hours ago, Sergei Steshenko said:

Is "usb_pgood_delay" in small letter or in capital ones ?

lower case ...

But I didn't try it out ! I've just find it in U-Boot common/usb_hub.c inside usb_hub_power_on() function.

[jock]

Thanks for the finding, I will try to test as soon as I can; unfortunately u-boot on rockchip has no video console, so it requires a serial port access :/

Also armbianEnv.txt is of no use here because the USB detection happens before its parsing.

[martinayotte]

2 hours ago, jock said:

Also armbianEnv.txt is of no use here because the USB detection happens before its parsing.

In such case, then, you could create a patch that will increase default value directly in common/usb_hub.c ...