Usually in arm arch I think its the device tree that enables things like UARTs. e.g in https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/rk3288-tinker.dts the text:
$this->bbcode_second_pass_code('', '&uart0 {
status = "okay";
};
&uart1 {
status = "okay";
};
&uart2 {
status = "okay";
};
&uart3 {
status = "okay";
};
&uart4 {
status = "okay";
};')
Is enabling all 4 uarts that are defined in https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/rk3288.dtsi
Only one pwm is enabled
$this->bbcode_second_pass_code('', '&pwm0 {
status = "okay";
};')
So will need to check in the rk3288 data sheet which pins that is connected to. Just checked. its pwm2 and pwm3 that use pins H28 and J25 that uart2 is on. pwm0 uses pin H22, so shouldn't clash with uart2.
Oh yes, I checked that the same uart is used in uboot and the device tree, for both they use the uart at 0xff690000 which is uart2. u-boot won't use the pwm ...
[Solved] Asus TB S
Re: Asus TB S
by summers » Tue Aug 07, 2018 4:43 pm
- summers
- Posts: 984
- Joined: Sat Sep 06, 2014 12:56 pm
Re: Asus TB S
by TheSaint » Wed Aug 08, 2018 4:22 am
So they arrange a messy setup 
They (Tinker staff) tell to monitor on UART2, in case of debugging, but in facts they didn't set it to work, because that is off and the pwm2 is on. Just because they like to show off the SBC capabilities, IMHO.
Anyway I understood which way is working and perhaps I route the debug to UART4.
Yesterday, impatiently,I've made this small setup. For the TX is good, but for RX isn't able to detect the level change, this from the converter side. I realized that isn't 3.3V compatible, as it was advertised. I'll wait the new one.
They (Tinker staff) tell to monitor on UART2, in case of debugging, but in facts they didn't set it to work, because that is off and the pwm2 is on. Just because they like to show off the SBC capabilities, IMHO.
Anyway I understood which way is working and perhaps I route the debug to UART4.
Yesterday, impatiently,I've made this small setup. For the TX is good, but for RX isn't able to detect the level change, this from the converter side. I realized that isn't 3.3V compatible, as it was advertised. I'll wait the new one.
- TheSaint
- Posts: 346
- Joined: Mon Jul 23, 2018 7:57 am
Re: Asus TB S
by summers » Wed Aug 08, 2018 8:36 am
Problem with diverting the output to UART4 is that there are several things which will access the uart:
1) the kernel
2) u-boot
3) the boot rom
Now 1) we can redirect with the kernel line "console=..." so its easy, but we can access the kernel messages with "dmesg" anyway, as long as we can boot into an operational system.
For u-boot, the output is set in the config file "CONFIG_DEBUG_UART_BASE=0xff690000" so thats the memory location for uart2. So to change that, we would need to recompile u-boot, and flash it to the disk in the right place. Now we aren't yet sure on how to do that. So thats a difficulty.
For the boot rom, its rom - and its done by rock chip. So we neither see the code, nor have the ability to change it.
So what I'd conclude, is that we are stuck with uart2.
Now sideline onto overlays, I can see from your config that tinker does overlays. I've only come across them with the beagle bone set up (You could see overalys done in the boot.txt I posted for the BBB). Now in the beagle world, overlays used to be done in userland via the kernel. That never used to work well, e.g. if you remove the hdmi from a running operating system, then things tend to complain. So where the beagle world went is via doing overlays by device tree modification in u-boot. The beagle people did this by forking u-boot, and adding a whole lot of code to it to do the overlays. Its not how mainline u-boot does it - that has to be via "ftd apply" which I posted above.
Now what does the tinkerboard do, obvious the tinkerOS does overlays. How though, I don't know. Probably either in kernel, or in an fork of u-boot. Can't say I like either. Anyway yes however you can disable pwm 2 and pwm3. has to be a good idea, as it will mess with uart2. You should also check "dmesg" to see if uart2 comes up ok.
Onto u-boot env variables. They are a bit odd, in mainline u-boot they are set via the "CONFiG_ENV" options e.g. "CONFIG_ENV_IS_IN_MMC=y" says save the env to the MMC. Now usually you would configure where to save with "CONFIG_ENV_OFFSET=" - mainline doesn't do that, which means it would save the env variable to the beginning of the MMC, That is bad I think, its where the partition information is, so writing there would trash the partition table. On the tinkerOS, I searched the image for the env variables - and haven't managed to find them yet. Hence I conclude that the set up on mainline u-boot is slightly broken - which is what the doc says. Also that whats in tinker-OS must have been modified. How we don't know.
Finally on your mod. Not a great way to use a difference voltage device, as it depends on the internal resistance of the uart device. If they are high impedance, then the external resistors won't make a difference. However what the external resistors will do, is to current limit what flows in the wires. Hopefully that should stop anything burning out. Me, I'd probably wait for the 3.3V uart to arrive ...
1) the kernel
2) u-boot
3) the boot rom
Now 1) we can redirect with the kernel line "console=..." so its easy, but we can access the kernel messages with "dmesg" anyway, as long as we can boot into an operational system.
For u-boot, the output is set in the config file "CONFIG_DEBUG_UART_BASE=0xff690000" so thats the memory location for uart2. So to change that, we would need to recompile u-boot, and flash it to the disk in the right place. Now we aren't yet sure on how to do that. So thats a difficulty.
For the boot rom, its rom - and its done by rock chip. So we neither see the code, nor have the ability to change it.
So what I'd conclude, is that we are stuck with uart2.
Now sideline onto overlays, I can see from your config that tinker does overlays. I've only come across them with the beagle bone set up (You could see overalys done in the boot.txt I posted for the BBB). Now in the beagle world, overlays used to be done in userland via the kernel. That never used to work well, e.g. if you remove the hdmi from a running operating system, then things tend to complain. So where the beagle world went is via doing overlays by device tree modification in u-boot. The beagle people did this by forking u-boot, and adding a whole lot of code to it to do the overlays. Its not how mainline u-boot does it - that has to be via "ftd apply" which I posted above.
Now what does the tinkerboard do, obvious the tinkerOS does overlays. How though, I don't know. Probably either in kernel, or in an fork of u-boot. Can't say I like either. Anyway yes however you can disable pwm 2 and pwm3. has to be a good idea, as it will mess with uart2. You should also check "dmesg" to see if uart2 comes up ok.
Onto u-boot env variables. They are a bit odd, in mainline u-boot they are set via the "CONFiG_ENV" options e.g. "CONFIG_ENV_IS_IN_MMC=y" says save the env to the MMC. Now usually you would configure where to save with "CONFIG_ENV_OFFSET=" - mainline doesn't do that, which means it would save the env variable to the beginning of the MMC, That is bad I think, its where the partition information is, so writing there would trash the partition table. On the tinkerOS, I searched the image for the env variables - and haven't managed to find them yet. Hence I conclude that the set up on mainline u-boot is slightly broken - which is what the doc says. Also that whats in tinker-OS must have been modified. How we don't know.
Finally on your mod. Not a great way to use a difference voltage device, as it depends on the internal resistance of the uart device. If they are high impedance, then the external resistors won't make a difference. However what the external resistors will do, is to current limit what flows in the wires. Hopefully that should stop anything burning out. Me, I'd probably wait for the 3.3V uart to arrive ...
- summers
- Posts: 984
- Joined: Sat Sep 06, 2014 12:56 pm
Re: Asus TB S
by TheSaint » Wed Aug 08, 2018 5:31 pm
So we are in a lot of unknown tricks that the Tinker staffs might have done.
The whole bunch seems to be at https://github.com/TinkerBoard/debian_kernel.
$this->bbcode_second_pass_quote('summers', 'b')ut we can access the kernel messages with "dmesg" anyway
The whole bunch seems to be at https://github.com/TinkerBoard/debian_kernel.
$this->bbcode_second_pass_quote('summers', 'b')ut we can access the kernel messages with "dmesg" anyway
You got it
. But the difference is when the kernel won't start and the console will tell the story. And that could be the point it we want to see what Arch kernel doing during boot time $this->bbcode_second_pass_quote('summers', 'F')or the boot rom, its rom
I doubt it is. I rather presume that is a flash, like many MCU have (e.g Arduino). Also I read that TB allows a fastboot, which is probably the way that the first boot stage is written inside the MCU.I hardly guess how much flash there could be, but it might be some 256 Kbytes, at least.
$this->bbcode_second_pass_quote('summers', 'w')e are stuck with uart2.
Not completely, when I disable pwm2, the UART2 is accessible.
$this->bbcode_second_pass_quote('summers', 'H')opefully that should stop anything burning out
Fortunately I didn't damage it, so the resistor are a safeguard against the odd. I received the new converter, with a big disappointment. It does the same like the other. Just the voltage is for 3.3 Volts. But the sensibility is bad. It works just if i cross RX with TX. And that TB doing the same.
I even try to put 1 KOhm resistor between RX and TX, for the converter alone, then it works. That means even with few mA there's no issue, but if I connect to TB, doesn't give anything in both communication directions
Should I put an buffer ?