[U-Boot] Porting to custom board with a PXA270
Dear U-booters,
I'm in the process of writing my bachelor thesis about porting Linux to custom board made by a company here in Denmark. As a part of this process, I am also trying to port U-boot to the board with limited success so far, unfortunately.
As I've mentioned in the topic, it has a PXA270, with 16 megs of Intel Strata P30 flash and 16MB of some Mobile SDRAM MT48H8M16LF. As far as I'm aware, this should be a relatively common configuration...
I started off by basing my port on the balloon3, as it seemed to be very clean and similar in specs. I've set up the clocks, memory registers and gpios, but i seem to be hitting some weird issues.
First, here is my boot log:
U-Boot 2010.12-rc1-00026-g0c0892b-dirty (Nov 18 2010 - 15:51:10)
U-Boot code: 00000000 -> 0002CEFC BSS: -> 0006A700 monitor len: 0006A700 ramsize: 01000000 TLB table at: a0ff0000 Top of RAM usable for U-Boot at: a0ff0000 Reserving 425k for U-Boot at: a0f85000 Reserving 264k for malloc() at: a0f43000 Reserving 24 Bytes for Board Info at: a0f42fe8 Reserving 92 Bytes for Global Data at: a0f42f8c New Stack Pointer is: a0f42f88 RAM Configuration: Bank #0: a0000000 16 MiB relocation Offset is: a0f85000 monitor flash len: 0002CEFC Now running in RAM - U-Boot at: a0f85000 Using default environment
himport_r: can't malloc 72 bytes, ret = (null) ERROR: Me sad :( Environment import failed: errno = -1 ret: -2
at env_common.c:195/set_default_env() data abort pc : [<e1a00000>] lr : [<a0f94aa0>] sp : a0f42f18 ip : 0000000c fp : 0001ce59 r10: ffffffe8 r9 : 00000000 r8 : a0f42f8c r7 : fffffffe r6 : 0d8aa869 r5 : a0f42f64 r4 : 000390b4 r3 : 0d8aa86a r2 : ffffffe7 r1 : ffffffff r0 : 00000000 Flags: nzcv IRQs on FIQs on Mode USER_26 Resetting CPU ...
resetting ...
As far as I can tell, the bootloader successfully relocates itself into RAM but fails to allocate 72bytes for the environment.
Before someone mentions, yes, I have added some extra lines to try to trace back what could be going wrong..
I have attached a diff of my changes, hope you guys can help me.
Cheers,
Attila Sukosd
Dear Attila Sukosd,
In message AANLkTikDfFa4VZ3uo=vfht7-ZinpiBT=CqmvVzuUrjGU@mail.gmail.com you wrote:
...
Reserving 264k for malloc() at: a0f43000 Reserving 24 Bytes for Board Info at: a0f42fe8 Reserving 92 Bytes for Global Data at: a0f42f8c New Stack Pointer is: a0f42f88 RAM Configuration: Bank #0: a0000000 16 MiB relocation Offset is: a0f85000 monitor flash len: 0002CEFC Now running in RAM - U-Boot at: a0f85000 Using default environment
himport_r: can't malloc 72 bytes, ret = (null) ERROR: Me sad :( Environment import failed: errno = -1 ret: -2
...
As far as I can tell, the bootloader successfully relocates itself into RAM but fails to allocate 72bytes for the environment.
Please keep in mind that computers are dumb. Yes, they really are (hope none of them listens in right now).
When they tell you "I cannot to that" they usually really mean it. So the best thing in such a situation is to ask them (or, if they don't answer, ask yourself): "Why cannot you do that?"
In the case of a failing malloc() the first thing that comes to my mind is: well, maybe all available memory has been used up.
So why don't you simply try and provide more (for a test, much more) room for malloc? Try, for example, setting CONFIG_SYS_MALLOC_LEN to "(1024 * 1024)" or such?
IIRC I told you the same on IRC already, but you failed to comment...
Best regards,
Wolfgang Denk
On Sun, Nov 21, 2010 at 4:59 PM, Wolfgang Denk wd@denx.de wrote:
Dear Attila Sukosd,
In message AANLkTikDfFa4VZ3uo=vfht7-ZinpiBT=CqmvVzuUrjGU@mail.gmail.com you wrote:
...
Reserving 264k for malloc() at: a0f43000 Reserving 24 Bytes for Board Info at: a0f42fe8 Reserving 92 Bytes for Global Data at: a0f42f8c New Stack Pointer is: a0f42f88 RAM Configuration: Bank #0: a0000000 16 MiB relocation Offset is: a0f85000 monitor flash len: 0002CEFC Now running in RAM - U-Boot at: a0f85000 Using default environment
himport_r: can't malloc 72 bytes, ret = (null) ERROR: Me sad :( Environment import failed: errno = -1 ret: -2
...
As far as I can tell, the bootloader successfully relocates itself into
RAM
but fails to allocate 72bytes for the environment.
Please keep in mind that computers are dumb. Yes, they really are (hope none of them listens in right now).
When they tell you "I cannot to that" they usually really mean it. So the best thing in such a situation is to ask them (or, if they don't answer, ask yourself): "Why cannot you do that?"
In the case of a failing malloc() the first thing that comes to my mind is: well, maybe all available memory has been used up.
So why don't you simply try and provide more (for a test, much more) room for malloc? Try, for example, setting CONFIG_SYS_MALLOC_LEN to "(1024 * 1024)" or such?
IIRC I told you the same on IRC already, but you failed to comment...
Hi,
Thanks for your fast reply. I have indeed tried that too, 128kbytes, 256kbytes, 512kbytes and 1MB for malloc, with the same issue.
Additionally, I failed to mention another issue in my previous email, which is, I seem to be getting random behaviours from the board depending on what I modify in the code.
For example, if I add one extra debug() or puts() line under another, flash the new version on the board, the board fails to boot, and I don't see any output on the serial.
Other times, I see some output on the serial, but fails to relocate to RAM. (Note: I do not change anything other than adding one extra puts line, so all configurations stay the same)
This uncertainty worries me a bit as I do not see a clear reason on why this would be happening...
Rgrds,
Attila
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Be careful what you wish for. You never know who will be listening. - Terry Pratchett, _Soul Music_
Dear Attila Sukosd,
In message AANLkTin=ZZFuUQDoU1hck-cZvJ62L32gMsSeO2cAWZUc@mail.gmail.com you wrote:
Additionally, I failed to mention another issue in my previous email, which is, I seem to be getting random behaviours from the board depending on what I modify in the code.
usually thatmeans that your RAM is not working stable, i. e. your ram init sequence might be incorrect and/or incomplete.
Best regards,
Wolfgang Denk
participants (2)
-
Attila Sukosd -
Wolfgang Denk