Hi,
the following mainboard Config.lb have not been refactored yet because they have not that much in common with other boards: asus/m2v-mx_se/Config.lb (512 kB XIP, different size calculation) technologic/ts5300/Config.lb (32 kB XIP) digitallogic/msm586seg/Config.lb (32 kB XIP) emulation/qemu-x86/Config.lb (32 kB XIP, no fallback) iei/juki-511p/Config.lb (64 kB XIP, no fallback)
To be honest, XIP size calculation seems pretty arbitrary to me. Some boards use 32 kB, some 64 kB, the majority uses 128 kB and one single board uses 512 kB.
AFAICS for ROMCC boards, making XIP larger than cache will result in cache misses, but won't corrupt anything. For CAR boards, having CAR+XIP exceed cache size will result in corruption. That means startup code should automatically calculate maximum XIP size. As a side benefit, calculating XIP stuff can be eliminated from these boards.
Can someone explain why the qemu-x86 and the IEI juki-511p targets do not have fallback options?
Regards, Carl-Daniel
On Tue, Apr 21, 2009 at 4:19 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Can someone explain why the qemu-x86 and the IEI juki-511p targets do not have fallback options?
for qemu I suppose the person who did it saw no value in it ...
we can not assume fallback in all cases anyway. In the case of linux as bootloader, there is rarely room for a fallback.
ron
On 21.04.2009 17:10, ron minnich wrote:
Since most Config.lb had the fallback and failover code enabled via conditional compilation only, I wonder if something would break if we added these options to Config.lb for the no-fallback and no-failover targets.
Regards, Carl-Daniel
On Tue, Apr 21, 2009 at 12:29 PM, Carl-Daniel Hailfinger
sure. If it does break we need to fix it anyway.
Good plan :-)
ron
-
Carl-Daniel Hailfinger -
ron minnich