A hal_delay_us patch...
Tested in RedBoot and in a program using the kernel.
This hal_delay_us() works whit an additional delay from ~10us @ 48MHz MCK.
Tested from 10us to 10s...
Oliver
PIT_fix2.diff
Description: Binary data
Change the page-calculations and make the flash_lock_block/unlock() work...
Oliver
flash_lock_fix.diff
Description: Binary data
Perfekt...
Thanks Oliver
Andrew Lunn schrieb:
On Sun, Apr 02, 2006 at 09:53:46PM +0200, oliver munz @ s p e a g wrote:
This patch allows, to make images whit a 0x1..0x18000 offset.
The reason of this is to allow a RedBoot in the memory from in the range
of 0x10..0x10
Index: packages/devs/eth/phy/current/cdl/phy_eth_drivers.cdl
===
RCS file:
/cvs/ecos/ecos/packages/devs/eth/phy/current/cdl/phy_eth_drivers.cdl,v
retrieving revision 1.9
diff -u -r1.9 phy_eth_drivers.cdl
---
The at91sam7??? targets can configured as RAM. But the header and
linker-include files are missing.
Here are two files for the 512kByte-flash targets...
The image will start at 0x204000, letting enough space for a redboot. It
works but i'm not sure if it's realy ok, or if there are stupid
If the PIT is used as system-timer and the kernel does the
initialisation of it late - may be after hanging a long time in a
boot-monitor - then it's possible, that the kernel delay_us dont work
korrekt. This is because the PIT looks at exact matches, and thus, if
You set the compare-register
Sorry, the PIT-patch i sent was a wrong one. But there is also a new
change in the startup and few register-definitions in the plf_io instead
the flash-driver, and so i will make a big diff including all when im
sure it works all together...
Hier comes the announced patch:
1. It allows the use of the second flash in the 512k devices.
2. It solves a possible problem with a late PIT-initalisation.
3. It improves the startup-time and prevents changes in the holly
system-clock when booting from a boot-monitor.
4. It removes a spaces at
