u-boot.git/cpu, branch v2008.10 Unnamed repository; edit this file 'description' to name the repository. 83xx NAND boot: wait for LTESR[CC] 2008-10-17T15:39:18+00:00 Lepcha Suchit Suchit.Lepcha@freescale.com 2008-10-16T18:38:00+00:00 fa7b1c07e9371aea8f87ee6d3c2ea5564bd8cc8d At least some revisions of the 8313, and possibly other chips, do not wait for all pages of the initial 4K NAND region to be loaded before beginning execution; thus, we wait for it before branching out of the first NAND page. This fixes warm reset problems when booting from NAND on 8313erdb. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Kim Phillips <kim.phillips@freescale.com> 
At least some revisions of the 8313, and possibly other chips, do not
wait for all pages of the initial 4K NAND region to be loaded before
beginning execution; thus, we wait for it before branching out of the
first NAND page.

This fixes warm reset problems when booting from NAND on 8313erdb.

Signed-off-by: Scott Wood <scottwood@freescale.com>
Acked-by: Kim Phillips <kim.phillips@freescale.com>
ppc4xx: PPC44x MQ initialization 2008-10-17T11:02:42+00:00 Yuri Tikhonov yur@emcraft.com 2008-10-17T10:54:18+00:00 bf29e0ea0af03d593c64614136acc723a7a022a2 Set the MQ Read Passing & MCIF Cycle limits to the recommended by AMCC values. This fixes the occasional 440SPe hard locking issues when the 440SPe's dedicated DMA engines are used (e.g. by the h/w accelerated RAID driver). Previously the appropriate initialization had been made in Linux, by the ppc440spe ADMA driver, which is wrong because modifying the MQ configuration registers after normal operation has begun is not supported and could have unpredictable results. Comment from Stefan: This patch doesn't change the resulting value of the MQ registers. It explicitly sets/clears all bits to the desired state which better documents the resulting register value instead of relying on pre-set default values. Signed-off-by: Yuri Tikhonov <yur@emcraft.com> Signed-off-by: Stefan Roese <sr@denx.de> 
Set the MQ Read Passing & MCIF Cycle limits to the recommended by AMCC
values. This fixes the occasional 440SPe hard locking issues when the 440SPe's
dedicated DMA engines are used (e.g. by the h/w accelerated RAID driver).

Previously the appropriate initialization had been made in Linux, by the
ppc440spe ADMA driver, which is wrong because modifying the MQ configuration
registers after normal operation has begun is not supported and could
have unpredictable results.

Comment from Stefan: This patch doesn't change the resulting value of the
MQ registers. It explicitly sets/clears all bits to the desired state which
better documents the resulting register value instead of relying on pre-set
default values.

Signed-off-by: Yuri Tikhonov <yur@emcraft.com>
Signed-off-by: Stefan Roese <sr@denx.de>
Revert "85xx: Using proper I2C source clock divider for MPC8544" 2008-10-17T08:50:41+00:00 Kumar Gala galak@kernel.crashing.org 2008-10-17T02:58:49+00:00 42653b826adb319a1df06e24ef26096b2a5d9d2a This reverts commit dffd2446fb041f38ef034b0fcf41e51e5e489159. The fix introduced by this patch is not correct. The problem is that the documentation is not correct for the MPC8544 with regards to which bit in PORDEVSR2 is for the SEC_CFG. Signed-off-by: Kumar Gala <galak@kernel.crashing.org> 
This reverts commit dffd2446fb041f38ef034b0fcf41e51e5e489159.

The fix introduced by this patch is not correct.  The problem is
that the documentation is not correct for the MPC8544 with regards
to which bit in PORDEVSR2 is for the SEC_CFG.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
mpc83xx: wait till UPM completes the write to array 2008-10-14T23:10:51+00:00 Selvamuthukumar selva.muthukumar@e-coninfotech.com 2008-10-09T04:59:14+00:00 9724555755a6f1066636481b41f7094e0ce93a69 Reference manual states that MxMR[MAD] increment is the indication of write to UPM array is complete. Honour that. Also, make the dummy write explicit. also fix the comment. Signed-off-by: Selvamuthukumar <selva.muthukumar@e-coninfotech.com> Signed-off-by: Kim Phillips <kim.phillips@freescale.com> 
Reference manual states that MxMR[MAD] increment is the indication
of write to UPM array is complete. Honour that. Also, make the dummy
write explicit.

also fix the comment.

Signed-off-by: Selvamuthukumar <selva.muthukumar@e-coninfotech.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
mpc86xx: use r4 instead of r2 in lock_ram_in_cache and unlock_ram_in_cache 2008-10-13T11:57:14+00:00 Nick Spence nick.spence@freescale.com 2008-08-28T21:09:15+00:00 392438406041415fe64ab8748ec5ab5ad01d1cf7 This is needed in unlock_ram_in_cache() because it is called from C and will corrupt the small data area anchor that is kept in R2. lock_ram_in_cache() is modified similarly as good coding practice, but is not called from C. Signed-off-by: Nick Spence <nick.spence@freescale.com> 
This is needed in unlock_ram_in_cache() because it is called from C and
will corrupt the small data area anchor that is kept in R2.

lock_ram_in_cache() is modified similarly as good coding practice, but
is not called from C.

Signed-off-by: Nick Spence <nick.spence@freescale.com>
86xx: remove redudant code with lib_ppc/interrupts.c 2008-10-13T11:56:18+00:00 Kumar Gala galak@kernel.crashing.org 2008-08-19T20:05:34+00:00 5c7cbcd34d0ee566875a4fd0f2a3e5a62bba921c For some reason we duplicated the majority of code in lib_ppc/interrupts.c Not know how that happened, but there is no good reason for it. Use the interrupt_init_cpu() and timer_interrupt_cpu() since its why they exist. Signed-off-by: Kumar Gala <galak@kernel.crashing.org> 
For some reason we duplicated the majority of code in lib_ppc/interrupts.c
Not know how that happened, but there is no good reason for it.

Use the interrupt_init_cpu() and timer_interrupt_cpu() since its why
they exist.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Merge branch 'master' of /home/stefan/git/u-boot/u-boot 2008-10-13T09:17:31+00:00 Stefan Roese sr@denx.de 2008-10-13T09:17:31+00:00 1f6aa622e365fef9d87de84753eb08347e310a2a 






Merge branch 'master' of git://git.denx.de/u-boot-arm
2008-10-12T21:55:12+00:00

Wolfgang Denk
wd@denx.de

2008-10-12T21:55:12+00:00

22a871a4644d3c7f6aa1ef77ae969d775752f6fa












Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx
2008-10-12T21:12:44+00:00

Wolfgang Denk
wd@denx.de

2008-10-12T21:12:44+00:00

1f7bab0832cfd04fe534eba10e67a8b9def0dc4f












85xx: Using proper I2C source clock divider for MPC8544
2008-10-08T19:20:27+00:00

Wolfgang Grandegger
wg@grandegger.com

2008-09-30T08:55:57+00:00

dffd2446fb041f38ef034b0fcf41e51e5e489159

Measurements with our MPC8544 board showed that the I2C bus frequency
is wrong by a factor of 1.5. Obviously, the interpretation of the
MPC85xx_PORDEVSR2_SEC_CFG bit of the cfg_sec_freq register is not
correct. There seems to be an error in the 8544 RM.

Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>





Measurements with our MPC8544 board showed that the I2C bus frequency
is wrong by a factor of 1.5. Obviously, the interpretation of the
MPC85xx_PORDEVSR2_SEC_CFG bit of the cfg_sec_freq register is not
correct. There seems to be an error in the 8544 RM.

Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>