Hi Tor,
Did I ever respond to your email, I forgot.
Anyway it's nice to see others have the same problem also.
The root cause of this has been found, did you see this:
It's a CPU memory cache problem (I could have known).
details:
Scott Wood wrote:
> This board currently sets DBAT6 to cover al
Hi Norbert,
I missed the start of this thread. So my apologies if im barking up the
wrong tree :)
We had problems uncompressing zImages on our 8313 board. But always
suspected some memory timing issues, or perhaps some strangeness in
8313.
I tracked our problems down to a specific line in lib_ge
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
Hi Wolfgang,
thanks for your reply.
Wolfgang Denk wrote:
> Are you sure it is only an issue of gzip compression, and not for
> example of image sizes?
>
The "gzip -8" compressed kernel, which does work, is obviously bigger
(vmlinux.bin.gz=1717766 (i.s.o. 1717544). Uncompressed size
is unchange
Dear "N. van Bolhuis",
In message <49746a3b.5070...@aimvalley.nl> you wrote:
>
> A certain powerpc 2.6.28 kernel (which is by default compressed with
> gzip -9) fails to load with u-boot v2008.10. It results in a machine
> check stop. I'm testing on a MPC8313-RDB.
...
> If I manually compress tha
A certain powerpc 2.6.28 kernel (which is by default compressed with
gzip -9) fails to load with u-boot v2008.10. It results in a machine
check stop. I'm testing on a MPC8313-RDB.
Btw. the linux-2.6.28/arch/powerpc/boot/wrapper script takes care of
compressing with "gzip -9".
On my host linux pc
6 matches
Mail list logo