Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide
translations



Rockbox mail archive

Subject: RE: X5 dual boot

RE: X5 dual boot

From: RaeNye <raenye_at_netvision.net.il>
Date: Tue, 02 May 2006 16:02:11 +0200

>> 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).
Received on 2006-05-02

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy