Baudrate on console

Moderators: mdrjr, odroid

Baudrate on console

Unread postby mboehmer » Mon Nov 20, 2017 5:14 am

Hi guys,

I have a problem with setting the baudrate of serial console of the C1+: I need to go down to 9600 (or similar slow), as the C1+ will have a long serial line here.
I tried to change the options in the boot.ini, as well as in the env settings of Uboot.

Nothing works.

The baudrate stays stable on 155200.

Can anyone please give me a hint on how to get this setting changed?

Thanks in advance, Michael
mboehmer
 
Posts: 12
Joined: Thu Nov 27, 2014 9:00 pm
languages_spoken: english, german
ODROIDs: U3+

Re: Baudrate on console

Unread postby odroid » Mon Nov 20, 2017 12:00 pm

The UART console parameter seems to be badly hard-coded in the kernel side. :(
https://github.com/hardkernel/linux/blo ... #L845-L850
You have to modify the source code and build the kernel.

If you need to change u-boot terminal speed too, you have to change the u-boot source code too.
User avatar
odroid
Site Admin
 
Posts: 25317
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English
ODROIDs: ODROID

Re: Baudrate on console

Unread postby mboehmer » Mon Nov 20, 2017 5:59 pm

Thanks for your answer.
Can you point me to the u-boot sources, too?

Is there a step-by-step instruction on how to get both things compiled and installed?
mboehmer
 
Posts: 12
Joined: Thu Nov 27, 2014 9:00 pm
languages_spoken: english, german
ODROIDs: U3+

Re: Baudrate on console

Unread postby odroid » Mon Nov 20, 2017 6:16 pm

Refer this link to build it natively(on the board).
https://wiki.odroid.com/odroid-c1/os_im ... nel_source

We will try to find where should be modified in u-boot code tomorrow.
User avatar
odroid
Site Admin
 
Posts: 25317
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English
ODROIDs: ODROID

Re: Baudrate on console

Unread postby mboehmer » Tue Nov 21, 2017 4:29 pm

Some remarks so far:

- building U-Boot as described in the link fails on Odroid C1:

Code: Select all
ld  -r -o /root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/libaml_meson.o  /root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/cpu.o /root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/timer.o /root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/reset.o /root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/board.o /root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/serial.o /root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/syslib.o
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/reset.o: In function `__raw_writesb':
/root/BUILD/u-boot/build/include2/asm/io.h:79: multiple definition of `__raw_writesb'
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/timer.o:/root/BUILD/u-boot/build/include2/asm/io.h:79: first defined here
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/reset.o: In function `__raw_writesw':
/root/BUILD/u-boot/build/include2/asm/io.h:86: multiple definition of `__raw_writesw'
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/timer.o:/root/BUILD/u-boot/build/include2/asm/io.h:86: first defined here
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/reset.o: In function `__raw_writesl':
/root/BUILD/u-boot/build/include2/asm/io.h:95: multiple definition of `__raw_writesl'
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/timer.o:/root/BUILD/u-boot/build/include2/asm/io.h:95: first defined here
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/reset.o: In function `__raw_readsb':
/root/BUILD/u-boot/build/include2/asm/io.h:100: multiple definition of `__raw_readsb'
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/timer.o:/root/BUILD/u-boot/build/include2/asm/io.h:100: first defined here
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/reset.o: In function `__raw_readsw':
/root/BUILD/u-boot/build/include2/asm/io.h:107: multiple definition of `__raw_readsw'
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/timer.o:/root/BUILD/u-boot/build/include2/asm/io.h:107: first defined here
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/reset.o: In function `__raw_readsl':
/root/BUILD/u-boot/build/include2/asm/io.h:116: multiple definition of `__raw_readsl'
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/timer.o:/root/BUILD/u-boot/build/include2/asm/io.h:116: first defined here
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/board.o: In function `__raw_writesb':
/root/BUILD/u-boot/build/include2/asm/io.h:79: multiple definition of `__raw_writesb'
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/timer.o:/root/BUILD/u-boot/build/include2/asm/io.h:79: first defined here
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/board.o: In function `__raw_writesw':
/root/BUILD/u-boot/build/include2/asm/io.h:86: multiple definition of `__raw_writesw'
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/timer.o:/root/BUILD/u-boot/build/include2/asm/io.h:86: first defined here
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/board.o: In function `__raw_writesl':
/root/BUILD/u-boot/build/include2/asm/io.h:95: multiple definition of `__raw_writesl'
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/timer.o:/root/BUILD/u-boot/build/include2/asm/io.h:95: first defined here
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/board.o: In function `__raw_readsb':
/root/BUILD/u-boot/build/include2/asm/io.h:100: multiple definition of `__raw_readsb'
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/timer.o:/root/BUILD/u-boot/build/include2/asm/io.h:100: first defined here
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/board.o: In function `__raw_readsw':
/root/BUILD/u-boot/build/include2/asm/io.h:107: multiple definition of `__raw_readsw'
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/timer.o:/root/BUILD/u-boot/build/include2/asm/io.h:107: first defined here
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/board.o: In function `__raw_readsl':
/root/BUILD/u-boot/build/include2/asm/io.h:116: multiple definition of `__raw_readsl'
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/timer.o:/root/BUILD/u-boot/build/include2/asm/io.h:116: first defined here
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/serial.o: In function `__raw_writesb':
/root/BUILD/u-boot/build/include2/asm/io.h:79: multiple definition of `__raw_writesb'
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/timer.o:/root/BUILD/u-boot/build/include2/asm/io.h:79: first defined here
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/serial.o: In function `__raw_writesw':
/root/BUILD/u-boot/build/include2/asm/io.h:86: multiple definition of `__raw_writesw'
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/timer.o:/root/BUILD/u-boot/build/include2/asm/io.h:86: first defined here
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/serial.o: In function `__raw_writesl':
/root/BUILD/u-boot/build/include2/asm/io.h:95: multiple definition of `__raw_writesl'
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/timer.o:/root/BUILD/u-boot/build/include2/asm/io.h:95: first defined here
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/serial.o: In function `__raw_readsb':
/root/BUILD/u-boot/build/include2/asm/io.h:100: multiple definition of `__raw_readsb'
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/timer.o:/root/BUILD/u-boot/build/include2/asm/io.h:100: first defined here
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/serial.o: In function `__raw_readsw':
/root/BUILD/u-boot/build/include2/asm/io.h:107: multiple definition of `__raw_readsw'
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/timer.o:/root/BUILD/u-boot/build/include2/asm/io.h:107: first defined here
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/serial.o: In function `__raw_readsl':
/root/BUILD/u-boot/build/include2/asm/io.h:116: multiple definition of `__raw_readsl'
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/timer.o:/root/BUILD/u-boot/build/include2/asm/io.h:116: first defined here
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/syslib.o: In function `__raw_writesb':
/root/BUILD/u-boot/build/include2/asm/io.h:79: multiple definition of `__raw_writesb'
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/timer.o:/root/BUILD/u-boot/build/include2/asm/io.h:79: first defined here
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/syslib.o: In function `__raw_writesw':
/root/BUILD/u-boot/build/include2/asm/io.h:86: multiple definition of `__raw_writesw'
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/timer.o:/root/BUILD/u-boot/build/include2/asm/io.h:86: first defined here
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/syslib.o: In function `__raw_writesl':
/root/BUILD/u-boot/build/include2/asm/io.h:95: multiple definition of `__raw_writesl'
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/timer.o:/root/BUILD/u-boot/build/include2/asm/io.h:95: first defined here
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/syslib.o: In function `__raw_readsb':
/root/BUILD/u-boot/build/include2/asm/io.h:100: multiple definition of `__raw_readsb'
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/timer.o:/root/BUILD/u-boot/build/include2/asm/io.h:100: first defined here
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/syslib.o: In function `__raw_readsw':
/root/BUILD/u-boot/build/include2/asm/io.h:107: multiple definition of `__raw_readsw'
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/timer.o:/root/BUILD/u-boot/build/include2/asm/io.h:107: first defined here
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/syslib.o: In function `__raw_readsl':
/root/BUILD/u-boot/build/include2/asm/io.h:116: multiple definition of `__raw_readsl'
/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/timer.o:/root/BUILD/u-boot/build/include2/asm/io.h:116: first defined here
Makefile:39: recipe for target '/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/libaml_meson.o' failed
make[1]: *** [/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/libaml_meson.o] Error 1
make[1]: Leaving directory '/root/BUILD/u-boot/arch/arm/cpu/aml_meson'
Makefile:564: recipe for target '/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/libaml_meson.o' failed
make: *** [/root/BUILD/u-boot/build/arch/arm/cpu/aml_meson/libaml_meson.o] Error 2


- cross compiling U-Boot on an Ubuntu 16.04 fails as the programs inside the toolchain bin directory "are not found", while file says it is 32bit executables. Files are 755 protected, so I assume we have a 64bit OS problem here.

Please provide some information on how to natively build U-Boot and get rid of that error.

Thanks in advance, Michael
mboehmer
 
Posts: 12
Joined: Thu Nov 27, 2014 9:00 pm
languages_spoken: english, german
ODROIDs: U3+

Re: Baudrate on console

Unread postby odroid » Tue Nov 21, 2017 4:57 pm

Here is the point of u-boot.
https://github.com/hardkernel/u-boot/bl ... cpu.h#L164

We will try to build u-boot on the board natively.
User avatar
odroid
Site Admin
 
Posts: 25317
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English
ODROIDs: ODROID

Re: Baudrate on console

Unread postby odroid » Tue Nov 21, 2017 6:40 pm

We could build the u-boot on the board.
But, the baud-rate couldn't be changed since the BL1 boot blob handles the baud-rate.
We have no right to access the BL1.
So you can change the kernel console baud-rate only. Sorry about that.
User avatar
odroid
Site Admin
 
Posts: 25317
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English
ODROIDs: ODROID

Re: Baudrate on console

Unread postby mboehmer » Tue Nov 21, 2017 7:00 pm

Hi,

so this is a real mess. I have 80m of cable between Odroid and MOXA RS232 port, which means that 115200 will not work reliable.
The console port was meant as "last resort" in case the Odroid fails booting - kernel access doesn't help me at all (the Odroid will be 2500m deep in the Pacific Ocean).

Can you at least point me how to solve the problem with building the UBoot, as stated before?

EDIT: is it possible to switch serial console speed after the BL1 has finished? It would be great to have some access witj 9600 8N1 to Uboot, so in case of failures one could interact with UBoot to get the C1+ running again.

EDIT: Patching BL1 is not possible?
Michael
mboehmer
 
Posts: 12
Joined: Thu Nov 27, 2014 9:00 pm
languages_spoken: english, german
ODROIDs: U3+

Re: Baudrate on console

Unread postby mad_ady » Wed Nov 22, 2017 1:23 am

What kind of datacenter will you be running under the sea? Also have you tested that 115200 doesn't work? Is the moxa 3.3V?
User avatar
mad_ady
 
Posts: 2879
Joined: Wed Jul 15, 2015 5:00 pm
Location: Bucharest, Romania
languages_spoken: english
ODROIDs: XU4, C1+, C2

Re: Baudrate on console

Unread postby mboehmer » Wed Nov 22, 2017 2:21 am

What kind of datacenter will you be running under the sea? Also have you tested that 115200 doesn't work? Is the moxa 3.3V?


We will try to spot nuclear subma... eh... wrong cover story :)
No, seriously, the C1+ will read out some photo multiplier tubes by specialized 1GbE link and store data for analysis (if there only was some Odroid with two genuine network ports, not USB crap).
It's a physical experiment related to muon particle detection.

