Linux on NTV6

[liftoff-sr]

I have 4 of these nagrace 3288 boxes. I can only get one USB port to work while running linux, the one nearest to the RJ45. (BTW Android is not appropriate for me.)

I have run the firefly linux on this in the form of two linux releases separated in time by 6 months, and on 3 of my 4 nagrace boxes, and in all test cases only one USB port works.

Is there a power on GPIO line that needs to be switched on to the usb hub chip? I also asked that I receive the linux kernel configuration files so I can experiment with kernel recompiles. This would be expected according to the GPL v. 2 license under which the linux binaries are being distributed.

I would also like to see a repo be setup for the nagrace linux kernel, again, according to the GPL v. 2.

Again, Android is of no interest to me.

[mo123]

I have 4 of these nagrace 3288 boxes. I can only get one USB port to work while running linux, the one nearest to the RJ45. (BTW Android is not appropriate for me.)

I have run the firefly linux on this in the form of two linux releases separated in time by 6 months, and on 3 of my 4 nagrace boxes, and in all test cases only one USB port works.

Is there a power on GPIO line that needs to be switched on to the usb hub chip? I also asked that I receive the linux kernel configuration files so I can experiment with kernel recompiles. This would be expected according to the GPL v. 2 license under which the linux binaries are being distributed.

I would also like to see a repo be setup for the nagrace linux kernel, again, according to the GPL v. 2.

Again, Android is of no interest to me.

Hi
You can use the standard rockchip_defconfig file to compile a kernel.
The USB ports not working is a GPIO pin configuration in the resource.img file or rk3288.dts file, you can extract it from the resource.img file and build a new resource.img file.
Android & Linux config files are the same except for Linux, you can add the following to the defconfig file
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
You can also use UGOOS Xubuntu 15.04 then all USB ports will work.
You can send me your resource.img,rk3288.dts file so I can check foe the USB problem if do don't get it right.

[liftoff-sr]

Thanks mo123,

That was very helpful. Candy Feng at Nagrace said to try the UGOOS 15.03 for the UT3S. I downloaded that and used resource_tool to extract the rk-kernel.dtb file. And I did the same for the failing firefly linux image (which causes only one USB port to operate.) Then I decompiled to *.dts both trees, and did a file compare. And they are identical. I thought I would merely replace the resource.img file after loading the
Firefly-RK3288_Ubuntu14.04_201501271612.img file. However, we cannot expect that to work given that both resource.img images are the same.
Was Candy wrong about which UGOOS machine is compatible?

Attached is the *.dts file in a zip wrapper (so it could be attached to this post).

You seemed to be knowledgeable about a USB tweak.... and I very much need your help.

TIA

[mo123]

Thanks mo123,

That was very helpful. Candy Feng at Nagrace said to try the UGOOS 15.03 for the UT3S. I downloaded that and used resource_tool to extract the rk-kernel.dtb file. And I did the same for the failing firefly linux image (which causes only one USB port to operate.) Then I decompiled to *.dts both trees, and did a file compare. And they are identical. I thought I would merely replace the resource.img file after loading the
Firefly-RK3288_Ubuntu14.04_201501271612.img file. However, we cannot expect that to work given that both resource.img images are the same.
Was Candy wrong about which UGOOS machine is compatible?

Attached is the *.dts file in a zip wrapper (so it could be attached to this post).

You seemed to be knowledgeable about a USB tweak.... and I very much need your help.

TIA

I wonder if the linux resource.img rk3288.dts file is not inside the Linux boot image(the image you flash to recovery partition to make Linux boot)
Try to decompile the boot.img flashed to recovery partition or linux_boot partition and see if there is not another secondboot or small 100KB file inside.
Rename this file to resource.img, then try to decompile.
Maybe Linux uses it's own resource.img instead of the Android one that is flashed to resource partition.

I think that is the problem, Linux uses different settings for USB than for Android.
You will also see for Mainline Linux with kernel 4.x version, the dts file is merged to the end of the kernel and is not inside resource.img or linux boot.img
You can read the wiki for Mainline Linux on Firefly wiki website how that also works.

[liftoff-sr]

