[U-Boot-Users] [PATCH] fix the ARM memory layout
Hi,
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.
This has the positive side-effect of actually allow U-Boot to run on PXA- and IXP-based targets; the current implementation sets up the heap using bogus addresses causing u-boot to crash (this even applies to the recently added board "ixdp425").
This patch doesn't go all the way, though, since doing away with the board-specific setting of TEXT_BASE would require the code to be position-independent, which at least the cpu initialization code in cpu/*/start.S is _not_.
CHANGELOG: Bring the ARM memory layout in line with the documentation.
Cheers Anders
On Wednesday 12 November 2003 12:23 pm, Anders Larsen wrote:
Hi,
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.
This has the positive side-effect of actually allow U-Boot to run on PXA- and IXP-based targets; the current implementation sets up the heap using bogus addresses causing u-boot to crash (this even applies to the recently added board "ixdp425").
I don't disagree that memory layout for ARM is broken. But, I've never seen a crash on any of my Xscale boards, including a couple of new ones based on ixdp425 and cradle.
Kyle.
Kyle Harris kharris@nexus-tech.net schreibt:
On Wednesday 12 November 2003 12:23 pm, Anders Larsen wrote:
This has the positive side-effect of actually allow U-Boot to run on PXA- and IXP-based targets; the current implementation sets up the heap using bogus addresses causing u-boot to crash (this even applies to the recently added board "ixdp425").
I don't disagree that memory layout for ARM is broken. But, I've never seen a crash on any of my Xscale boards, including a couple of new ones based on ixdp425 and cradle.
Hi Kyle,
Do you by any chance happen to have RAM at and around address 0x0badc0de ? Otherwise I don't see how PXA/IXP could possible work, for the reasons Richard already gave. (see also http://www.catb.org/~esr/jargon/html/S/schroedinbug.html ;-)
(BTW, I recognize you've contributed significantly to the PXA implementation I'm relying on and I'd like to thank you for that).
Cheers Anders
Good afternoon...
Porting u-boot-1.0.0 to SSH box (SIPO) now...
Everything seems to be okay so far except serial input... I see level changes on PD[28] when typing something in the terminal application...
U-Boot 1.0.0 (Nov 13 2003 - 13:24:09)
MPC8260 Reset Status: External Soft, External Hard
MPC8260 Clock Configuration - Bus-to-Core Mult 2.5x, VCO Div 2, 60x Bus Freq 40-120, Core Freq 100-240 - dfbrg 0, corecnf 0x06, busdf 3, cpmdf 1, plldf 0, pllmf 1 - vco_out 264000000, scc_clk 66000000, brg_clk 66000000 - cpu_clk 165000000, cpm_clk 132000000, bus_clk 66000000
CPU: MPC8260 (HiP3 Rev 01, Mask A.1 1K22A-XC) at 165 MHz Board: SSH Box (SIPO) DRAM: 64 MB FLASH: 8 MB In: serial Out: serial Err: serial PPARD: c3001b... PSORD: 30002... PDIRD: 36... PDATD: 483f03a... ssh>
Have set in my "include/configs/ssh.h":
#define CONFIG_CONS_ON_SCC /* define if console on SCC */ #define CONFIG_CONS_INDEX 2
as also in "board/ssh/ssh.c":
/* PD28 */ { 1, 1, 0, 0, 0, 0 }, /* SCC2 console RXD */ /* PD27 */ { 1, 1, 0, 1, 0, 0 }, /* SCC2 console TxD */ /* PD26 */ { 1, 0, 0, 1, 0, 1 }, /* SCC2 console RTS */
Something I have forgotten to enable receiving on SCC2?
(board works with original ssh bootloader ;o)
rick
Hi All,
On Thursday 13 November 2003 04:14 am, Anders Larsen wrote:
Kyle Harris kharris@nexus-tech.net schreibt:
On Wednesday 12 November 2003 12:23 pm, Anders Larsen wrote:
This has the positive side-effect of actually allow U-Boot to run on PXA- and IXP-based targets; the current implementation sets up the heap using bogus addresses causing u-boot to crash (this even applies to the recently added board "ixdp425").
I don't disagree that memory layout for ARM is broken. But, I've never seen a crash on any of my Xscale boards, including a couple of new ones based on ixdp425 and cradle.
Hi Kyle,
Do you by any chance happen to have RAM at and around address 0x0badc0de ? Otherwise I don't see how PXA/IXP could possible work, for the reasons Richard already gave. (see also http://www.catb.org/~esr/jargon/html/S/schroedinbug.html ;-)
Yeh, I don't doubt there is a problem. I guess I need to take a closer look and see why it works. But finding the time to work on something that actually already works is difficult...(got plenty of stuff that doesn't work to keep me busy).
(BTW, I recognize you've contributed significantly to the PXA implementation I'm relying on and I'd like to thank you for that).
You're welcome. But all I did was put the framework in place so that you and Richard and others can make it work correctly ;)
Kyle.
On Thursday 13 November 2003 09:19 am, Kyle Harris wrote:
Do you by any chance happen to have RAM at and around address 0x0badc0de ? Otherwise I don't see how PXA/IXP could possible work, for the reasons Richard already gave. (see also http://www.catb.org/~esr/jargon/html/S/schroedinbug.html ;-)
Yeh, I don't doubt there is a problem. I guess I need to take a closer look and see why it works.
I think the mystery is solved. I just updated my latest pxa to 1.0.0. It was based on 0.2.3 and the ixp port was based on 0.4.0. Early versions of the code, while not perfect, did run. Definitely a problem with the later stuff without proper patches (thanks for the patches).
Kyle.
Kyle Harris kharris@nexus-tech.net schreibt:
On Thursday 13 November 2003 09:19 am, Kyle Harris wrote:
Do you by any chance happen to have RAM at and around address 0x0badc0de ? Otherwise I don't see how PXA/IXP could possible work, for the reasons Richard already gave. (see also http://www.catb.org/~esr/jargon/html/S/schroedinbug.html ;-)
Yeh, I don't doubt there is a problem. I guess I need to take a closer
look
and see why it works.
I think the mystery is solved. I just updated my latest pxa to 1.0.0. It was based on 0.2.3 and the ixp port was based on 0.4.0. Early versions of the code, while not perfect, did run. Definitely a problem with the later stuff without proper patches (thanks for the patches).
Hi Wolfgang,
what's needed to make the patch worthy of inclusion? I know the patch doesn't go all the way you want, but IMHO we need several steps for that in order not to wreak too much havoc.
Cheers Anders
Dear Anders,
in message fc.004c4e48001ea0e0004c4e48001e6497.1ea0ee@rea.de you wrote:
what's needed to make the patch worthy of inclusion?
More time :-(
I know the patch doesn't go all the way you want, but IMHO we need several steps for that in order not to wreak too much havoc.
You are right, and I am perfectly willing to add this, but at the moment I'm caught in some other activities. I hope to find some more time for U-Boot next week.
Best regards,
Wolfgang Denk
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 sequentuially, 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?
Thanks.
Best regards,
Wolfgang Denk
On Sun, 07 Dec 2003 01:17:08 +0100 Wolfgang Denk wd@denx.de wrote:
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 sequentuially, 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,
sure, only I can't say when I'll be able to do it, since cvs.sourceforge.net is currently rejecting connections :-(
Cheers Anders
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 sequentuially, 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)
Dear Anders,
in message fc.004c4e48001fbb1a3b9aca00884cdb6e.1fbb43@rea.de you wrote:
the attached patch (against CVS 2004-01-08) fixes the rest of the ARM stuff I had in the pipe.
Thanks a lot, added.
Compilation tested with MAKEALL arm, functionality only tested on my PXA-based board.
I tested it on the SMDK2400 and TRAB boards with several memory con- figurations. Workes fine. Thanks a lot!!
Best regards,
Wolfgang Denk
participants (5)
-
Anders Larsen -
Anders Larsen -
Kyle Harris -
Richard Klingler -
Wolfgang Denk