Ar150 Serial Boot

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?


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.


Okay, I tried 3 adapters and 3 AR150s I only get garbage before these lines:



[ 0.700000] console [ttyATH0] enabled

[ 0.700000] console [ttyATH0] enabled

That looks like Linux initializing the UART. Prior to the I993X UART line, I’m getting framing errors. After it there are no errors on the serial line. Is there a way to verify what bit rate/etc the port is set to in uBoot? Do you think all my USB UARTs are defective? They are all the same type, but from different sources.


Log of boot data:




% R%%RQ @ T-!½Ñ´)D



IR"¥I½½E ÖK-I1jRJ: j $SIÑ5


J^¥K½¯$WEª) j Ph1O:¢j!¤iU¥I5/$/1%)

HBCá**W%¹ ªÍ³Z


ª Ò)Ù¶¢½)J Ë



R% @ R%%% P C!R @ R%%RR @ R


@* R%%%%*RR

%%%C!R* RRR%%RjR%REIRR%R @ j P%@R @ %%R@RRC!%%%% @ *%%% R%%EIEIj


¬* ½to Õ½%½¯/ËYgjþ


I U¹u(+Eb®Ñ+


Wk)¥Ñ) ¡¥¬.



.SWÉÑ+ j

Bë/ÑKÂ9ªj ª+)rµU’jM



(WEd¦&Òª)Ò 55

@$µy:j%"5bá J)béW+ Ö


(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½Ñ


z V

å."¥ÍVËJ¹®ZVH]Ë9¹u¥.1[ rW@rV+[Sµ xKÂ&V5 `.j½+±)Ò .WÑ




PWå ½ÉV ë$Y¹u¥5 PW¸½¯V,[K¥[Â0`j#Â0df5 rJ¹W¥[ ë$YÕª


#WëË)²VZ V)-'å b¥*©.)å.W©H+ ]PÑ¥µ [ rWPÉ


EQL¡U±¥Í,b¥¹UVK)&©5 rÕµZÒ½¹UÍÑk ¹h½¹U ¼%¤Y. j¥± ÉÖÕ5¹u¼¹.ÕÑ+

©.q d2FR¨ `.0WZ).%

µµinSª: ªm









%B9*É¥©Y.'RBz).q X2 å.ÍV©Hr]"¹ÑK




@¥ %B

¨. ]J¹½Ei

¢ Ñ´WÍ3’ Ê+É: ¢ å.WEsN©

° `.0WM¥©WË

*ɱ ¥É²Oj rRJ




@.]j¥[Kå.'² Z/aª²Zva+±UIZ ¬).¥

) Q¦* ÈÖW4, ½

(W,%Z ËÑ´ Ê¢


j!¤5 @0 WSU%'B]($:j!¤,*i




°Â]j½U- U

¨.9BÍ¡¢±)*¹E¥Uͳ’zÉ:¢ Ê©¥ &Wj¹EÁ°Ñ«i


(,%*¹®É²Y’$B+)'¢²>ͳCá r]rQ:R¥ÍW,-½E½/¬

2å `á


¨,Ë9J 11M(.V rÊ]ÊWo)¢½ ,k­5Uɲ)jAjH[ @rªNPWrQIR¥ÍɲYɲÑ4k½/

2µ *

r WT% ÍÑ+¥Í%BÍ

¢(,¥*¹KÍ:$+¥.q Ê&ÍVh 0É]TeA ¥E¢

¡U]uAÒB ¢tN%.'B+¥’båÑ4Y¥



(,%.½ ¹


r)]Te:½[ @0IWBÐ Ñ4UÍo0,¢ ÊY.W¥[rIWKÑ´YB¨.


(,%*¹®^©.q (¼Éɲ’&å.W¬¥ rWr!¥UÑ)¥E½¯¬


µ¥©+ L

[ rdW2á +Í¢±¬Y*¹E¥Uͳ’ª² z).'jML ºIå¹Í³Cá[ rd² PWÅÕµX.¦’²ÉÍV

¢ !ʦ J"PA± êÕ5)5[rd]Rj2’²¥®ªË




Ñ J.4

²º jÍVË+,B)


ª%^É $Ñ JIR¡u¹¢¥VH rt] ®,%V.%.r½ È©VkÑ))VHB+r]J½ ®,99."*± È©VkÑ¥),VÕ-/hWJN+2








[ 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.


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.


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:

  • UART Enable is set
  • Startup is called (well poked)
  • Bit rate is set
  • Parity, Length and Stop Bits are set
In the uBoot driver
  • Bit rate is set
Many other targets follow the Linux method. I suspect UART Enable does something to pin multiplexing, and Startup sets defaults, pin multiplexing, and/or clocks. I've done some reading and it is clear the 16550 code is a mess. I filed a request and it is awaiting moderation. It would certainly explain why some external UARTS work and others don't. I suspect your UART of choice is taking hints from the stream and correcting the settings or is more tolerant of voltage sag or multiplex noise prior to the proper initialization by Linux. Of course equally possible is I'm not seeing where initialization is occurring and there are more bad TTL UARTS than good.

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.


@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.

  1. 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?”

  2. 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.

  3. 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.;a=commit;h=382cc69881bcc4b928cf180ac7e725645054f94c
4) Piotr shared the current code supporting the AR93xx UART. He suggested we could patch the OpenWRT fork of uBoot.
Here'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.

  • Jitter is the deviation from true periodicity of a presumed periodic signal. In other words the signal bit edges are not on the proper clock cycle. This can lead to sampling the bit before or after it changes state. This is likely because the internal clock isn't set to a high enough resolution to trigger transitions where they should be. So if you send 101 it might be received 100 due to jitter and sampling.
  • Noise is stray signal on the line. It can cause errant reads and slow the slew rate on the line leading to late bit errors. Likely due to the fact the multiplex for the bit isn't set properly.
  • Slew is the time necessary for the voltage to overcome the capacitance of wire and components connecting the sender to the receiver. Noise can slow this time.
Here's the bad news. UARTs that do work are not operating per EIA standards for 232 and should be avoided as these usually are doing something non-standard to fix something operating outside the standards. Yes I can hear you saying, "But it works!" Just think about what a UART has to do to fix jitter, noise, and slew. It isn't recommended because it risks sampling errors to hide real problems. In this case, the clock is jittering on the AR9331 and the same sampling errors occur in _both directions_. Since we can't predict and compensate for jitter when sending to the AR9331, it is likely to have errors when receiving. This might be 1 in a million bits, but when you upload via serial, you're sending a few million, so it is likely you'll have an error in the upload. And at that small an error rate, it is likely to cause some mighty strange and hard to understand issues.


  1. 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.

  2. Patch OpenWRT’s uBoot with Piotr’s UART code. Again, happy to test on my side.

  3. Help uBoot’s community support the AR71/93xx properly. (You have spare time, right? - lol)

  4. Beg OpenWRT to bring uBoot into the current era. I suggest holding one’s breath as more productive considering the current environment.

  5. 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.


Back on my original question, when I attempt to pull the uBoot environment, I get the following:


Warning: Bad CRC, using default environment

bootcmd=bootp; setenv bootargs root=/dev/nfs nfsroot=${serverip}:${rootpath} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm



I’m using the following as addresses:

cat fw_env.config

MTD device name Device offset Env. size Flash sector size Number of sectors

/dev/mtd1 0x20000 0x01000 0x10000

I’m getting the numbers from here:
And using the process here:


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:;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.



Warning: Bad CRC, using default environment

bootcmd=bootp; setenv bootargs root=/dev/nfs nfsroot=${serverip}:${rootpath} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm




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











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



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.