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 relocation
ends at 0x%08lx\n", sp);
- /* adjust sp 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-
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
- do_bootm->do_bootm_linux->boot_body_linux->bo
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)
zeof(bp->bp_vend) + extlen;
iplen = 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
___
U-Boot mailing list
U-Boot@lists.denx
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
1203e7995a9b4] zlib.c
> +++ [88e71e289d0241baaa9db0624b98f00b5f1774b5] zlib.c
> @@ -1604,6 +1604,7 @@
>while (p != Z_NULL)
>{
> q = (--p)->next;
> + udelay(10);
> ZFREE(z, p, p->word.Nalloc * sizeof(inflate_huft));
> p = q;
>}
>
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 MPC8315
(im->clk.sccr & ~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
Wolfgang Denk wrote:
>
.
It appears Norbert cut-n-pasted the diff and thus introduced whitespace
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 1414c12b58c917bd11f8b3e91fbc
< SCCR_PCICM_SHIFT);
+ (CONFIG_SYS_SCCR_ENCCM << SCCR_ENCCM_SHIFT);
#endif
#ifdef CONFIG_SYS_SCCR_PCICM
Signed-off-by: Norbert van Bolhuis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
t with u-boot.bin. If the value
> extracted from the map file is less than the u-boot.bin size, we could
> generate
> an error/warning. Any comments?
>
> Best regards,
> Frank
>
> On Tue, Feb 24, 2009 at 10:09 AM, Norbert van Bolhuis
> wrote:
>> rudresh wrote:
&
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 s
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 using
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 pro
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 CONFIG
Nowadays, do many (PowerPC) embedded devices already risk omitting
NOR flash and use a NAND device solely for booting and storing images ?
I'm talking about systems with 10 years life-cycle (so no
MP3-players nor medical systems but somewhere in between).
We have a MPC8313E-RDB and I know bootin
17 matches
Mail list logo
