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

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@lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net] On Behalf Of Woodruff, Richard Sent: Monday, January 19, 2004 12:08 PM To: 'Anders Larsen' Cc: u-boot-users@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@lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net] On Behalf Of Anders Larsen Sent: Friday, January 09, 2004 5:14 AM To: Wolfgang Denk Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] [PATCH] fix the ARM memory layout
Wolfgang Denk wd@denx.de schreibt:
In message fc.004c4e48001e6497004c4e48001e6497.1e64ae@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

"Woodruff, Richard" r-woodruff2@ti.com schreibt:
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).
Hi Richard,
the power of peer review simply cannot be overestimated :-) I'll copy your changes from arm925 to the other ARMs and submit a patch.
-- 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.
Duh. I'll fix that, too.
-- 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).
This is probably true for all ARMs...
-- the introduction of CFG_GBL_DATA_SIZE is sort of a hollow gesture.
Seems you're right about that, too. I'll look back into my pool of changes to find out why I did it that way.
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.
Thanks for taking the time to dig through the mess I created ;-)
Cheers Anders

Dear Richard & Anders,
in message 71555548814716479478431542AA5F8A5A9DDF@dlee2k04.ent.ti.com you wrote:
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).
Can you please submit this as a proper patch (against current state of CVS, i. e. with Anders' patch as base).
And what about the other ARM processors?
Best regards,
Wolfgang Denk

Wolfgang Denk wd@denx.de schreibt:
Dear Richard & Anders,
in message 71555548814716479478431542AA5F8A5A9DDF@dlee2k04.ent.ti.com you wrote:
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).
Can you please submit this as a proper patch (against current state of CVS, i. e. with Anders' patch as base).
And what about the other ARM processors?
Hi Wolfgang,
I'll port Richard's fixes to the current CVS and to the other ARM processors as soon as my current workload permits - please be patient with me (but I guess you're busy with the Embedded World fair anyway ;-)
Cheers Anders

Dear Anders,
in message fc.004c4e480020ffe03b9aca00479b883e.210060@rea.de you wrote:
I'll port Richard's fixes to the current CVS and to the other ARM processors as soon as my current workload permits - please be
Thanks in advance.
patient with me (but I guess you're busy with the Embedded World fair anyway ;-)
I know all too well what "current workload" usually means ;-) And yes, the Embedded World does keep me busy, too...
I apologize that it took so long to get allt his stuff in - I'm trying hard now to get back in sync with all the patches that piled up. I will make sure that your patch goes in semi-immediately whenever you send it.
Best regards,
Wolfgang Denk
participants (3)
-
Anders Larsen
-
Wolfgang Denk
-
Woodruff, Richard