The link will be 80m unsielded twisted pair line (1 wire TxD, 1 wire RxD, common ground) on a specialized deep sea cable. The MOXA will be V.24 levels, and to my experience, 80m with 115200 is not one thing I want to rely on in case the eMMC card fails or some boot problems arise (it is almost impossible to recover without console, and ROV operation is damned expensive).
For me, safety is crucial here. No risks.

By the way, in case you guys have 10 Odroid C2 somewhere on the shelf, I would happily buy them at once, as they are out of stock here in Germany, and will be available too late for the deployment, so C1+ is kind of second choice (2GB RAM is better than 1GB :) ).

Michael
mboehmer
 
Posts: 12
Joined: Thu Nov 27, 2014 9:00 pm
languages_spoken: english, german
ODROIDs: U3+

Re: Baudrate on console

Unread postby mad_ady » Wed Nov 22, 2017 4:16 am

Well, it sounds like a worthy article for Odroid Magazine when it is done!
Serial communication over that distance might be problematic even at 9600: https://electronics.stackexchange.com/q ... rt-signals.
I'd be looking at a way to transport the serial console over ethernet at that distance and convert it back to serial at the moxa side. You could try usb over ethernet: https://www.amazon.de/Over-Ethernet-RJ4 ... B0029HRYBK and have a usb to serial dongle on the odroid side, though I'm not sure what you could use on the moxa side...

Make sure to enable watchdog and maybe scheduled reboots.

Regarding robustness - access to bootloader might not be that helpful. You will need:
- remote power on/off capability
- avoid doing software upgrades
- try to use a readonly rootfs (e.g. squashfs + overlay). Booting with only squashfs must give you remote access.
- write the experimental data over network if possible
- enable netconsole in case the kernel crashes/console doesn't work.

Regarding a board with 2 Gigabit ports - consider a xu4 with a usb-ethernet adapter. The onboard nic goes through a usb3 bus and the external ports goes through another one. Another user reported being able to use about 2.7Gbps throughput with the onboard ethernet and two ethernet-usb adapters.
User avatar
mad_ady
 
Posts: 2879
Joined: Wed Jul 15, 2015 5:00 pm
Location: Bucharest, Romania
languages_spoken: english
ODROIDs: XU4, C1+, C2

Re: Baudrate on console

Unread postby mad_ady » Wed Nov 22, 2017 4:36 am

Here's an idea about usb over ethernet extenders - You could use an extra odroid with a powered hub to connect the extended usb to serial adapters to remote odroids. You could connect this aggregator via serial to the moxa - if the moxa is still needed
User avatar
mad_ady
 
Posts: 2879
Joined: Wed Jul 15, 2015 5:00 pm
Location: Bucharest, Romania
languages_spoken: english
ODROIDs: XU4, C1+, C2

