>> Since the OF relies on what the preloader did. >Yes, we must make sure that we don't mess it up for the OF, but I think the solution is to restore the registers before starting the OF.
Cowon wrote both the preloader and the OF, so they rely on each other in many ways (some less predictable than others, e.g., using the byte at 0x30000000 to signal RTC alarm or just leaving the IDEConfig registers in a certain state) My aim in writing a dual-bootloader is to decide as quickly as possible if OF is to be loaded and only afterwards to setup registers for RB. Some of the registers even stay in their default settings (which are unknown to me). >> Serial vs. parallel? >> 1-bit transfer vs. 8-bit is 8 times slower, I guess. >> Same job done in less CPU work. >The difference is not parallel vs serial, I2C is a serial bus. The difference is using the internal I2C controller vs "bit-banging". >The Cowon firmware uses the I2C controller, and we don't. >The X5 version of the Rockbox I2C driver is slow at the moment, so it can be optimized. However, the performance is not important for the boot loader. You could also say that it doesn't matter since you only transfer a few bytes, but the point is that RB's pcf50606 functions aren't better than the OF's. >> (The next totalliy unrelated topic would be DMA for ATA, but I leave >> this for later) >Yes, ATA DMA might speed things up a little, but not as much as you might think. The assembler optimized ATA driver is pretty fast. Again I think it's a don't-burden-cpu-for-no-reason thing. DMA is there for a reason; let the CPU spend its cycles in SWCODEC (or GUI, whatever).
