Jump to content

RK3328 Kernel

Peba

By Peba
in Tinkerboard

 Share

Recommended Posts

Tido

Tido

Posted
Posted

The first time I looked closely to the first picture.

 

This is a really brilliant move from ASUS, an exact copy of the connectors placing and size, combined with a real CPU, twice as much RAM.

If the camera and display connector even have the same ports - hallelujah  :P 

Really neat, the colored GPI/O pins  :thumbup:

 

Brilliant - as long as Rockchip and ASUS send their code upstream.

2
Link to comment
Share on other sites
jernej

jernej

Posted
Posted

Sadly MiQi doesn't seem to be getting the funding it needs, only 2% of goal on indiegogo so far.  :(

 

Yes, their campaign failed, but you can still buy this board here: https://mqmaker.com/product/miqi-2gb-ram-fress-shipping/

 

 

Brilliant - as long as Rockchip and ASUS send their code upstream.

 

SoC used in these two boards is also used in Chromebook, which means that almost all HW has mainline drivers in Linux and U-Boot. However, someone is working on VPU driver, but it should be already usable.

Link to comment
Share on other sites
tkaiser

tkaiser

Posted
Posted

Here's dmesg output from TinkerOS: http://sprunge.us/JYcg

 

So ASUS is either pretty lazy or in the usual 'port and forget' mood (shipping kernel 4.4.16 while 4.4 LTS is already at 4.4.52 in the meantime) and they use well known and boring AP6212 to provide Wi-Fi/BT. So if power setup is identical between MiQi and Tinker Board all that's missing is adding a single line to /etc/modules and BT stuff.

Link to comment
Share on other sites
TonyMac32

TonyMac32

Posted
Posted

I've got a Tinker Board, had it about a week (they were very briefly available on Amazon, actually, as soon as it shipped the page was taken down).  I'm actually posting from it, was running some updates/etc.  It is truly identical to the Pi form factor wise, I slapped it into a Pi case.  I stuck an initial impressions on my blog, but more or less the 4 usb ports are through a hub, the gigabit ethernet is tied directly into the SoC so that makes it's networking amazingly better than the Pi.  Wifi is snappy, especially when considering the "chip-tenna" it's using for an aerial.

 

Tinker OS is horribly unstable in my experience.  The desktop crashes regularly and you have to reboot, or continue your work by switching to another terminal and living with the CLI.  0 graphic acceleration of any kind from what I can see, I have it hooked up to a 4k monitor, it appears to be upscaling a 1080p desktop and then putting a 4k mouse on top of it?  The mouse is nice and crisp (and tiny) and everything else is kind of blurry.  I've seen some noise concerning mainline patches for the Tinker board, hopefully those pan out.  And hopefully someone decides to let us use the graphics subsystem properly.

Link to comment
Share on other sites
jernej

jernej

Posted
Posted
1 hour ago, TonyMac32 said:

The mouse is nice and crisp (and tiny) and everything else is kind of blurry.

 

I'm pretty sure that both of your assumptions are correct.

 

A lot of SoCs have special buffer for mouse pointer which get blended a top of everything else. I'm pretty sure that's the case here too. IIRC I heard that RK3288 supports 1080p max and 4K is just upscaled version of that.

 

About other issues - MiQi board with same SoC has definetly working GPU and VPU drivers, so I think this is only temporary issue.

Link to comment
Share on other sites
TonyMac32

TonyMac32

Posted
Posted

That's interesting.  I wasn't sure what to make of the inconsistent "upscaled from 1080" notes I've found here and there, and got more confused with the entire mouse thing.  There's very little in the way of strange hardware physically on the board, although there is an 8k EEPROM on the bottom side next to the SD card that I can't really account for.  Power wise it's using a Rockchip RK808-B, which should mean the SoC has access to battery management and a real time clock, if everything is broken out.  To that end there are 2 connections available between the HDMI and Micro-USB, I haven't been brave enough to probe them fully, I'd assume one is purely a 5V in, the other may be for a battery or a hardware reset switch.  I'm looking over the datasheets and the (far from complete) schematic.

 

[edit]  There is a USB charge monitor onboard:  http://www.ti.com/lit/ds/symlink/bq24392.pdf

 

DSC_0637-768x576.jpg

Link to comment
Share on other sites
Igor

Igor

Posted
Posted

I am interested if Armbian for MiQi is working out of the box?

 

For kernel wise you might need to add this parameter to armbianEnv.txt to gain proper functionality: 

fdt_file=rk3288-miniarm

Miniarm was "secret" code for this board. In case you can't boot, we need to rebuild boot loader.

