* [U-Boot-Users] arm920t RAM relocation broken? @ 2008-03-06 21:05 Cory T. Tusar 2008-03-07 0:03 ` Ulf Samuelsson 0 siblings, 1 reply; 3+ messages in thread From: Cory T. Tusar @ 2008-03-06 21:05 UTC (permalink / raw) To: u-boot -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Commit d4fc6012 added an #ifdef CONFIG_AT91RM9200 construct around the RAM relocation bits in cpu/arm920t/start.S. More directly, it added an entire secondary relocation snippet surrounded by an #ifdef CONFIG_BOOTBINFUNC construct. It appears that this second implementation was later removed in commit 80767a6c, but the #ifdef CONFIG_AT91RM9200 logic was not removed also. Is RAM relocation only intended to function on at91rm9200 boards, or shall I submit a patch fixing the above? - -Cory - -- Cory T. Tusar Embedded Systems Engineer Videon Central, Inc. 2171 Sandy Drive State College, PA 16803 (814) 235-1111 x316 (814) 235-1118 fax "There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies." --Sir Charles Anthony Richard Hoare -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFH0FyBHT1tsfGwHJ8RAvOfAJ9y75jQiJih+IJrbD2beYyVpYYpVwCfQQyz /eeY22e7RSWYFbH0iLFcGEM= =yCLN -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 3+ messages in thread
* [U-Boot-Users] arm920t RAM relocation broken? 2008-03-06 21:05 [U-Boot-Users] arm920t RAM relocation broken? Cory T. Tusar @ 2008-03-07 0:03 ` Ulf Samuelsson 2008-03-07 19:02 ` Cory T. Tusar 0 siblings, 1 reply; 3+ messages in thread From: Ulf Samuelsson @ 2008-03-07 0:03 UTC (permalink / raw) To: u-boot ----- Original Message ----- From: "Cory T. Tusar" <ctusar@videon-central.com> To: <u-boot-users@lists.sourceforge.net> Cc: <peter.pearse@arm.com> Sent: Thursday, March 06, 2008 10:05 PM Subject: [U-Boot-Users] arm920t RAM relocation broken? > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Commit d4fc6012 added an #ifdef CONFIG_AT91RM9200 construct around the > RAM relocation bits in cpu/arm920t/start.S. More directly, it added an > entire secondary relocation snippet surrounded by an > #ifdef CONFIG_BOOTBINFUNC construct. > > It appears that this second implementation was later removed in commit > 80767a6c, but the #ifdef CONFIG_AT91RM9200 logic was not removed also. > > Is RAM relocation only intended to function on at91rm9200 boards, or > shall I submit a patch fixing the above? > > - -Cory > Does this mean that the AT91RM9200 always relocates? Then the code is simply wrong. If you run from a serial flash, then the code is already relocated and is executing from SDRAM at this point, so the code will crash. Best Regards Ulf Samuelsson ^ permalink raw reply [flat|nested] 3+ messages in thread
* [U-Boot-Users] arm920t RAM relocation broken? 2008-03-07 0:03 ` Ulf Samuelsson @ 2008-03-07 19:02 ` Cory T. Tusar 0 siblings, 0 replies; 3+ messages in thread From: Cory T. Tusar @ 2008-03-07 19:02 UTC (permalink / raw) To: u-boot -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ulf Samuelsson wrote: > ----- Original Message ----- > From: "Cory T. Tusar" <ctusar@videon-central.com> > To: <u-boot-users@lists.sourceforge.net> > Cc: <peter.pearse@arm.com> > Sent: Thursday, March 06, 2008 10:05 PM > Subject: [U-Boot-Users] arm920t RAM relocation broken? > > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Commit d4fc6012 added an #ifdef CONFIG_AT91RM9200 construct around the >> RAM relocation bits in cpu/arm920t/start.S. More directly, it added an >> entire secondary relocation snippet surrounded by an >> #ifdef CONFIG_BOOTBINFUNC construct. >> >> It appears that this second implementation was later removed in commit >> 80767a6c, but the #ifdef CONFIG_AT91RM9200 logic was not removed also. >> >> Is RAM relocation only intended to function on at91rm9200 boards, or >> shall I submit a patch fixing the above? >> >> - -Cory > > Does this mean that the AT91RM9200 always relocates? > Then the code is simply wrong. No, there's an additional #ifndef CONFIG_SKIP_RELOCATE_UBOOT construct around the relocation code. The issue is that nothing /but/ AT91RM9200 /ever/ relocates the way it's currently coded. The relevant chunk (lines 181-201) from cpu/arm920t/start.S: #ifdef CONFIG_AT91RM9200 #ifndef CONFIG_SKIP_RELOCATE_UBOOT relocate: /* relocate U-Boot to RAM */ adr r0, _start /* r0 <- current position of code */ ldr r1, _TEXT_BASE /* test if we run from flash or RAM */ cmp r0, r1 /* don't reloc during debug */ beq stack_setup ldr r2, _armboot_start ldr r3, _bss_start sub r2, r3, r2 /* r2 <- size of armboot */ add r2, r0, r2 /* r2 <- source end address */ copy_loop: ldmia r0!, {r3-r10} /* copy from source address [r0] */ stmia r1!, {r3-r10} /* copy to target address [r1] */ cmp r0, r2 /* until source end addreee [r2] */ ble copy_loop #endif /* CONFIG_SKIP_RELOCATE_UBOOT */ #endif > If you run from a serial flash, then the code is already relocated > and is executing from SDRAM at this point, so the code will crash. Yes. This should be handled by CONFIG_SKIP_RELOCATE_UBOOT in the board's configuration, shouldn't it? - -Cory - -- Cory T. Tusar Embedded Systems Engineer Videon Central, Inc. 2171 Sandy Drive State College, PA 16803 (814) 235-1111 x316 (814) 235-1118 fax "There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies." --Sir Charles Anthony Richard Hoare -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFH0ZEyHT1tsfGwHJ8RAg4jAJ9wF95+3lyL2o0szFVJOjDDm57TlgCgmI1D hM9rLWmlYeguSzKmaEJ88jI= =6+iX -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2008-03-07 19:02 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-03-06 21:05 [U-Boot-Users] arm920t RAM relocation broken? Cory T. Tusar 2008-03-07 0:03 ` Ulf Samuelsson 2008-03-07 19:02 ` Cory T. Tusar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox