Colibri/PXA320 meets OpenOCD, becomes free

In the last blog entry, I mentioned getting a development kit. It's cool and all, but as the Colibri/PXA320 and other PXA3xx boards, it has one really bad flaw -- all of the flashing tools for PXA3xx are for certain proprietary OS only. Moreover this particular overly proprietary debugger/flasher I got with the board was so choosy about adapters it supported it really went on my nerves badly especially since the adapter I got was not working properly and I couldn't use any other of those I had. So there was no way to reflash PXA3xx boards from Linux ... until recently.

I took a look at OpenOCD project, which is a Free Software JTAG Debugger, and figured it'd be actually quite simple to update it to support PXA3xx by looking into the PXA3xx documentation and comparing it with PXA2xx one. Apparently, the only differences there were the Instruction Length (which was 7 for PXA2xx and 11 for PXA3xx) and - the more weird change - that PXA3xx has the instruction codes shifted by 4 to the left in some cases. After fixing these, I was able to connect to the CPU using my FTDI FT2232 based fake-amontec JTAG cable and operate with it normally. The patches are available in the OpenPXA GIT.

Maybe someone would like to see a howto for loading new software into the board using the OpenOCD, so here it is. Firstly, download the OpenOCD patches from OpenPXA GIT and do:

• git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd # download OpenOCD sources
• cd openocd # enter the OpenOCD directory
  
• apply OpenPXA patches for OpenOCD
• ./bootstrap # prepare files necessary for OpenOCD compilation
• ./configure --enable-maintainer-mode --enable-ft2232_libftdi # the first option is necessary (dunno why), the other one enables support for the ft2232-based cables
• make # compiles OpenOCD
• ./src/openocd -s tcl -f board/colibri_pxa320.cfg -f interface/jtagkey.cfg # executes the OpenOCD debugger; tells it to search for configuration scripts in directory tcl, to use colibri_pxa320.cfg board support file and jtagkey.cfg cable support file
• telnet localhost 4444 # connect to the OpenOCD

Once connected using the telnet, we can start issuing commands. We'll want to load a program to a particular location in SRAM:

• reset halt # reset the CPU and stop executing instructions
  
• fast_load_image /path/to/file 0x5c080000 bin # prepare to load binary file to address 0x5c080000 (NOTE: 0x5c080000 is valid SRAM only for PXA320, for other CPUs use 0x5c000000 or something)
• fast_load # actually upload the file
• resume 0x5c080000 # continue instruction execution at address 0x5c080000 (about the address used, see previous note)

And now that you can load a file into SRAM and execute it, you can use this technique to load a bootloader there and control it over UART or something. Once you succeed in running the bootloader, you can do whatever you want with the hardware (for example flash the bootloader into NAND).

Colibri/PXA320 Ethernet, OpenPXA IPL v2.0 and UCB1400

Just a quick summary to keep possibly interested people in the loop today. I got the ethernet working on the Colibri/PXA320 board in u-boot. The problem was with the way the ax88796 driver was accessing the registers of the ethernet chip. It was actually accessing them in some weird 16bit mode, which caused two registers to be read at one time and the contents of the upper one was sometimes lost, caused malfunction of the driver. So I supplied my own access functions the same way as some Renesas board did and that eventually fixed the issues. Now the ethernet controller is working happily.

I recently started working on making the OpenPXA IPL more generic in preparation for supporting more devices. As I explained in an earlier post, the NAND is configured to some sane defaults and some of it's characteristics are determined by the BootROM already when the IPL is being executed. So I make use of this information and don't reconfigure the NAND, but just reset the chip and do READ0 and READYREAD commands. Also, I'm working on cleaning up the code and fixing some of it's possible issues.

Moreover, I plan to add debugging functionality into the IPL, which would probably allow the user to load some code into SRAM through serial console (XMODEM possibly or something) instead of NAND as it's now. Such thing will eventually allow the user to restore pretty much any system without NAND page number 0 being wiped out.

And the last thing today is about the UCB1400. I sent a patch upstream, that allows the UCB1400 to accept touchscreen IRQ GPIO through platform data. I also explained the reason for this in the previous post so read it there.

Recent happening - PXA3xx, u-boot etc.

I just want to write some sum of what happened since last time I posted something here as stuff actually pretty piled up and I'm overly busy now. Expect somehow longer entry as quite a bit happened actually.

All this machinery started back in late September, when I got a Toradex Colibri carrier board with a PXA320 CPU card from INCOME s.r.o. and was instructed to prepare a decent bootloader for it and possibly make Linux kernel run smoothly on it. Sure, sounds easy, it's a Marvell CPU afterall and U-Boot already has some support for a few boards with PXA3xx too. Moreover, it's not too different from PXA2xx series, right? Yes sure, it's not, but there are a few changes.

