Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
asus about to publish tinker board kernel sources
#11
I would look at the linux-rockchip git and Armbian (and apparently rockchip yocto) to play with source and have some discussion. Also the Miqi community can be of some help, these boards are all minimalist SBC's around the RK3288.

tx0h, you are correct, you have to comment out the __DATE__ __TIME__ bits to get it to compile. The patch I saw on rockchip commented out that and the line above it. That was necessary to get wifi working on Armbian.
Reply
#12
(05-01-2017, 02:31 AM)tonymac32 Wrote: I would look at the linux-rockchip git and Armbian (and apparently rockchip yocto) to play with source and have some discussion.  Also the Miqi community can be of some help, these boards are all minimalist SBC's around the RK3288.  

tx0h, you are correct, you have to comment out the __DATE__ __TIME__ bits to get it to compile.  The patch I saw on rockchip commented out that and the line above it.  That was necessary to get wifi working on Armbian.

For some obscure reason Asus is very reluctant to publish information about kernel and u-boot sources.
When they want Tinker Board to be a success, then why keep all this info secret?
 
There is a git repo for the Tinkerboard kernel sources, this is what we received upon request: TinkerOS kernel sources
They should publish the used u-boot sources too!
Reply
#13
(05-07-2017, 03:51 PM)gkkpch Wrote: There is a git repo for the Tinkerboard kernel sources, this is what we received upon request: TinkerOS kernel sources

There are some interesting commits:
- removed "upscaling" FHD->UHD behavior (eg. remove FAKE4K)
- full 4k@50hz/60hz will be available after pass VD and EMI testing (eg. enable HDMI2.0)

PS: Hardware (Synopsys DesignWare HDMI IP) is designed for HDMI2.0 and MHL (probably MHL3 with 6Gbit/s per lane) support:

There is dw-hdmi identification:

registers 0-3: 0x20 0xa 0xa0 0xc1

#define DESIGN_ID 0x0000
#define REVISION_ID 0x0001
#define PRODUCT_ID0 0x0002
#define PRODUCT_ID1 0x0003

registers 4-8: 0xbf 0x22 0xc2 0x0

#define CONFIG0_ID 0x0004
#define m_PREPEN BIT(7)
#define m_AUDSPDIF BIT(5)
#define m_AUDI2S BIT(4)
#define m_HDMI14 BIT(3)
#define m_CSC BIT(2)
#define m_CEC BIT(1)
#define m_HDCP BIT(0)


#define CONFIG1_ID 0x0005
#define m_HDCP22 BIT(6)
#define m_HDMI20 BIT(5)
#define m_CONFAPB BIT(1)


#define CONFIG2_ID 0x0006
enum PHYTYPE {
HDMI_TX_PHY = 0x00,
HDMI_MHL_WITH_HEAC_PHY = 0xb2,
HDMI_MHL_PHY = 0xc2,
HDMI_3D_TX_WITH_HEAC_PHY = 0xe2,
HDMI_3D_TX_PHY = 0xf2,
HDMI2_TX_PHY = 0xf3
};

#define CONFIG3_ID 0x0007
#define m_AHB_AUD_DMA BIT(1)
#define m_GP_AUD BIT(0)
Reply
#14
(05-07-2017, 03:51 PM)gkkpch Wrote:
(05-01-2017, 02:31 AM)tonymac32 Wrote: I would look at the linux-rockchip git and Armbian (and apparently rockchip yocto) to play with source and have some discussion.  Also the Miqi community can be of some help, these boards are all minimalist SBC's around the RK3288.  

tx0h, you are correct, you have to comment out the __DATE__ __TIME__ bits to get it to compile.  The patch I saw on rockchip commented out that and the line above it.  That was necessary to get wifi working on Armbian.

For some obscure reason Asus is very reluctant to publish information about kernel and u-boot sources.
When they want Tinker Board to be a success, then why keep all this info secret?
 
There is a git repo for the Tinkerboard kernel sources, this is what we received upon request: TinkerOS kernel sources
They should publish the used u-boot sources too!

right next the kernel sources: https://github.com/TinkerBoard - but I guess you  have found them already ..
Reply
#15
Well I have been running a tinker 24/7 for a few weeks now, i have found it destroys SD cards, think it is writing to them many more times than the raspberry pi does, think the raspberry pi people have tweaked their operating system to have min writes to the SD Card, this ASUS have not done, sd cards that seem to last a long time in the Pi dont last very long in the tinker, so will wait for a new operating system and test that to see if the tinker can be used 24/7 for years like the Pi can be. but it cant be at the moment, the odroid has out performed the tinker on that score, that was started at the same time as the tinker and is still running on its first card, the tinker destroyed 4 sd cards in that time.
Reply
#16
(06-25-2017, 06:02 PM)johnb_summers Wrote: Well I have been running a tinker 24/7 for a few weeks now, i have found it destroys SD cards, think it is writing to them many more times than the raspberry pi does, think the raspberry pi people have tweaked their operating system to have min writes to the SD Card, this ASUS have not done, sd cards that seem to last a long time in the Pi dont last very long in the tinker, so will wait for a new operating system and test that to see if the tinker can be used 24/7 for years like the Pi can be. but it cant be at the moment, the odroid has out performed the tinker on that score, that was started at the same time as the tinker and is still running on its first card, the tinker destroyed 4 sd cards in that time.

What were you doing to destroy the SD Card? What programs was the tinker running?
Reply
#17
(06-25-2017, 06:02 PM)johnb_summers Wrote: Well I have been running a tinker 24/7 for a few weeks now, i have found it destroys SD cards, think it is writing to them many more times than the raspberry pi does, think the raspberry pi people have tweaked their operating system to have min writes to the SD Card, this ASUS have not done, sd cards that seem to last a long time in the Pi dont last very long in the tinker, so will wait for a new operating system and test that to see if the tinker can be used 24/7 for years like the Pi can be. but it cant be at the moment, the odroid has out performed the tinker on that score, that was started at the same time as the tinker and is still running on its first card, the tinker destroyed 4 sd cards in that time.

Treat it as an SD-Drive, and optimize 'fstab' accordingly --use the 'noatime,nodiratime 0 0' parameters for each solid state partition, whether its SD, SSD, or eMMC.

You can use fstab reference-docs for any newer Debian-derivative, but the fstab file location may vary.  On x86 distros, its located in /etc/fstab, but on Armbian, I can't recall --Armbian was the only Linux I used on my Tinker before switching it permanently to Android after attaching a 23" touchscreen.  

Anyway, there are several params that can be used via fstab to control how disc-wear occurs.  Its just a matter of tuning it to your system, whether its an SBC, VM, workstation, laptop, or server.  You can also use fstab to build-in remote file-systems [such as SMB or NFS] so that remote drives mount automatically at boot.  Search Google for "fstab manpage" to get further info on how it all works.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)