Having a problem when booting with serial connected at 115200/n/8/1.
Connected at power on I get garbage instead of uboot and dmesg. Was expecting to see the result of this example.
If I wait until OpenWRT is booted, I can hit enter and get the OpenWRT banner. Of course hitting enter too soon aborts boot, and there is an interactive console, but so far I haven’t been able to guess the rate.
Is the hardware set to a different rate, parity or bits prior to Dropbear initializing the port?
M
It should be pretty easy to use.
If you only have garbage in your output, probably because the uart adapter is no good. We met such problems before. Use a better one.
alzhao,
Okay, I tried 3 adapters and 3 AR150s I only get garbage before these lines:
ê'%RJÍI933X UART
[ 0.700000] console [ttyATH0] enabled
[ 0.700000] console [ttyATH0] enabled
M
Log of boot data:
þAR%%IR
%IIIRJ%I%RR*EIR
% R%%RQ @ T-!½Ñ´)D
ÕªJ"j
IIR%%%II**IIIR%%I**EIQHPHBPRB
IR"¥I½½E ÖK-I1jRJ: j $SIÑ5
J^¥K½¯$WEª) j Ph1O:¢j!¤iU¥I5/$/1%)
HBCá**W%¹ ªÍ³Z
")VÑ©
ª Ò)Ù¶¢½)J Ë
21!5
"ÉR% @ R%%% P C!R @ R%%RR @ R
%j
@* R%%%%*RR
%%%C!R* RRR%%RjR%REIRR%R @ j P%@R @ %%R@RRC!%%%% @ *%%% R%%EIEIj
¬* ½to Õ½%½¯/ËYgjþ
AHÔÕµ¤
I U¹u(+Eb®Ñ+
+ÕÍÉ©
Wk)¥Ñ) ¡¥¬.
j(
Í.©HFÕ5
.SWÉÑ+ j
Bë/ÑKÂ9ªj ª+)rµU’jM
bUá8K&)rRj
(WEd¦&Òª)Ò 55
@$µy:j%"5bá J)béW+ Ö
Vͳ9V©
(W ¥:1
#²)®ªË
¨¹5µ+¥¹u ɹU±J¨V,ÉɹEÉVþKIjSWÉ+á[]b¥- WÍ¥ªË ¢ rz¹]I/a¥©+ÉÖ ½½±U U+0 +±U5°]U%.Wk½¹J:ʦ(PSZ)4[ @ P]Sk:
j T 5 r$±¬/+½é±QTÑ´J: :CjrS&S $S UÁ ` 1M-ÒM&BC+ @W ÉÖk(:ÇhPW[KV:@ 0PQÍV
[ @.PWJÑr½Ñ
2
z V
å."¥ÍVËJ¹®ZVH]Ë9¹u¥.1[ rW@rV+[Sµ
xKÂ&V5 `.j½+±)Ò .WÑ2É*
!,
rªH
PWå ½ÉV ë$Y¹u¥5 PW¸½¯V,[K¥[Â0`j#Â0df5 rJ¹W¥[ ë$YÕª
Â0`00j#Â&IfV5
#WëË)²VZ V)-'å b¥*©.)å.W©H+ ]PÑ¥µ [ rWPÉ
¨,)Zºå,V%
EQL¡U±¥Í,b¥¹UVK)&©5 rÕµZÒ½¹UÍÑk ¹h½¹U ¼%¤Y. j¥± ÉÖÕ5¹u¼¹.ÕÑ+
©.q d2FR¨ `.0WZ).%
µµinSª: ªm
(.ͳO.0XSZ(Q-½½E)®Q64c
Ao
/IZ(!ɵ«WVV²Z)®
½¹5=W
brÑj=Å
¨.&.Ir¥ÑK¤C¡UrWP)
¡.
¢
%B9*É¥©Y.'RBz).q X2 å.ÍV©Hr]"¹ÑK
¨.
¢
¡,¥*¥©.'ÂB’¥.13,Âb
@¥ %B
¨. ]J¹½Ei
¢ Ñ´WÍ3’ Ê+É: ¢ å.WEsN©
° `.0WM¥©WË
*ɱ ¥É²Oj rRJ
Ѭ-*
*k)õ0`j
@.]j¥[Kå.'² Z/aª²Zva+±UIZ ¬).¥
) Q¦* ÈÖW4, ½
(W,%Z ËÑ´ Ê¢
Í ¢ºWÂZ ÉV©H
j!¤5 @0 WSU%'B]($:j!¤,*i
°0X]*
!W
A]¥*ÖḒ"¥VÕ-Kºj¹¥©[K+'j
°Â]j½U- U
¨.9BÍ¡¢±)*¹E¥Uͳ’zÉ:¢ Ê©¥ &Wj¹EÁ°Ñ«i
¢
(,%*¹®É²Y’$B+)'¢²>ͳCá r]rQ:R¥ÍW,-½E½/¬
2å `á
]jMÒj
¨,Ë9J 11M(.V rÊ]ÊWo)¢½ ,k5Uɲ)jAjH[ @rªNPWrQIR¥ÍɲYɲÑ4k½/
2µ *
r WT% ÍÑ+¥Í%BÍ
¢(,¥*¹KÍ:$+¥.q Ê&ÍVh 0É]TeA ¥E¢
¡U]uAÒB ¢tN%.'B+¥’båÑ4Y¥
¨.
¢
(,%.½ ¹
$S©
r)]Te:½[ @0IWBÐ Ñ4UÍo0,¢ ÊY.W¥[rIWKÑ´YB¨.
¢
(,%*¹®^©.q (¼Éɲ’&å.W¬¥ rWr!¥UÑ)¥E½¯¬
2
µ¥©+ L
[ rdW2á +Í¢±¬Y*¹E¥Uͳ’ª² z).'jML ºIå¹Í³Cá[ rd² PWÅÕµX.¦’²ÉÍV
¢ !ʦ J"PA± êÕ5)5[rd]Rj2’²¥®ªË
rr)B4UªAPYI(A5)SJ)B4=D
IRJ%U))jM&²R
B
Ñ J.4
²º jÍVË+,B)
)¢½
ª%^É $Ñ JIR¡u¹¢¥VH rt] ®,%V.%.r½ È©VkÑ))VHB+r]J½ ®,99."*± È©VkÑ¥),VÕ-/hWJN+2
xQ
ɲétW
IOÂ1¦ÉV O
¨¥%
ê’%RJÍ
I933X UART
[ 0.700000] console [ttyATH0] enabled
[ 0.700000] console [ttyATH0] enabled
[ 0.710000] bootconsole [early0] disabled
[ 0.710000] bootconsole [early0] disabled
[ 0.720000] m25p80 spi0.0: found w25q128, expected m25p80
[ 0.720000] m25p80 spi0.0: w25q128 (16384 Kbytes)
[ 0.730000] 4 cmdlinepart partitions found on MTD device spi0.0
[ 0.740000] Creating 4 MTD partitions on “spi0.0”:
[ 0.740000] 0x000000000000-0x000000040000 : “u-boot”
[ 0.750000] 0x000000040000-0x000000050000 : “u-boot-env”
[ 0.750000] 0x000000050000-0x000000ff0000 : “firmware”
[ 0.790000] 2 uimage-fw partitions found on MTD device firmware
[ 0.800000] 0x000000050000-0x000000180000 : “kernel”
[ 0.800000] 0x000000180000-0x000000ff0000 : “rootfs”
[ 0.810000] mtd: device 4 (rootfs) set to be root filesystem
[ 0.810000] 1 squashfs-split partitions found on MTD device rootfs
[ 0.820000] 0x000000670000-0x000000ff0000 : “rootfs_data”
[ 0.820000] 0x000000ff0000-0x000001000000 : “art”
While, you need to try different type, not same type of adapters. If this type of adapter has problems, then all this type will have problems. Generally it is because of the chip.
Alfie, I guessed it might be the chip so I borrowed a couple today. No joy. They all produce the exact same result. We’re up to 4 chips now. How do we verify the uboot rate? I’m not saying they aren’t all defective, but before I go buy a new lot I’d like to see if there are any other causes. If you had your UART on Amazon that would be an easy check.
There is no secret, We all use the same settings for uart, 115200.
The following link actually show all needed for serial.
We do recommend a UART adapter, which is available on our own shop, not amazon.
Alfie,
I didn’t think it was a secret and I assumed 115200n81. 115200, 38400, and 9600 still seem to rule the router world. We’ve suffered the fake converters at least once so we know what to look for. We have a PL2303TA, CP2102, FTDI and one I’m sure is a fake PL2303 and then one I don’t know as it left with its owner. We’re all working in 3.3v systems.
I’ve ordered your UART from the web site.
I’d still like to know where to check the default settings for uboot please. I can’t afford a 3 week delay at this point. I know it should be set at 115200/n/8/1, but every adapter swears its having framing errors.
M
in uboot, use printenv to print the settings.
But this may not display all the settings, as uboot may use fixed settings.
But OpenWrt can override the settings itself. I uses its own settings.
Can you tell me what you have done with the router, for example, changing firmware? changing settings? And connections?
I never expect there are such problems.
LOL! Well that’s going to be difficult to do anything in uBoot via serial since the serial port does nothing but frame errors before Linux initializes it. Even if I force uBoot recovery, I get garbage on serial. I might have to connect 2 AR150s together to solve this in my time window.
The 3 routers I’ve been using are all AR150s.
History for #6 Fronkensteen
Arrived on 2.12, upgraded to 2.13, upgraded to 2.17. reverted to 2.13, custom Trunk build 5/12/16 <span style=“line-height: 1.5;”>packages - wpad-mini, + joe, authsae, wpad, alfred</span>
History for #8 Knockers
Arrived on 2.12, upgraded to 2.13, packages - wpad-mini, + joe, authsae, wpad
History for #10 (unnamed)
Arrived on 2.13, no changes - Pulled from wrapper to test uBoot frame error issue discovered on #6.
I’ve found a suspect. In the ar933x-uart driver for Linux:
And yes, I understand why you wouldn’t suspect uBoot in the first place. I’ve fixed a few issues where there was some workaround that was well “supported by evidence” and accepted as reasonable.
M
@Mmonaghan, the situation is interesting. Seems you have more experience than me in this UART things. I just grab our USB adapter and it just works. We have used several types. At the beginning we had adapters which don’t work so we change new model and it works. Then we just used it.
Seems now I have to wait for your news for this issue when you try new adapters.
Can you share photo of your adapter and how you connect?
@alzhao, that’s often the way it happens. Something doesn’t work, someone finds a “fix”, a reason is formed to support it, and everyone moves on while the real cause lurks in the shadows. The ability to find these things is only slightly more profitable than annoying. (lol) My apologies for what I’m about to document.
<span style=“line-height: 1.5;”> </span>WARNING: Due to the uninitialized state of the UART, uploading via serial in uBoot is not recommended. If you must, verify the check-sum!
I have conformation from the uBoot community along with details and some possible fixes.
UART Support for ARxxxx doesn’t exist in our current version of uBoot. The UART is not initialized until Linux boot starts. The uBoot fork in OpenWRT has several of these missed opportunities beyond the UART. They only get fixed when someone figures it out, and most people don’t do hardware at that level. “Surely the programmer knew everything and did it exactly right the first time, right?”
We are on a 2003 fork of uBoot. It is not supported. It has never been merged against the current uBoot so they are more than a decade out of sync. The current uBoot is on an 8 week release cycle.
uBoot added support for AR71/93xx family to mainline. It will be added to release in a few months. It might be worth building the current uBoot and seeing if it will work. Lacking a recovery path, I can’t do that at this time.
http://git.denx.de/?p=u-boot/u-boot-mips.git;a=commit;h=382cc69881bcc4b928cf180ac7e725645054f94c4) Piotr shared the current code supporting the AR93xx UART. He suggested we could patch the OpenWRT fork of uBoot.
https://github.com/pepe2k/u-boot_mod/blob/master/u-boot/cpu/mips/ar7240/qca_hs_uart.cHere's what's happening:
uBoot doesn’t initialize the UART on the SoC. Initializing it sets defaults, enables it, sets pin multiplexing, clock multipliers, etc. The reason some external UARTs aren’t working is clock jitter, noise and slew.
Options:
Try the latest mainline uBoot and see if it just works. You’ll likely have to set option for pins, flash, etc to match your configuration. If it boots, send me a copy and I’ll verify it resolves the serial issue on several devices.
Patch OpenWRT’s uBoot with Piotr’s UART code. Again, happy to test on my side.
Help uBoot’s community support the AR71/93xx properly. (You have spare time, right? - lol)
Beg OpenWRT to bring uBoot into the current era. I suggest holding one’s breath as more productive considering the current environment.
Ignore it and suffer chaos theory.
I hope I’ve been able to shed a little light into a dark corner. I know this isn’t your fault as you adopted it in good faith. Let me know what I can do to help with a fix and I’ll lend you my support.
M
Back on my original question, when I attempt to pull the uBoot environment, I get the following:
fw_printenvWarning: Bad CRC, using default environment
bootcmd=bootp; setenv bootargs root=/dev/nfs nfsroot=${serverip}:${rootpath} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm
bootdelay=5
baudrate=115200
cat fw_env.configMTD device name Device offset Env. size Flash sector size Number of sectors
/dev/mtd1 0x20000 0x01000 0x10000
https://github.com/domino-team/openwrt-cc/blob/master/package/boot/uboot-ar71xx/files/include/configs/nbg460n.hAnd using the process here:
https://wiki.openwrt.org/doc/techref/bootloader/uboot.config
Use the following for fw_env
But it maybe empty
cat fw_env.config
# MTD device name Device offset Env. size Flash sector size Number of sectors
/dev/mtd1 0x0000 0x8000 0x10000
Same result (below).
I’ll pull the partitions off the device today and see if I can find the boundaries. There is a configuration on the device, or U-Boot wouldn’t work at all. You probably know this, but there’s a good definition of what needs to be configured here: http://git.denx.de/?p=u-boot.git;a=blob_plain;f=README;hb=HEAD It covers the current version of U-Boot so everything doesn’t match, but at least it tells me where to find the majors.
I think the “flash sector size” should reflect the flash sector size but it may be ignored as we have SPI connected flash. If U-Boot were to respect the current settings, a write would land in the middle of the firmware partition. The documentation on the OpenWRT version is conflicted against itself.
On the jitter issue, I’ve found several patches were submitted on OpenWRT as far back as 2014 in an attempt to correct this, but none were committed and none were of the quality of Piotr’s code.
M
fw_printenv
Warning: Bad CRC, using default environment
bootcmd=bootp; setenv bootargs root=/dev/nfs nfsroot=${serverip}:${rootpath} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm
bootdelay=5
baudrate=115200
So I pulled the partitions and what I’m seeing doesn’t make sense to me. Going to code, <b>CONFIG_ENV_OFFSET</b> is defined in 3 places as :
0x60000 = /firmware
0x20000 = /u-boot
0x4200 = /u-boot
CONFIG_ENV_ADDR is additionally defined as 0xbfc20000 ((Is this a CPU map for 0x20000)
There is no U-Boot config at any of these addresses. If someone tries save the U-Boot environment, it looks like it stomps on firmware or U-Boot code. The final address might be a “special address” which could land anywhere or result in a kernel fault if it is in a mode that checks bounds.
Not dissuaded by lack of correct pointers, I did find the following at 0x25440 in /u-boot:
*Note: this looks more like Domino than AR150 partitions
bootargs=console=ttyATH0,115200 board=domino root=31:03 rootfstype=squashfs,jffs2 noinitrd mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,1280k(kernel),14656k(rootfs),64k(nvram),64k(art)ro,15936k@0x50000(firmware)bootcmd=bootm 0x9f050000
bootdelay=1
baudrate=115200
ipaddr=192.168.1.1
serverip=192.168.1.2
bootfile=“firmware.bin”
loadaddr=0x80800000
ncport=6666
uboot_addr=0x9F000000
uboot_name=uboot_for_gl-ar150.bin
uboot_size=0x40000
lu=if ping $serverip; then tftp $loadaddr $uboot_name && if itest.l $filesize == $uboot_size; then erase $uboot_addr +$filesize && cp.b $loadaddr $uboot_addr $filesize && echo OK!; else echo ERROR! Wrong file size!; fi; else ERROR! Server not reachable!; fi
firmware_addr=0x9F050000
firmware_name=openwrt-gl-ar150.bin
lf=if ping $serverip; then tftp $loadaddr $firmware_name && erase $firmware_addr +$filesize && cp.b $loadaddr $firmware_addr $filesize && echo OK!; else ERROR! Server not reachable!; fi
lc=tftp 0x81000000 config.bin &&cp.b 0x9fff1000 0x80060000 0xf000 && cp.b 0x81000000 0x80060002 0x06 &&erase 0x9fff0000 +0x10000 && cp.b 0x81000000 0x9fff0000 $filesize && cp.b 0x80060000 0x9fff1000 0xf000
uboot env takes 64k after 256k uboot. But if the partition is empty, uboot will use the default env.
If the uboot-env partition is empty, you will have the error when using fw_printenv, because it simply read that partition.
I still have no idea of they problem you met, why you cannot read the console.