Link to comment
Share on other sites
Igor

Igor

Posted
Posted

Thank you, but I am not sure I need another board / new costs. Recently I denied two board donations, from board makers, with this (simplified) explanation: "We can't accept more boards, since we are small amateur group, overwhelmed with work / boards.". If they still want the board here, project is open - they can add it ... or try to make a deal.

1
Link to comment
Share on other sites
TonyMac32

TonyMac32

Posted
Posted

I hacked an adapter for my FTDI Friend together, I tried the default MiQi image, there is nothing on the serial port.  I assumed 115200 8N1, is that correct?

 

The output from the ASUSimage looks like this: 

cap 2048
chipsize_mb=1024
chipsize_mb=1024
size_mb = 2048


U-Boot 2016.09-rc1 (Feb 23 2017 - 17:59:51 +0800)

Model: Miniarm-RK3288
DRAM:  chipsize_mb=1024
chipsize_mb=1024
size_mb = 2048
2 GiB
MMC:   dwmmc@ff0c0000: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   Net Initialization Skipped
No ethernet found.
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
reading /extlinux/extlinux.conf
140 bytes read in 6 ms (22.5 KiB/s)
Retrieving file: /hw_intf.conf
reading /hw_intf.conf
109 bytes read in 4 ms (26.4 KiB/s)
hw_conf.valid = 1
hw_conf.i2c1 = 1
hw_conf.i2c4 = 1
hw_conf.spi2 = 1
hw_conf.pwm2 = 1
hw_conf.pwm3 = 1
hw_conf.uart1 = 1
1:      kernel-4.4
Retrieving file: /zImage
reading /zImage
6731160 bytes read in 497 ms (12.9 MiB/s)
append: earlyprintk console=tty1 root=/dev/mmcblk0p2 rw init=/sbin/init uboot_version=2016.09-rc1
Retrieving file: /rk3288-miniarm.dtb
reading /rk3288-miniarm.dtb
45592 bytes read in 8 ms (5.4 MiB/s)
## Flattened Device Tree blob at 01f00000
   Booting using the fdt blob at 0x1f00000
   Loading Device Tree to 1fff1000, end 1ffff617 ... OK

Starting kernel ...

 

Link to comment
Share on other sites
Igor

Igor

Posted
Posted

Thank you both for trying. This is how we usually begin and sometimes it just work :) According to this (supposedly working) recipe, we don't miss anything regarding booting ... or do we? We are using mainline u-boot, where things could be changed ... but usually you get something on serial. I can switch to this u-boot source: https://github.com/rockchip-linux/u-boot and we try again.

Default MiQi image might not work and at least we have a confirmation now. Good.

Link to comment
Share on other sites
TonyMac32

TonyMac32

Posted
Posted

Looking through the source, the tinker_rk3288.h in the build directory of what I built vs the one at Rockchip linux has a correction on the boot target device number from func(MMC, mmc, 0) to  func(MMC, mmc, 1) I could see it stalling the boot, but no serial out?  Apparently these were originally configured with an eMMC...

https://github.com/rockchip-linux/u-boot/commit/d57b7e1f6707ee5e834e0b2c9ceeaf558455ff4b

If I change this in my source files and rebuild, will it be preserved or will the build replace it with the original?  (noob question, sorry)

 

[EDIT]   Found the script option to turn off checkout.  Trying it.

 

[EDIT 2]  I'm afraid that single adjustment didn't fix it.  It's time to sleep for me, I'll be back later. ;-)

Link to comment
Share on other sites
TonyMac32

TonyMac32

Posted
Posted

Pulled out the hex editor to get a closer look at the bootloader to see if it was putting everything where it belongs, and I figured out why I can't see serial terminal, it's on UART2 in this build instead of UART1 like on the ASUS build.  So that explains that mystery.  I'm sure the sources could have told me that, but somehow the hex editor was easier to follow...  I also see references to the now-gone eMMC, so it's probably trying to boot that and hanging.

 

Can't get the build script to give me serial 1 instead of serial 2, but I did change the U-Boot source to the Rockchip Linux one, and I made an even more interesting adapter to ttyS2 and got this: 

U-Boot SPL 2017.03-rc3-armbian (Mar 14 2017 - 23:21:19)

 

It hung right away just like the mainline, I'm learning my way around to see if it's a device number issue, I'm still seeing the dwmmc@ff0f0000 (that's the eMMC address) popping up in the binary (less than with mainline), I haven't figured out where to turn that off if it's being passed as a parameter somewhere.

 

 

1
Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept