[U-Boot-Users] -- fix the ARM memory layout -- couple errors.

[Woodruff, Richard]

Anders,

After tracing though the code I found a couple bugs in the patch.  I think I
corrected them and included the version of start.S for the ARM925 which I am
using.  I now get the expected register dump (or alternative function I've
defined).

-- The 3 reserved words for abort info is carved out at the top of the stack
(high addr).  The converted macro's treated this info as if it were at the
"bottom" of the stack by subtracting off CONFIG_STACKSIZE.  This is not
correct or consistent with the previous def's which happened just above.
The CONFIG_STACKSIZE should not be used at all.  It has little meaning at
present, perhaps more with irq's are enabled.

-- I noticed that get_bad_stack() actually was not correct for SWI's and
would crash my board in an unexpected way.  The reason is that the SWI
enters the system in SVC mode and the get_bad_stack() macro assumes a banked
SP (R13)...ie it destroys the SVC mode SP, then switches to SVC mode (its
already there) and there it tries to write on the bad stack.  I added a new
macro to my build which I think fixed the problem (assuming the svc stack is
good).

-- the introduction of CFG_GBL_DATA_SIZE is sort of a hollow gesture.  It is
perhaps a good seg way, but at present doesn't do much other than waist some
space.  Lib_arm/board.c currently sets the global area to a stack allocated
object which happens to be on the top of the stack as it's the first
definition. Carving out space for it is just fine, however this space never
used.  ... It might be nice to have a separate section for this object which
the loader could initialize at some other spot, say, sram...later perhaps.

Other than those few bits everything else seems to be working.  Thanks for
the effort.  Your work is forcing me to switch to the preferred memory
setup.

Regards/thanks,

Richard W.





-----Original Message-----
From: u-boot-users-admin at lists.sourceforge.net
[mailto:u-boot-users-admin at lists.sourceforge.net] On Behalf Of Woodruff,
Richard
Sent: Monday, January 19, 2004 12:08 PM
To: 'Anders Larsen'
Cc: u-boot-users at lists.sourceforge.net
Subject: RE: [U-Boot-Users] [PATCH] fix the ARM memory layout

Anders,

I just applied this patch to my ARM board, and it seems to mostly work.
Prior to the memory change I would get stack dumps on aborts, since applying
the patch I am unable to get on to print.  Have you been able to generate
one?  I hook up the JTAG and do a little tracing...

One other comment... I have some test code which does a crc32 over the rom
portion of u-boot to help validate the image, this code used armboot_end.
In your patch you removed that symbol.  Bss_start seems to be an "almost"
proper substitution.  I say almost as an ALIGN 4 is done before it.  If the
cmd size ended on a byte or half word boundary this would mess up the crc32
from what I might expect...In practice it might be that GCC generates things
such that it pads to this anyway).  Adding another symbol is easy, just
thought I'd point out that it "might" not be strictly equivalent the way you
did it...

Regards,

Richard W.

-----Original Message-----
From: u-boot-users-admin at lists.sourceforge.net
[mailto:u-boot-users-admin at lists.sourceforge.net] On Behalf Of Anders Larsen
Sent: Friday, January 09, 2004 5:14 AM
To: Wolfgang Denk
Cc: u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] [PATCH] fix the ARM memory layout

Wolfgang Denk <wd at denx.de> schreibt:
>In message <fc.004c4e48001e6497004c4e48001e6497.1e64ae at rea.de> you wrote:
>> 
>> here's a fresh version of my rather intrusive patch from the 17.th sept.
>> to rearrange the ARM memory layout to bring it in line with the README.
>
>Sorry, I'm working through my backlog sequentially,  and  I  already
>added  the  other  patch.  Can  you please check your current version
>against current top-of-tree in CVS and provide a new diff?

Hi Wolfgang,

the attached patch (against CVS 2004-01-08) fixes the rest of the ARM
stuff I had in the pipe.

In particular, the abort-stack is now set up in the correct RAM area
(which I had neglected in my previous patches), and the BSS is zeroed
out as it should be (which most previous ARM implementations had
neglected).

Furthermore, the magic variables 'armboot_end' and 'armboot_end_data'
of the linker scripts are replaced by '__bss_start' and '_end', resp.,
which is a further step to eliminate unnecessary differences between
the implementation of the CPU architectures.

Compilation tested with MAKEALL arm, functionality only tested on my
PXA-based board.

CHANGELOG:
   Fix the ARM memory layout.

Cheers
 Anders

(Patch gzipped due to size constraints on the list)



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

-------------- next part --------------
A non-text attachment was scrubbed...
Name: start.S
Type: application/octet-stream
Size: 11160 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20040119/744b010f/attachment.obj