Re: Baudrate on console

Unread postby mboehmer » Wed Nov 22, 2017 5:24 am

mad_ady wrote:Well, it sounds like a worthy article for Odroid Magazine when it is done!


It sounds like a few days off once this beast is working :)

Serial communication over that distance might be problematic even at 9600: https://electronics.stackexchange.com/q ... rt-signals.


A V.24 driver will be added to console UART anyhow. 3.3V is not an option. I'd prefer LVDS here, but again, cable pinout is limited and no more wires free.

I'd be looking at a way to transport the serial console over ethernet at that distance and convert it back to serial at the moxa side.


Unfortunately, space is an enemy. As well as heat dissipation. Sitting inside a tin can can make life really hot, even if you are surrounded by 4deg cold water. Titanium is not a good heat conductor, and we have underpressure inside as addition (so heat conduction will be lower as on shore). Again, space is critical.

- remote power on/off capability


We have :)

- avoid doing software upgrades


For sure.

- try to use a readonly rootfs (e.g. squashfs + overlay). Booting with only squashfs must give you remote access.


Hm, sounds like a nice idea, any link for me to learn more (I'm not a software guy, usually I'm doing FPGA work ).

- write the experimental data over network if possible


No way. We have one 100MBit uplink for several Odroids, and there is a reason for using the genuine GbE port and a fast eMMC...

