It sure looks like an mpc8313 problem I once looked into
for quite some time. The solution was:
http://lists.denx.de/pipermail/u-boot/2009-March/049175.html
It could also be your DDR RAM not properly functioning. You
can let u-boot test it with the POST MEM test (which happens
before
by 1K to be safe */
- sp -= 1024;
+ /* adjust sp by 4K to be safe */
+ sp -= 4096;
lmb_reserve(lmb, sp, (CONFIG_SYS_SDRAM_BASE + get_effective_memsize() -
sp));
return ;
--
1.5.2.2
Signed-off-by: Norbert van Bolhuis nvbolh...@aimvalley.nl
I was not totally correct.
gunzip/inflate has nothing to do with this problem.
the problem is this:
- do_bootm-bootm_start-arch_lmb_reserve
reserves unused memory as in cur_sp-1k upto end-of-mem
in my case this is 0x0fb0cb28 - 0x1000
-
before I send a patch or whatsoever I'll explain what's wrong first,
maybe I overlook something.
I'm using u-boot v2008.10, customized for our PPC MPC8313 based board.
When booting a kernel (including ramdisk and dtb) space for cmdline
and board info is reserved (by arch_lmb_reserve-lmb_reserve)
= BOOTP_HDR_SIZE - sizeof(bp-bp_vend) + extlen;
NetSetIP(iphdr, 0xL, PORT_BOOTPS, PORT_BOOTPC, iplen);
--
1.5.2.2
Signed-off-by: Norbert van Bolhuis nvbolh...@aimvalley.nl
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de
Hi Prafulla,
We have a custom designed board with the M88E6185 and M88E6131
switch. The u-boot patches are very usefull, even though I already
finished some code to initialize the switches.
In our application it's more easy to fully provision the switches
when the linux kernel is up and running.
, p, p-word.Nalloc * sizeof(inflate_huft));
p = q;
}
8-
/Tor
On Tue, 2009-01-27 at 11:05 +0100, Norbert van Bolhuis wrote:
This is a MPC8313E-RDB board problem. We have 2 REV A4 boards.
I can reproduce this problem
Aha!
It seems like the root cause of this problem:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/53025/match=nasty+gunzip+problem+mpc8313e+rdb
As a MPC8313E(-RDB) user I'm happy no more checkstops will occur
for some kernels. I'm even more happy I took over the BAT settings
from
~SCCR_ENCCM) |
- (CONFIG_SYS_SCCR_ENCCM SCCR_PCICM_SHIFT);
+ (CONFIG_SYS_SCCR_ENCCM SCCR_ENCCM_SHIFT);
#endif
#ifdef CONFIG_SYS_SCCR_PCICM
--
1.5.2.2
Signed-off-by: Norbert van Bolhuis nvbolh...@aimvalley.nl
Wolfgang Denk wrote:
Dear Norbert van Bolhuis
errors.
I can obviously apply this by hand but I'd rather get Norbert up to
speed with submitting patches, esp. for the sake of future, potentially
unwieldy, contributions.
Kim
From 1414c12b58c917bd11f8b3e91fbc260962d51c47 Mon Sep 17 00:00:00 2001
From: Norbert van Bolhuis nvbolh...@linpc062
);
+ (CONFIG_SYS_SCCR_ENCCM SCCR_ENCCM_SHIFT);
#endif
#ifdef CONFIG_SYS_SCCR_PCICM
Signed-off-by: Norbert van Bolhuis nvbolh...@aimvalley.nl
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
rudresh wrote:
i'm using u-boot -1.3.0 in MPC8313 evaluation board, it having a NAND , NOR
Flash , u-boot stored in NOR flash. when i do the saveenv , reset command
the u-boot is erased. i'm not able to fix this issue. help me to fix this
issue
Thanks
Rudresh
I had a similar
This is a MPC8313E-RDB board problem. We have 2 REV A4 boards.
I can reproduce this problem on both of the MPC8313E-RDB boards
with any version of u-boot with a compressed file which contains
1 or more dynamic codes blocks and a final fixed codes block.
I have a 5k gzipped file for which the
We have 2 MPC8313E-RDB REVA4 boards.
u-boot always fails to uncompress certain compressed files.
Either the board will hang or a checkstop occurs.
The problem occurs on both our MPC8313E-RDB REVA4 boards.
Probably memory is overwritten at the end of RAM (where
u-boot is relocated to). When
I built the latest u-boot for MPC8313E-RDB, flashed it, and ran into trouble
after saving my environment to flash.
I'm using git://git.denx.de/u-boot-nand-flash.git (I believe the problem is in
other gits as well).
I'm booting from NOR flash ('make MPC8313ERDB_33_config')
The problem is
15 matches
Mail list logo