I was suffering for some time, trying to make use of the preinstalled EBOOT bootloader to load Linux and even wrote some wrapper so it loads the kernel correctly at least, but I gave up on this idea as it turned out EBOOT is a worthless piece of crap. Not to mention, EBOOT is a proprietary goo. So I figured I need to replace it. U-Boot was the only choice here of course, but here came the first difference between PXA2xx and PXA3xx. The PXA3xx CPU does not need a NOR flash to boot from, it can boot directly from the NAND flash. Actually, there is something called BootROM buried in the CPU as I figured out later, but it's not possible to read it's contents without electron microscopy I think. Well this BootROM apparently configures the NAND properly, copies it's first sector to SRAM and executes it. But here popped in another problem, I managed to overwrite the first sector with not working code rendering the board unusable. Sadly, there is no utility for Linux that can flash the PXA3xx board so I had to use their proprietary one to reflash the board.

After numerous reflashes and testing, digging through the bootloader images Toradex released publicly and analyzing them, I managed to put together an open source GPLed IPL (initial program loader) that can be stored in the first sector of NAND with a sole purpose of loading further sectors from NAND, copying them to SRAM and then jumping to the beginning of these copied data. For this IPL, I established the OpenPXA project hosted on SourceForge as the plan is to extend it's support to other boards as you'll figure out later. Well, the data I mentioned a while ago that are being copied and executed are actually U-Boot. Maybe you are asking -- why is it so complicated. That's because the BootROM can apparently load only the first sector from NAND, the rest has to be done by the IPL, that's how the chip is.

Back to the U-Boot. There was one more obstacle I had to fight, it was the RAM. The PXA3xx supports DDR DRAM besides some other types of DRAM and the hardware I have has the DDR DRAM. That's why I had to write the initialization routine, which soon turned out to be one hell of a hard work to be done properly. As a side story, I made a decision to stick most of the hardware initialization into the U-Boot and keep the IPL size to the minimum. That's also why the IPL is loading the U-Boot into SRAM, to avoid initializing the DRAM controller.

After all this suffering, the current status of U-Boot for the Colibri/PXA320 is such that it's usable to boot Linux from MMC or NAND, the CPU is properly configured, DRAM works just fine. There are still a few problems though. The most noticable one is that the NAND can't be written from U-Boot, but I suspect that's because of a GCC bug that produces wrong code causing the U-Boot to hang. The other problem is that the ethernet adapter doesn't work in U-Boot, but that's being worked on now. It actually works from Linux so that's not much of a problem. Just as a side note, I sometimes update the patches for U-Boot in the OpenPXA git so if you are interested, you can find them there.

Mentioning GCC bugs, let me warn you that you should not even try compiling U-Boot with >= GCC4.3. It produces weird code and makes the U-Boot not work properly, like unexpectedly hang and such. I tried fixing some of those issues in U-Boot, but there are still many so stick with GCC4.2 for the time being. The exceptionally nasty one was with 64bit division. In the end, I ripped the code for 64bit division from Linux kernel and stick it into U-Boot, but that's more like a workaround.

Before I disclose my future plans with U-Boot on PXA3xx, I first need to explain why I'm so into it probably. That's because somewhere along the process of fixing U-Boot, I made some negotiations with a certain corporation that makes CPUs and such (I'm not sure if I can disclose anything more here, sorry) and was supplied some hardware to hack on. So that's why I'm sticking very closely to this and why I'm investing such a load of my time to this low-level stuff. Also I have to say, the people I communicated with so far are awesome and I like it the way it is.

So to the plans I have with the IPL and U-Boot. Firstly, I'll have to hack on the IPL a bit to make it support PXA310, Monahans LV CPU. Then there was an idea to use the values from BootROM to auto-configure the NAND in the IPL and possibly even later in U-Boot and Linux, which is awesome as the NAND will be technically auto-detected and we won't have to care for it much. Next of course will be fixing of the ethernet on the Colibri/PXA320, ok, maybe this will be first as I'm getting close here. What I'd also like to have working is the USB host in U-Boot so the thing can also boot from an USB thumb-drive or something.

Besides these plans with IPL and U-Boot, I have an idea that there needs to be an improvement made in the Linux kernel concerning the UCB1400 chip driver which is integrated on the Colibri/PXA320 module. This improvement would make use of the recently merged possibility of passing platform data through the AC97 bus. Let me explain properly. I recently got an email from someone that the pseudo-auto-detection routine which somehow should detect the proper touchscreen IRQ GPIO for UCB1400 doesn't work on his hardware. Well that sucks and it was unavoidable anyway I think. So this patch would pertain to removal of this routine altogether and modifying all the platforms that use the UCB1400 driver to supply the touchscreen IRQ GPIO as AC97 bus platform data. There are just two or three such platforms so it's not much of a problem anyway.

Well this is about it, life was pretty busy recently and the article actually grew quite long, sorry to hold you here for so long. I hope you enjoyed your stay at least.