A file with a dts extension would be a device tree source file. That would not be on the flash in any case. The *.dtb file would be, which is the compiled form. If you look at firefly's 3.10 linux tree, and build target firefly-rk3288.img, then you see that DTC gets invoked. After deleting the *.dtb file from the build, and re-running it, I get this:

$ ./build-kernel.sh
CHK include/generated/uapi/linux/version.h
CC scripts/mod/devicetable-offsets.s
CHK include/generated/utsrelease.h
make[1]: 'include/generated/mach-types.h' is up to date.
GEN scripts/mod/devicetable-offsets.h
HOSTCC scripts/mod/file2alias.o
CALL scripts/checksyscalls.sh
HOSTLD scripts/mod/modpost
CHK include/generated/compile.h
DTC arch/arm/boot/dts/firefly-rk3288.dtb
GEN drivers/video/rockchip/screen/lcd.h
Kernel: arch/arm/boot/Image is ready
LZO arch/arm/boot/compressed/piggy.lzo
AS arch/arm/boot/compressed/piggy.lzo.o
LD arch/arm/boot/compressed/vmlinux
OBJCOPY arch/arm/boot/zImage
Kernel: arch/arm/boot/zImage is ready
Image: kernel.img is ready
Pack to resource.img successed!
Image: resource.img (with firefly-rk3288.dtb logo.bmp) is ready
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
make[1]: 'include/generated/mach-types.h' is up to date.
CALL scripts/checksyscalls.sh
CC scripts/mod/devicetable-offsets.s
GEN scripts/mod/devicetable-offsets.h
HOSTCC scripts/mod/file2alias.o
HOSTLD scripts/mod/modpost
Building modules, stage 2.
MODPOST 2 modules
INSTALL drivers/gpu/arm/midgard/mali_kbase.ko
INSTALL drivers/media/usb/gspca/gspca_main.ko
DEPMOD 3.10.0


If I then use resource_tool on that resource.img file, I get rk-kernel.dtb, so apparently the linux kernel Makefiles are renaming the *.dtb file as it is tucked into resource.img.

Summary: I do not follow your train of thought and have no evidence of a *.dts file and none starting with a name of rk3288
in any runtime partition. Also, resource.img seems like it would need to come from the linux build tree, unless it was identical to the one for android. The device tree is in there, most certainly as rk-kernel.dtb.


So my problem remains: the usb port closest to the HPH hdmi connector does not work while running linux.

If I attach a device to that port after boot, I see a message indicating that a usb driver could not find something needed in the device tree or that it does not know where the device tree is. I think I will try upgrading uboot next, it is what loads the device tree blob.

[liftoff-sr]

Here is the dmesg when I plug a mouse into this USB port:

# dmesg
[ 3867.050775] rk_ehci_hcd_enable, enable host controller
[ 3868.989266] rk_ehci_hcd_enable, disable host controller
[ 3869.018799] rockchip_ehci_host ff500000.usb: remove, state 1
[ 3869.018863] usb usb1: USB disconnect, device number 1
[ 3869.040545] rockchip_ehci_host ff500000.usb: USB bus 1 deregistered
[ 3869.040619] rockchip_ehci_host ff500000.usb: Fail to get reset control from dts
[ 3869.040701] rockchip_ehci_host ff500000.usb: Rockchip On-Chip EHCI Host Controller
[ 3869.040781] rockchip_ehci_host ff500000.usb: new USB bus registered, assigned bus number 1
[ 3869.051746] rockchip_ehci_host ff500000.usb: irq 56, io mem 0xff500000
[ 3869.067975] rockchip_ehci_host ff500000.usb: USB 0.0 started, EHCI 1.00
[ 3869.068147] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 3869.068182] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 3869.068211] usb usb1: Product: Rockchip On-Chip EHCI Host Controller
[ 3869.068238] usb usb1: Manufacturer: Linux 3.10.0 ehci_hcd
[ 3869.068263] usb usb1: SerialNumber: ff500000.usb
[ 3869.069325] hub 1-0:1.0: USB hub found
[ 3869.069378] hub 1-0:1.0: 1 port detected
[ 3870.986766] rk_ehci_hcd_enable, enable host controller

I will look for that hi-lighted text now in the source.

The influence that Android has on a Linux install for these boxes is very disappointing. Many of the tools are windows centric, and I don't use that.
At least Firefly has made an attempt at a wiki for linux support. I am not happy with this architecture, mostly due to support.

Why people think I'd want to run Android on this box is a mystery to me. I can watch cartoons on my TV.

[liftoff-sr]

Upgrading to uboot version RK3288UbootLoader_V2.19.01.bin

made no difference. The dmesg is still the same. Fail to get reset control from dts

# lsusb does not show the new USB mouse. That same mouse plugged into the other USB port works and is known to lsusb.

I will need more help, or will need to return these four units to Nagrace. I could spend more time on it, but my time is too valuable.

[liftoff-sr]

OK, I got it working by individually flashing the resource.img partition, rather than using the entire update.img file with update_tool. IOW, update_tool with update.img did not work, neither for UGOOS nor for HPH, nor for Firefly linux update.img images.

When I used the HPH standalone (non-update.img-embedded) resource.img with rkflashkit (after update_tool and update.img), then it works. Using the standalone one from others did not work, and did not even boot. So the HPH resource.img file, i.e. the *.dtb, is unique to that machine.

So one of two things are true:

1) update_tool is not happy with the format of update.img and is burning a bad resource.img partition or skipping it, or

2) update.img has a bad resource.img in it, one that looks reasonably OK, but does not have either host nor ehci USB reset symbols in the *.dtb. This would mean that the download's standalone resource.img file is different than the one embedded in the update.img file. Only way this happens if the standalone one changed after the update.img build.

I suspect 2) is more likely.

The non-ehci USB port (host1) would also not be reset with the bad rk-kernel.dtb, according to dmesg, however for some reason that did not keep that port from working. Doing a decompile on the bad rk-kernel.dtb clearly showed that these USB reset symbols were missing:

otg_ahb
otg_phy
otg_controller
host1_ahb
host1_phy
host1_controller
ehci1_ahb
ehci1_aux
ehci1_phy

See linux source file drivers/usb/dwc_otg/usbdev_rk32.c. I was taken to that file from the output of the dmesg failure message text.

All this is probably a direct result of doing all the build stuff on Windows, without a reliable, reproduce-able build script. It seems mickey mouse to me to be candid.

Any hardware vendor assembling these ROMs on windows or from a non-scripted environment is an amateur.

[mo123]

This is very old firmware but it's dual-boot Linux made for HPH.

https://drive.google.com/file/d/0B1UeinqYRJ-tTWJyQ09rRXZaWWc/view

Maybe you can see something in it's dts file?

[RISCy Dude]

Is there some reason the NTV6 won't run fine on Ugoos' 15.04 SD Boot version? Since all USB ports on my UT3 work using this, what keeps the NTV6 from successfully running the same thing without modification? Or for that matter, the standard install of Ugoos' 15.04.
Just curious.

[mo123]

Is there some reason the NTV6 won't run fine on Ugoos' 15.04 SD Boot version? Since all USB ports on my UT3 work using this, what keeps the NTV6 from successfully running the same thing without modification? Or for that matter, the standard install of Ugoos' 15.04.
Just curious.

UGOOS Xubuntu & SD Card version work great on NT-V6.

But I think he wants to make his own kernel & resource.img and then don't get the OTG USB port working on Firefly Lubuntu that he tests.
He says the dts file of Firefly & UGOOS is the same so he doesn't understand why on Firefly Lubuntu the OTG USB doesn't work.
But I don't see how that is possible since Firefly also has VGA, serial connection and other ports settings in it's resource.img(dts file) while UGOOS doesn't have it.
I can only think that it then must be a driver or setting in the Linux_boot.img or Linux RFS of Firefly Lubuntu that is too old or not the same as UGOOS's.
There might be a second resource.img just for Xubuntu in UGOOS firmware perhaps attached to the kernel in Linux_boot.img.

[liftoff-sr]

Hi RISCy_Dude:

If the schematics are the same between two boards, then they should run the same software. I have no information on schematics for any of these boards except the Firefly. No one is obligated to provide their schematics unless theirs is a derivative under some kind of upstream license which requires that the derivative be freely open and available.

This kind of license is actually in effect on the software. And in my very learned opinion, Nagrace is in violation of the GPL v2 for linux, and Firefly is not. Firefly has distributed their source code according to the license. The device tree source code is part of the linux kernel, and so is covered under the GPL v2 as well as other source files in the linux source tree.

