u-boot for Zyxwl nsa320

I am struggling with my nsa320 using the stock u-boot. In addition to it not supporting thumb drives, the network is very flaky, but only in u-boot. Sometimes it works and sometimes it doesn't. When it doesn't work, I find that booting the stock firmware or Archlinux and then restarting fixes it. I don't know if this is normal for the nsa320, but it only fails to come up in u-boot and always works in Linux, so I suspect a software issue in the stock u-boot (maybe the lack of some work-around).

In any case, I want to replace u-boot with a version that supports usb and, hopefully, doesn't have the network problem.

I got the uboot-nsa320 source code from github psch2 and built it for the nsa320. This code did not include the kwboot program (but it did make the kwimage). So, I got the u-boot source code from denx and buily kwboot. That denx package did not have nsa320 support (or I somehow missed it). I'm surprised that it hasn't made it to the latest denx mainstream. Maybe I'm not looking in the right place.

Anyway, I used kwboot to load the u-boot.kwb file into the nsa320. It looked like it downloaded (had the [... stuff), but nothing happened. I used the "-t" switch to get a terminal when it was done and saw nothing happening there. (Kwboot with -t and no image let me watch the standard u-boot when I reset, so all that seems to works.)

Is there something else I need to do when building u-boot other than "make nsa320_config" and "make u-boot.kwb"?

Where is the best place to get the u-boot source (i.e., the latest functioning u-boot for nsa320)?

I am using the arm-linux-gnueabi- toolchain with gcc 4.6. Is that appropriate?

Thanks in advance,

Lance

I found something that might be related, but I don't know enough about the processor and board to know. I compared the values for register initialization in the kwbimage.cfg file with what I take to be the corresponding registers in the nsa320 (read using md in u-boot). First, the base address for the registers in the nsa320 is 0xf100000 rather than the 0xffd00000 in the cfg file. I assume that this is just a remapping performed by u-boot and is not very important.

But some of the DRAM init/timing registers are different, which may be important. For example, the cfg has:

DATA 0xFFD0141C 0x00000C52 # DDR Mode

and the corresponding 0xf100141c = 00000652

Similary:

DATA 0xFFD01420 0x00000040 # DDR Extended Mode

is 00000004 in the device.

DATA 0xFFD01494 0x00030000 # DDR ODT Control (Low)

is 00120012 in the device.

DATA 0xFFD0149C 0x0000E803 # CPU ODT Control

is 0000e403 in the device.

I tried changing the cfg values to match the device but I got the same results.

By the way, I also found the README.nsa320 file and followed the directions exactly including downloadind, building and using kwuartboot-0.1. I still got the same results. I did notice that kwuartboot-0.1 is significantly slower to download, has fewer options and much less user feedback. I guess it was an early version that eventually evolved inot the one in the u-boot tree.

I' m still seeking advice/suggestions.

Thanks,

Lance

The network "flakyness" is actually a very annoying known issue with their design. Twiddling power on resume to ON will solve the issue, as an intermediate step.

Hello WarheadsSE -- we meet again.

I'm not sure what you mean by "Twiddling power on resume to ON..." Is this a u-boot setting? The problem I am seeing is when I boot u-boot. I have not seen the problem booting either the stock Linux or Archlinux.

Thanks,

Lance

http://archlinuxarm.org/forum/viewtopic.php?f=27&t=3708&start=30#p22861

WarheadsSE,

Thanks for the link. I tried it and got somewhat different behavior than before, but it just might be that the trials are not well controlled enough and are small enough not to be statistically significant.

After running the script, I was able to power cycle and run u-boot with a working network about four times in a row. Then it stopped working again. At this point, I booted Archlinux and it could not start the network -- this was the first time I had seen this. I booted Arch two more times with the same results.

Finally, I booted the stock firmware and the network came up. Then I rebooted and started Arch and the network worked again. So, as a modification to my earlier observations, I have never seen the stock linux fail to get the network running. Maybe there's something ZyXEL knows that we don't. (By the way, I thought this was supposed to be open source. I have not been able to find the ZyXEL source for the 320.)

One other observation is that the network never comes up if I connect it to my 10/100 router. This is true even though I don't get the "egiga0 no link" message (which is what usually happens when the network doesn't come up. But, if I insert a gE router between the nsa320 and the 10/100 router, then the network does come up (assuming I'm not having the "no link" issue). With linux (stock or Arch), it will work with either connection. So I guess there's some auto-negotiation that's not being done in u-boot.

I'd like to better understand what the script is doing. I mean, I know what it is doing with the GPIO lines, but I don't know what they are connected to so I don't know the net result. From the script, it appears that GPIO49 might be serving as some sort of clock to latch whatever we output on GPIO47. But, even if it is, is this something nonvolatile so when I cycle power it will remain?

I wrote a program to allow me to examine/modify the chip registers (still mapped to 0xf1000000 in linux as they were in u-boot). When I write to the GPIO control registers, I note that the GPIO49 appears to be mapped as in input in both u-boot and Arch, and it reads back as 0. However, when I program it, I do seem to be able to see the output value reflected back in the input register.

Back to the issue of the serial booting u-boot, I notice that the value in kwbimage.cfg for the I/O configuration register (reg offset 0x100e0) does match the u-boot/linux values. The cfg file has 0x1b1b1b9b and uboot/linux have 0x1b1b9b9b. I looked this up in the data sheet and the differing bit controls the I/O pad voltage for the RGMII -- 0=3.3v, 1=1.8V. So the cfg seems to be setting 3.3V despite the comment that says 1.8V.

The other mismatches look like differences in DDR timing and termination. Assuming that these values are actually transfered to the chip, I don't see it how it could work. Perhaps they changed some things in the nsa320 since Peter's cfg file.

Here is another possibility. I initially built my I/O access program using the same toolchain I built u-boot with. When I ran it -- just in help mode, no actual I/O access -- I immediately got s segmentation fault. But ,when I installed GCC under Arch on the nsa320 and built it there, it ran fine. I did a "file" on both images and they only differed in version. But maybe there is something wrong with using arm-linux-gnueabi-gcc-4.6 to build u-boot.

Thanks,

Lance

I did some hacking around and I may be on to something. First, I added some GPIO register writes in the kwbimage.cfg file to verify, via the LEDs, that this much was working. It was.

I noticed when the download completes, the system LED alone is on and it is green. So I wrote a code fragment to change the LED pattern to something I would recognize and started inserting it at various points in the intialization sequence. The code I stuck in is:

*((u32*) 0xf1010100) = 0x00001000;
*((u32*) 0xf1010140) = 0x00000100;
while (1) {}

Using that, I started doing a search -- lots of compile and downloads. But I finally found it. It gets to a point in the timer_init routine but gets no further. The line beyond which it does not go is:

lastdec = READ_TIMER;

The READ_TIMER macro converts to

(readl(CNTMR_VAL_REG(UBOOT_CNTR)) /(CONFIG_SYS_TCLK / 1000))

I believe this might invoke a floating point function to do the arithmetic. So I suspect a compiler/library/switch problem with the toolchain I am using. Here is the compiler invocation:

arm-linux-gcc -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x00600000 -I/home/lancej/nsa320/uboot/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc/arm-linux-gnueabi/4.6/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mabi=aapcs-linux -mno-thumb-interwork -march=armv5te -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -o timer.o timer.c -c

I see it has "-msoft-float" but I don't know if that is enough or if maybe the library has some floating point compiled in.

If it looks like I am on the right track, what should I be using for the tool chain? I used synaptic (kubuntu 12.04) and chose gcc-4.6-arm-linux-gnueabi (it installed 4.6.3-1ubuntu5cross1.62). Should I build the crosstool-ng compilers? Any advice would be welcome.

Thanks,

Lance

Solved! It was the toolchain. I went to the Archlinux site and followed the instructions for building a cross-tool set:

http://archlinuxarm.org/developers/distcc-cross-compiling

Of course, the tools didn't build at first on Xubuntu 12.04/32, but I replaced the crosstool-ng with the latest version (1.17) and it all built. Then I rebuilt uboot, serial loaded it and it worked.

can you please share the final uboot.kwb that you used?