Rockbox Development > New Ports
Rockbox Player - Project to design and build a Free/Open hardware audio player
casainho:
--- Quote from: spark on May 10, 2008, 05:10:22 PM ---Try to generate a Mapfile by adding "-Map flash_led.map" to LDFLAGS.
this should give you some hints in the generated mapfile.
--- End quote ---
Hmmm... I did and I have now information on generated file that I do not understand ;-) :-) -- I will read more about that subject. I already read in recent past but I don't really understand... Atmel have an application note with title "at91sam9260_getting_started_1.0" where they explain the flash_LED code (where I copy that code) and they also explain the linker stage...
MAP file here: http://code.google.com/p/rockboxplayer/source/browse/trunk/flash_LED/flash_led.map?r=10
--- Quote from: spark on May 10, 2008, 05:10:22 PM ---basically, all segments of data and code must be at the correct location in memory as it is expected by the program (i.e. as per the map file). If you load your program at the wrong address then it will not work.
--- End quote ---
I have a big problem here, I don't know the right address to load the code on U-Boot and I don't know the right value to pass on linker script!! Since I understand, to load stand alone applications on U-Boot I do "tftp address file" being the address a RAM place where the file code will be loaded and U-Boot executes that code directly on RAM - I am linking with arguments "LDFLAGS=-Bstatic -Ttext 0x20000000" - In the manual of the dev. board I have a memory map that says the 64MB RAM starts at 0x20000000 and ends on 0x23FFFFFF - and using value 0x20000000 on "tftp 0x20000000 flash_LED.bin" system hangs, I do not have the code loaded in the memory... I tried doing "tftp 0x2000 flash_LED.bin" and It loads ok to the memory but do not flash the led and even returns to the U-Boot shell which shouldn't happen because of the while(1) cycle.
People at U-Boot mailing lists gave me one example of how to compile, link and load a stand alone application... I did follow that examples but I got system hang, maybe because of wrong adress... - here the example of a stand alone application:
http://code.google.com/p/rockboxplayer/wiki/Flash_LED
--- Quote from: Domonoky on May 11, 2008, 06:27:58 AM ---I would try a simpler test-program first, to see if your uploaded code really works. At the moment your blink-led code has many places where it could fail.. Maybe first try to only switch a LED on, then you dont need timers and such, which means less potential errors.
--- End quote ---
Good idea!! :-) -- yes, and I understand now that I can visually understand if code is working by looking at brightness of the LED, If I insert "dummy" code between ON and OFF instructions, I will can vary the duty-cycle and I will see that varying the brightness of the LED -- very easy since I did already configure the PIO controller and turn OFF and ON the LED :-)
New code here: http://code.google.com/p/rockboxplayer/source/browse/trunk/flash_LED/flash_led.c?r=10
spark:
mapfile says
.text @ 0xc100000
and
.stack @ 0x8000
since application is standalone, you have to make sure stack is initialized by your program. 0x8000 seems doubtful here.
You said that RAM is 0x20000000, so probably even .text is wrongly located.
start with the simplest possible program. no function calls, just switch the LED on at the entry point of the C program. Then you can go to more complex stuff like initializing stack, using functions, timers, etc.
casainho:
--- Quote from: spark on May 11, 2008, 08:10:52 AM ---mapfile says
.text @ 0xc100000
and
.stack @ 0x8000
since application is standalone, you have to make sure stack is initialized by your program. 0x8000 seems doubtful here.
You said that RAM is 0x20000000, so probably even .text is wrongly located.
start with the simplest possible program. no function calls, just switch the LED on at the entry point of the C program. Then you can go to more complex stuff like initializing stack, using functions, timers, etc.
--- End quote ---
I will wait for help from U-Boot mailing list - also I must understand that linker information, .text and .data and stack, etc.
A few days ago I saw that Sparkfun started to sell his "MP3 Development Board" for $199.95 . I quickly saw the schematic and I was unhappy to see that board misses SDRAM :-( -- It's a ARM7, VS1002 - MP3 audio codec, 128x128 colour LCD, microSD, FM Transmitter, Lithium Polymer battery and accelerometer. If It have 4 or 8MB of SDRAM I think Rockbox would work very nice on that hardware and that could be a start for a good hardware for Rockbox Player, even If it uses just an ARM7 at 60 MHz.
They use instead a MP3 audio codec in spite of doing decoding in software...
http://www.sparkfun.com/commerce/product_info.php?products_id=8603
Also interesting is what Bagder wrote on his blog: My phone does not replace my Rockbox -- http://daniel.haxx.se/blog/2008/05/08/my-phone-does-not-replace-my-rockbox/
I also think that mass use of standalone MP3 players will be quickly reduced to zero because of mobile phones/computers, specially after Android initiative. So I keep thinking why this efforts to Rockbox Player should going on... and I think we are in the right direction with Rockbox Player V1, trying not compete with that mobile multimedia players and instead make a good quality dedicated hardware for playing and recording audio.
casainho:
--- Quote from: friendlyzookeeper on May 11, 2008, 04:24:30 PM ---In the old days we would use a hex editor to find memory location of an executed application, if that helps.
--- End quote ---
I did plan to do disassembly of the code to see where is jumps etc... but is now working ;-) :-)
I have the flash_LED code working, but not with timers, just a loop turning ON and OFF the green LED. The code using timers returns to U-Boot shell which shouldn't!!
Code that is working: http://code.google.com/p/rockboxplayer/source/browse/flash_led-0.c
And what is not working: http://code.google.com/p/rockboxplayer/source/browse/flash_led-1.c
I got a few answers from guys at U-Boot mailing list which help me, like "Try using some offset - say 256 kB or so; that should be sufficient in any case - i. e. try 0x20040000 as download address." When I was using 0x20000000 I was probably overwriting the exception vectors(??).
EDIT: Doing a disassembly I saw that the code with timers have a different entry point to the _start(), I did a "go new_address" and worked nice, except the if() inside the while(1)... and I think the problem is with variable used in the if()... so I really must read more about link stage and understand it :-)
There is no need to use U-Boot (??)
I am being using U-Boot as suggested to download code by TFTP to SDRAM and run it. Until now, the advantages I see in using U-Boot is the quick way to download code and run it, using ethernet connection from the board to my PC.
The RockboxPlayerV1 will not have an Ethernet connection, instead USB will be the base connection between PC and the hardware. Even If for some chance there will Ethernet connection, RockboxPlayerV1 is much different from the dev. board so there will be the need to port U-Boot for It, which does look likes to me a wast of energies If U-Boot is just justified to download code by TFTP.
Since the USB is the main connection, we can use Sam-ba from Atmel to download code for SDRAM and Flash memory, using the USB connection. The Sam-ba program fro PC is available for Linux and MS Windows, although is not Free Software :( - but there is an Free Software version for Sam7 MCUs, maybe a version for Sam9 will happen -- http://oss.tekno.us/sam7utils/
So in resume, by USB we will be able to flash new versions of firmware, with a GUI program on PCs like RockboxUtility. Also we can use USB connection to quick load code to internal SDRAM and run it, for development purposes. As for low level development we must use OpenOCD in conjunction with GNU Debugger.
One drawback of USB in actual AT91SAM9261 is only the Full Speed. Maybe later versions of this MCUs will have High Speed.
Roger, what do you think about this?
In the next days I will concentrate on put Sam-ba working on my computer and dev. board. I have the application note from Atmel for the Flash LED code, with C code and instructions for using Sam-ba -- will be easy :-)
spark:
yes full-speed is bottleneck in 9261, that's why i've added High-Speed OTG controller in the block diagram
http://www.rockbox.org/twiki/bin/view/Main/RockboxPlayerV1#Block_Diagram
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version