It is the combination of the executable kernel binary and the device tree blob that establish the software behaviour. The device tree is basically a lookup table for the addresses of peripherals, addresses of GPIO pins, clockrates, etc. The linux binary will use what it finds in the device tree blob. To use a metaphor, the software could say go out the door, and the device tree blob which tell you either front door or back door.

Since I came into the RK3288 with a whole bunch of experience on other platforms, it took very little time to come up to speed. Yesterday I went through uboot source to find the exact code which loads the device tree blob. This is why I knew at 100 % confidence where it is loaded from on my machine. However, this was a waste of my time, even though I came to a proper solution. This waste would have been avoided had Nagrace been in compliance with the GPL. I could have simply looked at the source to their device tree blob, which is compiled by the device tree compiler from source code.

And I could have compared their device tree source to the one used by Firefly or UGOOS to answer your question with 100% confidence. Instead, I had to use the device tree compiler in "decompile" mode and essentially fend for myself. This is what the GPL v2 was designed to prevent, it is largely to protect both users of the software and the developers of the software, although each are protected from different things.

All it would take for Nagrace to come into compliance with the GPL v2 is for them to provide a repo some place or link to one along with a version tag, for each binary distribution that they provide. Or they could offer a tarball snapshot for each distribution (=revision).


Hi mo123:

The USB port which was not working, was the ehci port, see line 555 of current 3.10 linux from firefly, file drivers/usb/dwc_otg_310/usbdev_rk32.c

I have not got around to using the OTG port while running linux. I do appreciate that on Nagrace it is full sized, so if it is truly OTG it should be able to play either HOST or DEVICE roles well. For maintenance I would probably come in via ssh and do updates that way over my network.

Yes, I probably will make my own ROM now. I am intrigued by Ubuntu Touch for use in my kitchen, especially if I can also use a real keyboard. WIth Android I could not use a real keyboard and have it recognize the enter key. So Android is permanently off the table for me, I don't even like it on my phone, although I would like iPhone less because of the closed nature of its provider.

I am very impressed with what the company behind Ubuntu has been doing lately.

Anyone know if Touch is running on these boards yet?

[liftoff-sr]

mo123:

Re: HPH-RK3288-Android-Ubuntu_20140924.rar

The standalone resource.img file in this archive is the one that worked for me. Extracting rk-kernel.dtb and decompiling it shows the symbols I mentioned. I am suspicious however that the resource.img file in the envelop file update.img is not any good. I can verify this if this is of help to you. (If so, it points out a bad build methodology on the part of the person who prepared the archive *.rar.)

[mo123]

Hi liftoff-sr
Here is Nagrace dts file for Lollipop kernels only.
It differs tremendiously from the file you uploaded.
The USB,OTG names are different and use different pins.
It is for use with Lollipop kernels, the Firefly one might work.
I asked Firefly to update their sources on Bitbucket because it's very old, but they didn't yet.

The HPH-RK3288-Android-Ubuntu_20140924 dts should be used with KitKat kernels only.

I think there is a problem with Firefly sources not being up to date thus making the LED light and USB ports not working correctly with other devices dts's.

I don't think Ubuntu Touch is that easy to port otherwise someone will have done it already.

[liftoff-sr]

Hi mo123:

A lot of "intent" is lost from the original device tree source when coming from the blob to source via a decompile. (Although I think a recompile of this decompile would produce an identical blob.) The original source consists of a number of included (nested) source files for organizational structure.

Off hand, the two decompiled sources are not that far off, most of the deltas are those phandles which as I recall are pointers to other places in the same file, relative offsets. In the original source they are named offsets, in the decompiled source they are numeric. So they can be omitted from a conceptual compare.

Touch seems to want GPU support or such. Don't know if that is a 2d or 3d requirement. I thought some of that was in place now with the mali kernel patch. I will take a look at it. Touch claims to use libhybris so we know that's been done before on these RK3288s. I think I will start by producing a baseline Ubuntu 15.10 headless server image, onto which any UI can be installed. The MATE UI is also worth looking at, and if we can get to these various places with a single package install command (and associated dependencies coming in automatically), this leads to a lot of value starting from a bare baseline.

Linux package management is one of the primal values of using Linux, so its a feature I'd like to use to our advantage.