- enable netconsole in case the kernel crashes/console doesn't work.


Give me a hint :) I can compile the kernel natively now, so it should not be a problem, in case it's a kernel option.

Regarding a board with 2 Gigabit ports - consider a xu4 with a usb-ethernet adapter.


No way. XU4 is a nice toy, but anything which needs an active fan (at least my XU4s came with fans) is not useable.
Moreover, I don't like USB/ethernet - otherwise I could also use some RaspBerryPi (which is a nice toy, too, but we had too many problems with the USB subsystem in different setups there).

Would it be possible to use RXDb and TXDb on GPIO as console for UBoot and change baudrate there? This UART is not in use, and it better connects to the motherboard inside the box - not that special connector as for the console (number of connectors => reliability)...

Michael
mboehmer
 
Posts: 12
Joined: Thu Nov 27, 2014 9:00 pm
languages_spoken: english, german
ODROIDs: U3+

Re: Baudrate on console

Unread postby mad_ady » Wed Nov 22, 2017 9:08 am

Here is some info about overlay: viewtopic.php?t=24078

Netconsole is already built-into the latest kernels and only needs to be configured: viewtopic.php?t=26965

Sorry, I don't have experience with uboot and can't advise there, but you should be able to move both uboot and kernel console to the other serial port (you can on xu4), but I expect baudrate to be an issue.
User avatar
mad_ady
 
Posts: 2879
Joined: Wed Jul 15, 2015 5:00 pm
Location: Bucharest, Romania
languages_spoken: english
ODROIDs: XU4, C1+, C2

Re: Baudrate on console

Unread postby cap00k » Wed Nov 22, 2017 10:32 am

cap00k
 
Posts: 53
Joined: Tue May 21, 2013 10:46 am
languages_spoken: english
ODROIDs: ODROID

Re: Baudrate on console

Unread postby mboehmer » Wed Nov 22, 2017 4:08 pm

cap00k wrote:Please refer to this page when cross compiling.

And, native compiling


I can meanwhile compile both Uboot and Kernel natively. The missing information was "don't compile Uboot with gcc 5.x" and "install some tools for getting the kernel image finally".
Cross compiling... no thanks. I started out with the famous MCM8+2 LInux chip years ago with crosscompiling, and don't need that experience twice :) (unless really needed).

So... anyone with ideas on how to get Uboot on C1+ using lower serial speed? Or to use the second UART on GPIO pins instead?

AFAIK the common/main.c is the part of code started after the BL1 blob, so it must be possible to set the UART speed simply by some simple command (in the end, it is just a clock divider setting for the UART, and this can't be impossible).

Michael
mboehmer
 
Posts: 12
Joined: Thu Nov 27, 2014 9:00 pm
languages_spoken: english, german
ODROIDs: U3+

Re: Baudrate on console

Unread postby mboehmer » Thu Dec 07, 2017 12:48 am

Status update: got some C2 finally, so at least hardware is available. I meanwhile managed to cross compile the U-Boot, and could also include some code into odroidc2.c (right into board_init()), which sets the console speed to 9600.
Amazingly, U-Boot still works and starts the kernel :)

BTW, a suitable documentation on the S905 SoC would make life much easier for all of us...

Unfortunately, the Linux kernel seems to ignore the console from bootargs, and as odroid pointed out, the baudrate in kernel "seems" to be hardcoded:

https://github.com/hardkernel/linux/blob/odroidc-3.10.y/drivers/amlogic/uart/uart/meson_uart.c#L845-L850

Strange enough, it seems to me that all the option handling is in the code, but only the uart_set_options() call in line 888 has been commented out and been replaced by "return 0;".

Any ideas, why that happened? AFAIK it is possible to change console paramaters in Linux after kernel booted, so there should be support for that call?

Best regards, Michael
mboehmer
 
Posts: 12
Joined: Thu Nov 27, 2014 9:00 pm
languages_spoken: english, german
ODROIDs: U3+


Return to Hardware and peripherals

Who is online

Users browsing this forum: No registered users and 1 guest