* [U-Boot-Users] help in understand the address of standalone applications, ARM MCU
@ 2008-05-11 16:36 J.P. Casainho
2008-05-11 18:31 ` Wolfgang Denk
0 siblings, 1 reply; 8+ messages in thread
From: J.P. Casainho @ 2008-05-11 16:36 UTC (permalink / raw)
To: u-boot
Hello :-)
I would like to create a standalone application and I already read manual and
also asked help here and got one good example however I can't get It working
and I think the problem is in the address.
I am using an Olimex dev. board with a ARM9, AT91SAM9260 MCU. On my makefile I
am linking with address 0xc100000, "LDFLAGS=-Bstatic -Ttext 0xc100000" -- is
this address correct? How can I have sure of that? -- I got this value from
makefile of "hello world" example.
When I do "tftp 0xc100000 flash_led.bin" the system hangs.. while If I try to
do for example "tftp 0x1000 flash_led.bin" the code loads ok but after "go
0x1000", the code does not work... It evens return while shouldn't because of
an infinite loop on the code.
In the manual of the dev. board I have a memory map that says the 64MB RAM
starts at 0x20000000 and ends on 0x23FFFFFF - If I do "tftp 0x20000000
flash_LED.bin" system also hangs...
Can someone help me?
My flash_LED code is here:
http://code.google.com/p/rockboxplayer/source/browse/trunk/flash_LED
And the help, example, I got before here in the mailing list:
http://code.google.com/p/rockboxplayer/wiki/Flash_LED
I must say that with my dev. board comes an "hello world" example which is an
empty function :-( -- but even I don't know to what address I should load it.
I did turn ON and OFF the LED on the dev. board using U-Boot shell, using the
memory write and memory display commands ;-) -- I did write configure values
to the PIO controller, enabling the PA6 pin as output and set and clear that
pin to turn OFF and ON the green LED.
I am working on a Free/Open hardware digital audio player and recorder:
http://www.rockbox.org/twiki/bin/view/Main/RockboxPlayer
Thanks in advance,
JPCasainho - http://www.Casainho.net
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot-Users] help in understand the address of standalone applications, ARM MCU
2008-05-11 16:36 [U-Boot-Users] help in understand the address of standalone applications, ARM MCU J.P. Casainho
@ 2008-05-11 18:31 ` Wolfgang Denk
2008-05-11 19:51 ` J.P. Casainho
2008-05-11 20:40 ` [U-Boot-Users] help in understand the address of standaloneapplications, " Ulf Samuelsson
0 siblings, 2 replies; 8+ messages in thread
From: Wolfgang Denk @ 2008-05-11 18:31 UTC (permalink / raw)
To: u-boot
In message <200805111736.50691.casainho@gmail.com> you wrote:
>
> I am using an Olimex dev. board with a ARM9, AT91SAM9260 MCU. On my makefile I
Is this board supported in the public U-Boot git tree?
> am linking with address 0xc100000, "LDFLAGS=-Bstatic -Ttext 0xc100000" -- is
What makes you think we would know the memory map of your board better
than you?
> this address correct? How can I have sure of that? -- I got this value from
> makefile of "hello world" example.
As the first step you have to understand the memory map of your
system. We cannot know this.
> When I do "tftp 0xc100000 flash_led.bin" the system hangs.. while If I try to
Then the address is obviously wrong - seems there is no RAM there.
> do for example "tftp 0x1000 flash_led.bin" the code loads ok but after "go
Are you sur the code is really stored to this address? I seriously
doubt that. 0x1000 is probably an address in flash memory on your
system, and you do not program the flash (normally) when running a
"tftp" command.
> 0x1000", the code does not work... It evens return while shouldn't because of
> an infinite loop on the code.
You are probably executing random code that happens to be at that
location in flash.
> In the manual of the dev. board I have a memory map that says the 64MB RAM
> starts at 0x20000000 and ends on 0x23FFFFFF - If I do "tftp 0x20000000
Ah, see! So what makes you think 0xc100000 could work?
> flash_LED.bin" system also hangs...
Probably because you are overwriting the exception vectors?
> I must say that with my dev. board comes an "hello world" example which is an
> empty function :-( -- but even I don't know to what address I should load it.
Ask the company who provided that port of U-Boot and the example
program?
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 at denx.de
It is practically impossible to teach good programming style to stu-
dents that have had prior exposure to BASIC: as potential programmers
they are mentally mutilated beyond hope of regeneration. - Dijkstra
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot-Users] help in understand the address of standalone applications, ARM MCU
2008-05-11 18:31 ` Wolfgang Denk
@ 2008-05-11 19:51 ` J.P. Casainho
2008-05-11 20:22 ` Alessandro Rubini
2008-05-11 20:36 ` Wolfgang Denk
2008-05-11 20:40 ` [U-Boot-Users] help in understand the address of standaloneapplications, " Ulf Samuelsson
1 sibling, 2 replies; 8+ messages in thread
From: J.P. Casainho @ 2008-05-11 19:51 UTC (permalink / raw)
To: u-boot
Hello :-)
On Sunday 11 May 2008 19:31:05 you wrote:
> In message <200805111736.50691.casainho@gmail.com> you wrote:
> > I am using an Olimex dev. board with a ARM9, AT91SAM9260 MCU. On my
> > makefile I
>
> Is this board supported in the public U-Boot git tree?
No I think, It come with sources on CDROM, however this board looks like
identical of the board/atmel/at91sam9260ek/.
http://git.denx.de/?p=u-boot.git;a=tree;f=board/atmel/at91sam9260ek;h=9872dae12d7fd41dfbdd82e5ea2ad900cc47c044;hb=f3612a7b199cab3942f60d9c1392eb39d58cc699
The board is the Olimex SAM9-L9260, manual:
http://www.olimex.com/dev/pdf/ARM/ATMEL/SAM9-L9260.pdf
> > am linking with address 0xc100000, "LDFLAGS=-Bstatic -Ttext 0xc100000" --
> > is
>
> What makes you think we would know the memory map of your board better
> than you?
Hmmm... I am a novice :-) - my first time with 32 bits and U-Boot :-) - I
tought that in some way memory map on U-Boot would be the same for every
boards, dependant only on the MCU.
> > this address correct? How can I have sure of that? -- I got this value
> > from makefile of "hello world" example.
>
> As the first step you have to ?understand ?the ?memory ?map ?of ?your
> system. We cannot know this.
So them I assume the information on manual are what I am looking for. Is there
any way to know that looking at sources of U-Boot?
> > When I do "tftp 0xc100000 flash_led.bin" the system hangs.. while If I
> > try to
>
> Then the address is obviously wrong - seems there is no RAM there.
>
> > do for example "tftp 0x1000 flash_led.bin" the code loads ok but after
> > "go
>
> Are you sur the code is really stored to this ?address? ?I ?seriously
> doubt ?that. ?0x1000 ?is ?probably an address in flash memory on your
> system, and you do not program the flash (normally) ?when ?running ?a
> "tftp" command.
>
> > 0x1000", the code does not work... It evens return while shouldn't
> > because of an infinite loop on the code.
>
> You are probably executing random code that happens to be at that
> location in flash.
>
> > In the manual of the dev. board I have a memory map that says the 64MB
> > RAM starts at 0x20000000 and ends on 0x23FFFFFF - If I do "tftp
> > 0x20000000
>
> Ah, see! So what makes you think 0xc100000 could work?
>
> > flash_LED.bin" system also hangs...
>
> Probably because you are overwriting the exception vectors?
Hmm... So I must know detailed memory map, and that depends on U-Boot usage,
right? - the board manual just tells the principle and the end addresses of
the SDRAM... - maybe the information I am looking for is in the sources of
U-Boot...
> > I must say that with my dev. board comes an "hello world" example which
> > is an empty function :-( -- but even I don't know to what address I
> > should load it.
>
> Ask the company who provided that port of U-Boot and the example
> program?
>
> Best regards,
>
> Wolfgang Denk
Can you guide me? -- If I find the right address and use it on the -Ttext link
time and on the tftp load and go command, my original program should work? is
just that "simple" to have a externall application?
Thank you.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot-Users] help in understand the address of standalone applications, ARM MCU
2008-05-11 19:51 ` J.P. Casainho
@ 2008-05-11 20:22 ` Alessandro Rubini
2008-05-11 20:36 ` Wolfgang Denk
1 sibling, 0 replies; 8+ messages in thread
From: Alessandro Rubini @ 2008-05-11 20:22 UTC (permalink / raw)
To: u-boot
> Hmm... So I must know detailed memory map, and that depends on U-Boot usage,
> right? - the board manual just tells the principle and the end addresses of
> the SDRAM... - maybe the information I am looking for is in the sources of
> U-Boot...
Most likely u-boot is running at 0x23f0.0000. Usually the initial
bytes are used for special purposes (I don't remember the details but
irq vectors might be located there), so anything in-between should
work. Try 0x2010.0000 (1M within the RAM area) or whatever.
In short: yes, it depends on the detailed memory map.
A good choice, if you don't want to know the details, is the address
where you load the kernel image (it's on the manual, or default boot
command). Note: not the flash address, but the load address in the
range 2000.0000-2400.0000; it usually is 32k in the ram, but whatever
it is, that is a safe address. 0 and 0xc000.0000 are definitely not good.
> If I find the right address and use it on the -Ttext link time and
> on the tftp load and go command, my original program should work?
Yes.
Hope this helps
/alessandro
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot-Users] help in understand the address of standalone applications, ARM MCU
2008-05-11 19:51 ` J.P. Casainho
2008-05-11 20:22 ` Alessandro Rubini
@ 2008-05-11 20:36 ` Wolfgang Denk
1 sibling, 0 replies; 8+ messages in thread
From: Wolfgang Denk @ 2008-05-11 20:36 UTC (permalink / raw)
To: u-boot
In message <200805112051.43401.casainho@gmail.com> you wrote:
>
> > Is this board supported in the public U-Boot git tree?
>
> No I think, It come with sources on CDROM, however this board looks like
Well, probably you should direct your questions to Olimex technical
support, then.
> Hmmm... I am a novice :-) - my first time with 32 bits and U-Boot :-) - I
> tought that in some way memory map on U-Boot would be the same for every
> boards, dependant only on the MCU.
No. The memory map is something that is board specific. Actyally you
define it when you port U-Boot to a specific board.
> So them I assume the information on manual are what I am looking for. Is there
> any way to know that looking at sources of U-Boot?
Sure. Most of these definitions are in the board config file,
include/configs/<board>.h
> > > In the manual of the dev. board I have a memory map that says the 64MB
> > > RAM starts at 0x20000000 and ends on 0x23FFFFFF - If I do "tftp
> > > 0x20000000
...
> > Probably because you are overwriting the exception vectors?
>
> Hmm... So I must know detailed memory map, and that depends on U-Boot usage,
Not on usage, but on the configuration chosen by whoever ported U-Boot
to that board.
Try using some offset - say 256 kB or so; that should be sufficient in
any case - i. e. try 0x20040000 as download address.
> Can you guide me? -- If I find the right address and use it on the -Ttext link
> time and on the tftp load and go command, my original program should work? is
> just that "simple" to have a externall application?
I really think you should ask the vendor who provides the code. Only
when they get a sufficient load of support calls they will learn that
it's better to push their changes back upstream.
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 at denx.de
The flow chart is a most thoroughly oversold piece of program docu-
mentation. -- Frederick Brooks, "The Mythical Man Month"
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot-Users] help in understand the address of standaloneapplications, ARM MCU
2008-05-11 18:31 ` Wolfgang Denk
2008-05-11 19:51 ` J.P. Casainho
@ 2008-05-11 20:40 ` Ulf Samuelsson
2008-05-12 0:01 ` J.P. Casainho
1 sibling, 1 reply; 8+ messages in thread
From: Ulf Samuelsson @ 2008-05-11 20:40 UTC (permalink / raw)
To: u-boot
> In message <200805111736.50691.casainho@gmail.com> you wrote:
>>
>> I am using an Olimex dev. board with a ARM9, AT91SAM9260 MCU. On my makefile I
>
> Is this board supported in the public U-Boot git tree?
>
>> am linking with address 0xc100000, "LDFLAGS=-Bstatic -Ttext 0xc100000" -- is
>
> What makes you think we would know the memory map of your board better
> than you?
>
>> this address correct? How can I have sure of that? -- I got this value from
>> makefile of "hello world" example.
By looking at the datasheet of the part in questions!
The AT91SAM9260 has fixed decoding of chip selects.
If you want to put your code in SDRAM, you need to put
is somewhere from [0x20000000 .. 0x20000000 + SDRAM_SIZE ]
U-Boot is typically located at [0x20000000 + SDRAM_SIZE - 0x100000]
>
> As the first step you have to understand the memory map of your
> system. We cannot know this.
>
>> When I do "tftp 0xc100000 flash_led.bin" the system hangs.. while If I try to
>
> Then the address is obviously wrong - seems there is no RAM there.
>
>> do for example "tftp 0x1000 flash_led.bin" the code loads ok but after "go
>
> Are you sur the code is really stored to this address? I seriously
> doubt that. 0x1000 is probably an address in flash memory on your
> system, and you do not program the flash (normally) when running a
> "tftp" command.
>
0x1000 looks like internal SRAM. This is VERY limited in size.
>> 0x1000", the code does not work... It evens return while shouldn't because of
>> an infinite loop on the code.
>
> You are probably executing random code that happens to be at that
> location in flash.
>
>> In the manual of the dev. board I have a memory map that says the 64MB RAM
>> starts at 0x20000000 and ends on 0x23FFFFFF - If I do "tftp 0x20000000
>
> Ah, see! So what makes you think 0xc100000 could work?
>
>> flash_LED.bin" system also hangs...
>
> Probably because you are overwriting the exception vectors?
>
>> I must say that with my dev. board comes an "hello world" example which is an
>> empty function :-( -- but even I don't know to what address I should load it.
>
> Ask the company who provided that port of U-Boot and the example
> program?
>
Best Regards
Ulf Samuelsson
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot-Users] help in understand the address of standaloneapplications, ARM MCU
@ 2008-05-12 8:50 J.P. Casainho
0 siblings, 0 replies; 8+ messages in thread
From: J.P. Casainho @ 2008-05-12 8:50 UTC (permalink / raw)
To: u-boot
"I tried a more complex code that uses a periodic interval timer to do a delay
on flash LED code however this code does not work, It comes back to U-Boot
shell with return value of 1. What can I be doing wrong?" -- to answer my own
questions, the page
http://www.denx.de/wiki/view/DULG/MyStandaloneProgramDoesNotWork did help
because I was not going to the right entry point :-)
Thank you all :-) :-)
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2008-05-12 8:50 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-05-11 16:36 [U-Boot-Users] help in understand the address of standalone applications, ARM MCU J.P. Casainho
2008-05-11 18:31 ` Wolfgang Denk
2008-05-11 19:51 ` J.P. Casainho
2008-05-11 20:22 ` Alessandro Rubini
2008-05-11 20:36 ` Wolfgang Denk
2008-05-11 20:40 ` [U-Boot-Users] help in understand the address of standaloneapplications, " Ulf Samuelsson
2008-05-12 0:01 ` J.P. Casainho
-- strict thread matches above, loose matches on Subject: below --
2008-05-12 8:50 J.P. Casainho
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox