Jump to content

Tinkerboard hardware settings


meres5

Recommended Posts

Hi out there!

 

F.Y.I.

 

I've tried a lot of things to customize the kernel for Tinker Board on

32-bits host platform, but finally I gave it up.

Instead other messy things, I followed the armbian instructions exactly,

and successfully created an Armbian_5.32_Tinkerboard_Debian_jessie_default_4.4.76.img

using the comile script on the recommended Ubuntu host.

 

Unfortunately the resulted image does not boot:

 

root@eepc:~# ttysh /dev/ttyUSB0 -s 115200

U-Boot SPL 2017.07-armbian (Jul 18 2017 - 17:40:48)
Returning to boot ROM...

U-Boot 2017.07-armbian (Jul 18 2017 - 17:40:48 +0200)

Model: Tinker-RK3288
DRAM:  2 GiB
MMC:   dwmmc@ff0c0000: 1
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Model: Tinker-RK3288
Net:   eth0: ethernet@ff290000
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
Found U-Boot script /boot/boot.scr
1446 bytes read in 67 ms (20.5 KiB/s)
## Executing script at 00000000
U-boot loaded from eMMC
106 bytes read in 57 ms (1000 Bytes/s)
43877 bytes read in 124 ms (344.7 KiB/s)
** File not found /boot/uInitrd **
** Unrecognized filesystem type **
** File not found uInitrd **

Well, I made that missing uInitrd using mkimage, and TaDaaaa! It worked!

 

During the build procedure I choose Tinker Board, choose to customize the kernel (menuconfig,

to unleash all of all serial ports of Rockchip), and choose the server version.

All other things remained as is.

 

Probably the last mkimage step is somehow missing from the procedure.

 

Regads,

M5

 

Link to comment
Share on other sites

Hi again!

 

Unfortunately there is an Ooops with UART4 on Tinker Board.

 

From the inside view everything is OK, but there is no TX/RX on real pins

on the boards connector.

 

In case of linaro it was a matter of altering the configuration in

the boot directory, turning the competitive device - e.g. PWM - off.

 

In case of UART4 the competitor is SPI0...

Is anybody there who knows how to deal with that in case of armbian?

 

Regards,

M5

Link to comment
Share on other sites

Just now, meres5 said:

Is anybody there who knows how to deal with that in case of armbian?


Currently, by decompiling dtb, edit and compiling back.


https://docs.armbian.com/User-Guide_Allwinner_overlays/

We recently finished this for Allwinner boards and it needs to be ported elsewhere to have some unified way of manipulating hw settings. Any help on this is welcome.

Link to comment
Share on other sites

Thank you for the quick reply!

 

Your compile script is amazing!
Your kernel compilation was spreaded across all of CPU cores!
The whole procedure took only half an hour!

Now back to the case...
Huhhhh!
So it makes me run the gountlet further...

Well, I've logged in, (it's cute, picture attached)

then checked the device tree in the running system.

Here are the results:

root@tinkerboard:/# cat /sys/firmware/devicetree/base/serial@ff1c0000/status
okay

then

root@tinkerboard:/# cat /sys/firmware/devicetree/base/spi@ff110000/status
disabled

Seems OK.

 

Well, time to port GPIO_API (gpio and wiringPI with ASUS patch) in order
to check how GRF_GPIO5B_IOMUX and others are going.
(according to RK3288 TRM, Chapter 7 General Register Files (GRF))
And I will see what...

These new kernel architectures are not familiar to me.

It was a decade or so when I wrote device drivers for our FPGA based PCI cards.

(Linux/Windows)

 

Anyway, if you point the direction to the iomux control stuff (maybe called overlays) in the kernel source,

used by your compile script, I will have a look around.

 

Regards,
M5

worked.png

Link to comment
Share on other sites

Just now, meres5 said:

Now back to the case...


I moved affected posts to a new topic in right place - Rockchip sub forum. 

 

Overlays help to handle already defined functions, but here this is not the case since overlay support is not done. I am also not very familiar with default settings on this board. Don't have one and in general, don't work much with Rockchips.

Link to comment
Share on other sites

Igor, thank you again.

 

I've just realized that the kernel in your pretty neat bundle is maintained by MiQi,

one of whom started the Rockchip thread.

 

I hope someone might help with the issue concerning the pin multiplexing of this RK3288 SoC.

Until then I will do as mentioned in the post above.

 

My mission objective is to bring UART4, a.k.a. uart4exp, a.k.a ttyS4 alive

on Tinker Board's pin-header, pins 13 and 15 (166, 167 SoC) - in a timely manner.

 

After customizing the kernel, I have ttyS4 alive, but the UART (at ff1c0000) signals seem

not routed to the header pins - probably due to the wrong IOMUX settings

at GRF_GPIO5B_IOMUX.

(IO directions, drive strength, etc... might be a concern either)

 

Regards,

M5

Link to comment
Share on other sites

Hi there again,

 

meanwhile I've build gpio api successfully (with ASUS patch, enclosed).

The result of "gpio readall" is quite confusing.

We see the settings as they left by the kernel - it is very unlikely that other

player altered them.

 

1. SoC pins 164, and 165 are dedicated to UART's RTS,CTS - kicking off SPI0CLK, and SPI0CSN0.

   That means no SPI0 functionality at all, but we have UART4 RTS/CST hardware handshake.

 

