Dear Brian Hutchinson,
In message y2o3d1967ab1004071745y111d704oda973290a7a4a...@mail.gmail.com you
wrote:
#if CFG_ENV_SECT_SIZE CFG_ENV_SIZE
up_data = (end_addr_new + 1 - ((long)flash_addr_new + CFG_ENV_SIZE));
debug (Data to save 0x%x\n, up_data);
if (up_data) {
Dear Brian Hutchinson,
In message q2m3d1967ab1004071747zf70f0006x1f4eb1012f66e...@mail.gmail.com you
wrote:
Looks like the malloc of up_data (which is 0x3) is failing.
So maybe you want to increase the size of the malloc arena?
My env size is 0x1 so why am I trying to malloc
Dear Brian Hutchinson,
In message s2x3d1967ab1004071751j50c177f6haaafa222f76f3...@mail.gmail.com you
wrote:
...
## Booting image at 0020 ...
Image Name: Linux-2.6.28-picochip-3.2.0
Created: 2010-04-05 19:24:18 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
On Thu, Apr 8, 2010 at 6:08 AM, Wolfgang Denk w...@denx.de wrote:
Dear Brian Hutchinson,
In message s2x3d1967ab1004071751j50c177f6haaafa222f76f3...@mail.gmail.com
you wrote:
...
## Booting image at 0020 ...
Image Name: Linux-2.6.28-picochip-3.2.0
Created: 2010-04-05
Hi Wolfgang,
... which to my understanding is intended to allow you to save RAM by
using a env. smaller than your sector size which is my case.
This has nothing to do with saving RAM.
You are right (as usual). I was searching the archives before I
started posting and I read something to
Dear Brian Hutchinson,
In message k2m3d1967ab1004080409w81bf0842pa84001760c214...@mail.gmail.com you
wrote:
A load address of 0x8000 / entry point of 0x8000 is pretty
certainly bogus on a ARM system, which typically has ROM at this
address range. =A0Are you sure that you have
Hi Wolfgang,
I noticed my malloc pool was only 128k so I changed that to 256 and it
didn't help.
CFG_MONITOR_LEN is set to 256k, the same size as a flash sector.
Well, and what hapopens when you inclrease the malloc size to - say -
1024 kB ?
About a hour before your post, I tried bumping
Hi,
I'm using u-boot 1.1.6 and have been using a single 256k flash sector
for the environment. I want to use the redundant env. feature so I
changed my config to:
#define CFG_ENV_IS_IN_FLASH 1 /* Environment
variables stored in Flash memory */
#define CFG_ENV_ADDR
Update.
I'm on a ARM 926 by the way. Forgot to mention that.
I fired up my trusty JTAG OpenOCD and gdb to investigate this more.
Looks like the malloc of up_data (which is 0x3) is failing.
My env size is 0x1 so why am I trying to malloc 0x3?
Regards,
Brian
#if CFG_ENV_SECT_SIZE CFG_ENV_SIZE
up_data = (end_addr_new + 1 - ((long)flash_addr_new + CFG_ENV_SIZE));
debug (Data to save 0x%x\n, up_data);
if (up_data) {
if ((saved_data = malloc(up_data)) == NULL) {
printf(Unable to save the
Sorry for the top post. Resending in plain text as original message was UTF-8
On Wed, Apr 7, 2010 at 11:14 AM, Brian Hutchinson b.hutch...@gmail.com wrote:
Hi,
I'm using u-boot 1.1.6 and have been using a single 256k flash sector
for the environment. I want to use the redundant env. feature
Sorry for the top post. Resending in plan test. This was the second
message of the thread.
On Wed, Apr 7, 2010 at 4:14 PM, Brian Hutchinson b.hutch...@gmail.com wrote:
Update.
I'm on a ARM 926 by the way. Forgot to mention that.
I fired up my trusty JTAG OpenOCD and gdb to investigate
Sorry for top post. This is the third message of the thread being
re-sent in plain text. I'll also add that the test case below also
hangs on trying to bootm a kernel in flash just as it did in the nfs
boot case of the shown below.
On Wed, Apr 7, 2010 at 5:07 PM, Brian Hutchinson
13 matches
Mail list logo
