I got to hacking on OpenPXA today. This brought some noticable progress. For some time already, there was a bothersome issue where one had to prepare a NTIM and IPL binary for the PXA300/PXA310 and a special combined IPLNTIM for PXA320.
Knowing it's most probably no use trying to get NTIM working on PXA320, I used a horrible hack. Firstly, lets recapitulate the facts. The first important fact is, that the first four bytes of the NTIM contain minimal version of BootROM this image will run on. The second important fact is that the four bytes at offset 0xc contain a date when the NTIM was created and is ignored by the BootROM.
On PXA300 and PXA310 which have BootROM v3.xx, the version string is compared to the BootROM version and if it's lower, the NTIM header is used to further control the boot process. On PXA320 on the other side, the code at 0x0 is copied to SRAM and normally executed. So the trick with unified NTIM now seems simple. It has a problem though.
Firstly I thought placing a branch instruction at offset 0x0 which would just jump past the NTIM should do the trick. How mistaken I was. The branch instruction was encoded as 0xea000028, if converted to LE it is 0x280000ea, whereas the version string in LE is 0x00030102 for BootROM v3.12, so this can't possibly work. Though there is a solution.
Branch which jumps eight bytes forward is encoded as 0xea000000, in LE 0x000000ea, which is lower than the version string. With this trick, I used the date entry and inserted an instruction which branches right past the NTIM header. You probably noticed by now, that the branch jumps 8 bytes forward, but the date entry is at 0xc. This is no problem as the entry at 0x8 is the HMIT section offset, which is zero and zero means nop.
This change has one more advantage. The IPL is now stored in block 0 of NAND just past the NTIM. It was necessary to patch the linker command so it'd correctly adjust the location of built in variables. But the result now is, one more block is free and can contain U-Boot most likely and there's no need to explicitly choose which CPU will the NTIM run at. As of today, the CPU parameter is dropped and only file called iplntim.bin is generated, holding the contents of NAND block 0.
Besides this crucial change, I moved the stack setup into a self standing function which then calls the main function of the IPL. This allows the main function to have it's variables on the stack and correctly allocated.
Friday, May 14, 2010
Thursday, May 13, 2010
Marvell, Voipac, U-Boot and insomnia
Again the time has come to push out a summary of things that I worked on recently. Mostly, I worked on the Voipac Technologies a.s. hardware, but there are some great news from Marvell as well.
Voipac
In the last entry, I mentioned adding support for the Voipac PXA270 SBC. Most of the support for this device hit mainline and will be available in 2.6.35 probably. The rest will hopefully hit 2.6.36. That's not all, I estabilished cooperation with the corporation itself and they sent me a baseboard and a CPU card equipped with OneNAND memory. This made me busy for a few days until I figured how to properly prepare the OneNAND IPL that is in U-Boot.
Voipac also sent me their JTAG adapter, which I'm very grateful for as it helped me a lot. Support for this JTAG adapter as well as for the Voipac board with NOR flash hit mainline OpenOCD already. It's currently impossible to flash OneNAND directly from OpenOCD, but one can load U-Boot into SRAM using OpenOCD and execute it from there. Then one can simply reflash the board from that U-Boot.
I then hacked on the SparseMEM support for the board a little more. There was a bug in kernel which caused the kernel to crash in very early stages with SparseMEM enabled. The bug was caused by a recent patch that was applied to the tree. Though, Catalin proposed a fix a few days before I finished debugging it, the fix was pending until someone tests it. Giving my ACK for that, the fix was applied and I submitted a SparseMEM support patch. The SparseMEM support is still unapplied though.
Besides, the company told me they have a DMA capable driver for the ParallelATA disk attached to the board. I only used the pata-platform driver which was only PIO capable and giving about 3800 kB/s reads. This was a no-go. The company didn't send me the harddrive extension for that board, so I had to fix myself a hardware hack, which allowed me to connect a CDROM drive. But ATAPI has specific needs when it comes to DMA and I was unable to get the DMA working with CDROM drive. So I made another hardware hack, even worse this time and connected a PATA 2.5" harddrive. Hacking on this driver for a while resulted in a generic pata-pxa driver, which uses the PXA DMA controller and is capable of getting over 11084 kB/s reads, but only for harddrive. For CDROM the driver falls back to PIO, but it's unlikely anyone will connect a CDROM to this SBC.
Hacking on the Voipac platform was great because the hardware is very well documented and the design is very clean.
U-Boot
I prepared a few macros that drop the need for copying so many code between PXA2xx boards in their lowlevel_init.S files. Those macros allow easy GPIO configuration, SDRAM configuration, clock and interrupt configuration as well as wakeup procedure. When using these macros, the lowlevel_init.S file consist of about 6 lines. This is a great achivement in cleaning up the u-boot-pxa. The ZipitZ2 platform was converted to use these new macros and works well.
Besides these macros, I added support for some new platforms. Namely the Voipac PXA270 with OneNAND flash and a Toradex Colibri PXA270. All of this new stuff is available in the u-boot-pxa devel branch. The branches were also recently rebased to bring the newest code from mainline u-boot.
Marvell
Recently, a friend of mine in Marvell arranged it so I was able receive two Marvell Zylonite units, one with Marvell PXA320 CPU and one with Intel PXA300 (the CPU was apparently made in Intel factory and is possibly even a prototype, though I'm unsure). This will be a great help for the OpenPXA project and he deserves a big thanks.
Also, I was told that PXA320 does not support NTIM header because the CPU is old (and has BootROM v2.22), which means I don't have to RE the BootROM anymore probably and I'd better focus on implementing a single NTIM header for both PXA320 and PXA310/300 (BootROM v3.xx). This is very likely doable through some a little non-standard alternations to the NTIM header. Though it's also likely I'll still continue to RE the BootROM just for curiousity's sake. For example I found out that WTM registers are mapped at 0x43000000 (this is undocumented in PXA3xx manual).
Others
I got my hands on one more platform -- the smarthouse.cz SH-Dmaster. It's a platform based on Toradex Colibri PXA270 module, but uses it's own baseboard. The patch for this platform is pending and is uncertain to be applied as it started a discussion about splitting development platforms to hardware that's on the mainboard and hardware that's on the CPU card.
I must not forget one more thing, I added support for the Guillemot Jet Leader Force Feedback joystick into the iforce driver. I had the patch lying around from the times of 2.6.16 or so, but never got around to sending it. Now it's already applied in linux-input. As I didn't want to reboot my PC to test the driver, I debugged it on the Voipac board.
Conclusion
Well, it's getting pretty busy recently, but I'm happy with the direction things are taking. Also, most of the hardware I have available now works well.
Voipac
In the last entry, I mentioned adding support for the Voipac PXA270 SBC. Most of the support for this device hit mainline and will be available in 2.6.35 probably. The rest will hopefully hit 2.6.36. That's not all, I estabilished cooperation with the corporation itself and they sent me a baseboard and a CPU card equipped with OneNAND memory. This made me busy for a few days until I figured how to properly prepare the OneNAND IPL that is in U-Boot.
Voipac also sent me their JTAG adapter, which I'm very grateful for as it helped me a lot. Support for this JTAG adapter as well as for the Voipac board with NOR flash hit mainline OpenOCD already. It's currently impossible to flash OneNAND directly from OpenOCD, but one can load U-Boot into SRAM using OpenOCD and execute it from there. Then one can simply reflash the board from that U-Boot.
I then hacked on the SparseMEM support for the board a little more. There was a bug in kernel which caused the kernel to crash in very early stages with SparseMEM enabled. The bug was caused by a recent patch that was applied to the tree. Though, Catalin proposed a fix a few days before I finished debugging it, the fix was pending until someone tests it. Giving my ACK for that, the fix was applied and I submitted a SparseMEM support patch. The SparseMEM support is still unapplied though.
Besides, the company told me they have a DMA capable driver for the ParallelATA disk attached to the board. I only used the pata-platform driver which was only PIO capable and giving about 3800 kB/s reads. This was a no-go. The company didn't send me the harddrive extension for that board, so I had to fix myself a hardware hack, which allowed me to connect a CDROM drive. But ATAPI has specific needs when it comes to DMA and I was unable to get the DMA working with CDROM drive. So I made another hardware hack, even worse this time and connected a PATA 2.5" harddrive. Hacking on this driver for a while resulted in a generic pata-pxa driver, which uses the PXA DMA controller and is capable of getting over 11084 kB/s reads, but only for harddrive. For CDROM the driver falls back to PIO, but it's unlikely anyone will connect a CDROM to this SBC.
Hacking on the Voipac platform was great because the hardware is very well documented and the design is very clean.
U-Boot
I prepared a few macros that drop the need for copying so many code between PXA2xx boards in their lowlevel_init.S files. Those macros allow easy GPIO configuration, SDRAM configuration, clock and interrupt configuration as well as wakeup procedure. When using these macros, the lowlevel_init.S file consist of about 6 lines. This is a great achivement in cleaning up the u-boot-pxa. The ZipitZ2 platform was converted to use these new macros and works well.
Besides these macros, I added support for some new platforms. Namely the Voipac PXA270 with OneNAND flash and a Toradex Colibri PXA270. All of this new stuff is available in the u-boot-pxa devel branch. The branches were also recently rebased to bring the newest code from mainline u-boot.
Marvell
Recently, a friend of mine in Marvell arranged it so I was able receive two Marvell Zylonite units, one with Marvell PXA320 CPU and one with Intel PXA300 (the CPU was apparently made in Intel factory and is possibly even a prototype, though I'm unsure). This will be a great help for the OpenPXA project and he deserves a big thanks.
Also, I was told that PXA320 does not support NTIM header because the CPU is old (and has BootROM v2.22), which means I don't have to RE the BootROM anymore probably and I'd better focus on implementing a single NTIM header for both PXA320 and PXA310/300 (BootROM v3.xx). This is very likely doable through some a little non-standard alternations to the NTIM header. Though it's also likely I'll still continue to RE the BootROM just for curiousity's sake. For example I found out that WTM registers are mapped at 0x43000000 (this is undocumented in PXA3xx manual).
Others
I got my hands on one more platform -- the smarthouse.cz SH-Dmaster. It's a platform based on Toradex Colibri PXA270 module, but uses it's own baseboard. The patch for this platform is pending and is uncertain to be applied as it started a discussion about splitting development platforms to hardware that's on the mainboard and hardware that's on the CPU card.
I must not forget one more thing, I added support for the Guillemot Jet Leader Force Feedback joystick into the iforce driver. I had the patch lying around from the times of 2.6.16 or so, but never got around to sending it. Now it's already applied in linux-input. As I didn't want to reboot my PC to test the driver, I debugged it on the Voipac board.
Conclusion
Well, it's getting pretty busy recently, but I'm happy with the direction things are taking. Also, most of the hardware I have available now works well.
Subscribe to:
Posts (Atom)