2. SoC pins 166, and 167 is used as GPIO output, killing both (SPI0 and UART4) - just for sure :-) :-) :-)

 

Note that these things reported by "gpio readall" seems adequate for me,

from two point of views:

 

1. I've checked the source wiringPi.c against the Technical Reference Manual (TRM) of RK3288,

    and played with the API under linaro (ASUS stuff)

 

2.  The results seems WYSYWIG - that is:  other three UARTS are OK in real.

    (hardware handshake signals were not tested, because we won't need them)

 

Regards,

M5

gpio_readall.png

Link to comment
Share on other sites

I would prefer to implement device tree overlays, however I'm unfamiliar with how it works and would hate to break something. 

 

As far as the GPIO library, I have been pondering whether Armbian should adopt a specific library and implement it across all boards for consistencies sake.  Obviously every board has different I/O, but some commonality would be good, and having it available in the configuration utility would be even better.  

Link to comment
Share on other sites

Hi!

 

I've run through the gauntlet, and survived!
ttyS4 is now working like a charm!

 

As I mentioned before, from the device side all of all UART's
were OK (after compiling the customized kernel - as per the book).

But in case of these SoC's, the pin-count is limited, so they are
multiplexing several device-signals into a single poor pin -
conquering functions each other.

Its is up to you to chose: SPI? I2C? generic GPIO? UART? etc...
My opinion is that this mess is not really the kernel's business.

I think the device-tree stuff is closing to Windows registry.

 

The kernel should bring up the configured devices on-chip,
including their pin mux setings, and let the user(-space) decide
later which device to put in charge in case of a conflicting
IO pin.

Although this method might surprise an I2C device to receive
UART serial data on its clock input. :-(
Anyway, the last probed should win....

 

Therefore, it would be fine to enable/disable them individually during
the kernel configuration, and issue only a warning when configured
devices are collided on a certain pin.

 

In most cases, the system images (available for download) are
created by qualified personnel - probably they know what they do.
It is a nightmare to reproduce the constellation for building a
system properly for a noob - so this kind of collision won't be
a real problem :-) :-) :-).
I think it is unnecessary to made a complicated thing more complicated..

 

Anyway, here's how I've gone through:

 

1. Seeing the list of "gpio readall", I thought that it'll be as easy
   as pie - just set the pins from OUT to SERL using the tool.
   But unfortunately, SERL (or SERIAL) is a patch from ASUS -
   and on the the read side only :-(

2. I've tracked down how they gather those information, and how they set the pin function
   to GPIO.
   Taking "asus_set_pinmode_as_gpio" function in wiringPi.c as a starting point, I wrote
   "asus_set_pinmode_as_uart" :-)
   
The code snippets:

/**/
#define selpinfnc2( pin, reg, val )               \
        csr = *(grf+(reg)/4);                     \
        printf("before=%.8x\n", csr);             \
        csr &= 0x0000ffff;                        \
        csr &= (~(0x03LU<<(((pin)%8)*2)));        \
        csr |= ( (0x03LU<<(((pin)%8)*2+16)));     \
        csr |= ( (((val)&0x03LU)<<(((pin)%8)*2)));\
        printf("after.=%.8x\n", csr);             \
        *(grf+(reg)/4) = csr
/**/
#define selpinfnc4( pin, reg, val )               \
        csr = *(grf+(reg)/4);                     \
        printf("before=%.8x\n", csr);             \
        csr &= 0x0000ffff;                        \
        csr &= (~(0x0fLU<<(((pin)%8)*4)));        \
        csr |= ( (0x0fLU<<(((pin)%8)*4+16)));     \
        csr |= ( (((val)&0x0fLU)<<(((pin)%8)*4)));\
        printf("after.=%.8x\n", csr);             \
        *(grf+(reg)/4) = csr
/**/
void asus_set_pinmode_as_uart( int pin )
{
unsigned long csr;
switch(pin)
   {
       //GPIO5B
       case 160 :
       case 161 :
       case 162 :
       case 163 :              
           selpinfnc2( pin, GRF_GPIO5B_IOMUX, 1 );
           break;
       case 164 :
       case 165 :
       case 166 :
       case 167 :
           selpinfnc2( pin, GRF_GPIO5B_IOMUX, 3 );
           break;
.... etc ....

(Note that's not my style, except the macros...)

 

3.  I wrote a userspace app called "serpins", using the
   hacked wiringPi lib to turn those pins back from the dark side:

 

#include <wiringPi.h>
int main (void)
{
wiringPiSetupGpio();
//pinMode (164, SERIAL) ;
  pinMode (166, SERIAL) ;
  pinMode (167, SERIAL) ;
//pinMode (165, SERIAL) ;
//pinMode (238, SERIAL) ;
//pinMode (224, SERIAL) ;
//pinMode (160, SERIAL) ;
//pinMode (161, SERIAL) ;
//pinMode (162, SERIAL) ;
//pinMode (163, SERIAL) ;
//pinMode (239, SERIAL) ;
//pinMode (223, SERIAL) ;
}

And TaDaaa!
It worked!

 

Of curse it would be better to port gpio tools
to armbian supported SoC's properly...

 

Thank you for your time, and regards,
M5

 

p.s.
BTW, do you know how to kill sit0, and dummy0 from the
network interfaces permanently?

 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines