Rockbox Player - Project to design and build a Free/Open hardware audio player

[mocad_tom]

Hi,

this is my first post here, but I read this discussion for quite some time.
I have a proposal for this project.
I think Rockbox is very interesting as a platform for mobile sensors.
I am in an ehealth-project where you monitor vitalparameters like heartbeat, body-core-temperature, blood-glucose and so on.
All this vitalparameters are no problem if you don't want to be mobile.
Form-factor, cpu-power, battery-runtime and the OS(rockbox) is really good if you compare it with other embedded "homegrown" systems.

The only thing which Rockbox-Player has to offer is an easy accessible SPI-port(in Hardware and in Software) where engineers can connect their A/D-Samplers or acceleration sensors with. I think that there is a big crowd of research and development people out there who are fighting against battery-runtime-,  file-system-, form-factor-troubles, to low CPU-clocks and not enough RAM. The portable mp3-players are very good optimised in this area.

I don't exactly know the licensing stuff Rockbox has - GPL AFAIK.

Here is my second not so popular proposal:
If the Rockbox-Hardware + -Software is in a LGPL it is possible to  develop closed-source-schematics-modules which connect directly to SPI-port.
It is possible to develop closed source software-modules and algorithms to analyse the captured parameters from the SPI-port.

And here comes the goody for the project:
The main-platform (the MP3-player-stuff - hardware and software ) is open source and it is mandatory to publicize the advances which a company has made in this area.
So if a company says the platform is very promising, it develops a SPI-Hardware-Module and a library to talk to the hardware - this is closed source. The next step is they want to sell this product so they have to make the Rockbox-Player smaller, they tweak for e.g. the USB driver-support and so on -> this tweaks have to be publicized (not the schematics for the SPI module).

And so both sides - the community and the company profits from this very cool platform.

What do you think of it?

Regards,
Tom

[Domonoky]

Hi,

About your second proposal:
I think it would surely possible to build a proprietary extension Modul for such a rockbox player as proposed here.
But a closed Source Software module is not possible without violating Rockboxs Licence (GPL).
The GPL forbids linking with non-opensource code. Remember that Rockboxs plugins link directly to rockbox code, unlike a normal PC program.

It could perhaps be possible with a LGPL middleman, but this a grey-area.

[casainho]

Christian from Pasen did answered yesterday to one my e-mail:
I'm sorry but our company has decided to invest on the mobile phone device,and at the moment we can't afford to develop two devices,we are out of budget.
If the phone goes well maybe we'll have a look at it again.

And the first message of Christian here, in this forum message:
Hi Guys,
my name is Christian and I came here while looking for some skilled engineer to work on google android. ...

I understand, phone mobile devices are attractive, they can also play MP3 - I see a lot of people using them to listen music with phones or even without phones. Who wants to buy an MP3/MP4 player if one can have it on their mobile phone?
---

I did updated the information about flash LED code: http://code.google.com/p/rockboxplayer/wiki/Flash_LED

I would like to know If I am doing good or If I am doing something wrong like not initialize the structures - I am really a newbie in C:
http://code.google.com/p/rockboxplayer/source/browse/trunk/%20rockboxplayer/flash_led.c

Thank you.

[mocad_tom]

Thank you for your comments.

I found a statement about this in the mail archive:
http://www.rockbox.org/mail/archive/rockbox-archive-2005-01/0285.shtml
I think that this is a quite clear statement pro GPL.

All compatible licenses are allowed as well.

This hint you mentioned -> a plugin in the middle which is LGPLed is a point to start with.

PluginPacbox plays in a quite similar area:
There is a hardware emulator which is GPLed but the ROM-files are not(AFAIK).

A thing which is mentioned the whole thread long is:
Who will buy the rockbox-player-boards?
I'm quite sure that there are a lot of mobile-embedded-developers who need a development basis where they can connect a developed SPI-Piggy-Pack. There should be room for a board which is stacked on top of the basic board.
The stacked approach could be realised similar to this:
http://particle.teco.edu/devices/upcoming_main.html

If this proposal is a no-go than it is okay for me.
But I think this will open up new possibilities for rockbox.
At the moment we are thinking about an abstract and a presentation for mocomed 2008 (mobile computing in medicine) and one possible area is to show the benefits an open-source-OS offers for mobile vital-parameter-sensors.

Applications like the frwd-sports-computer could be very easy to implement on top of a rock-box-device which has an expansion slot for a gps-piggy-pack:
http://www.frwd.fi/index.php?71

Regards,
Tom

Edit:
What is wrong with the bulletin board? Where is the post of casainho I intended to answer?


Just to answer the question of casainho:

Hi casainho,

I'm a smartphone software engineer(Windows-Mobile-native, .net compact Framework, Symbian-native, J2ME), so I'm not so deep into this stuff.
In our research and development project we are discussing at the moment about how much intelligence a mobile sensor has to offer.
The electrical-engineer-project-colleagues (who are working in another company) use TI MSP430 chips as a hardware basis.
They have a not so optimal software development cycle.
If I say this to them they throw stones at me      
In this area rockbox offers a very good approach (think of the VMware with a ready-to-use toolchain).
So much of the high level stuff can be implemented in VMware - this is a lot faster then developing the hole bunch of code on the MSP430.
So they don't use the possibilities a open-source-project could offer.

Back to the expansion-slots for mobile devices.
This project is quite different but I think it could help:
http://www.sunspot.co.uk/Projects/sweexproject.htm

I think there are similarities. You can buy a really low-cost-edimax-router and modify it. First of all you have to replace the firmware with a AFAIK openwrt linux (it is a branch which is called midge). On the board layout you can see the pins for the COM-Port.
Then there are drivers for the RS232-port and for I2C and GPIO and with this there is a lot of home automation stuff possible (sensors and actuators). The LEDs are connected to GPIO-cannels.

I hope that it is a little clearer now.

Regards,
Tom

[casainho]

DSPdap V2 was released on 1 May
I just saw today that V2 of DSPdap was resealed on 1 May :-) - thats a project made by Roger Quadros aka Spark.

News on V2: Li-ion battery support with built-in charger (USB); SD/MMC card support; Line-in recording and digitizing to SD card; SDRAM - more memory for more codecs and LCD; Small form factor (9cm x 5cm) --> http://dspdap.sourceforge.net/

DSPdap have all that Rockbox Player pretends to have, less the display and the MCU. The MCU is TMS320C55x 16-bit fixed-point DSP, which since I know, don't have a free software compiler as ARM MCUs have and maybe because of that DSPdap can't run Rockbox firmware :-(

I am very happy to see that now DSPdap sells in his site PCBs for $25, cheap price, IMO. Congratulations Roger!!

I am even more confident now that Rockbox Player will be available worldwide and in a modest price. If Roger can design and sell PCBs worldwide for that prices, great for the project!!
Roger being working on Rockbox Player means (my guess) that we will reuse the hardware, we just need to change the MCU for that ARM9 and add a display :-) - in fact, I am being changing some e-mails with Roger and we will use AT91SAM9261 MCU because of the TFT LCD support.

We must now find a LCD suitable for AT91SAM9261.

---
Tom, all that work supported on that strong based hardware router - but that base must be very good, cheap and available and after that hacks can happen.

I would like to have a stable, strong base hardware, good in audio quality and world available, after that, new versions, hacks/improvements will happen.

If I understand you correctly, some one already suggest a near idea:
http://forums.rockbox.org/index.php?topic=6751.msg112395#msg112395

[spark]

Thanks Casainho,
Yes definitely we can reuse some sections of dspdap-v2 http://dspdap.sourceforge.net for Rockboxplayer. I see that the power supply & charger section can be re-used almost as it is.
SDRAM, SD/MMC can be used as reference.

[casainho]

My development board is not working now... I tried to restore the default bootloader and kernel using SAM-BA Linux version, all went ok but it does not boot. I did put online the log file and the steps that I went:
http://code.google.com/p/rockboxplayer/wiki/RestoringTheDefaultBootloaderAndKernelOnSAM9L9260

I am thinking in try now the OpenOCD. I never used OpenOCD and I don't have a cable ready yet - but I will work on it

[casainho]

I'm sorry I can't help you, you did use windows 2000 or xp? I have a different decoder IC and display with controller. I put sound and video on a module.

I did use Linux. But I did restore the u-boot now using a computer with Windows and seeing the log file looks like the tentative to recover Linux should work - I do not use Windows on my computers so I must be able to know how to recover in Linux when needed.

Now my problem is to put a "Hello world" and the Flash_LED code to working, launched by u-boot. Yesterday I managed to have TFTP server on my pc and I did load with success bin files to the development board, on u-boot shell - finally I use the "go address" command to try run the "Hello world" and the Flash_LED but I got nothing :-( -- I will try to build a new "Hello world" from the u-boot source code and also I will ask for help on u-boot mailing list.


http://farm3.static.flickr.com/2374/2480364568_ac0ac8f98d_o.png

The code for flash_LED I wrote is here: http://code.google.com/p/rockboxplayer/source/browse

EDIT: I did turn ON and OFF the green LED on the development 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.

[spark]

Try to generate a Mapfile by adding "-Map flash_led.map" to LDFLAGS.
this should give you some hints in the generated mapfile.

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.

Make sure you look into the linker options in more detail.

This article should help
http://www.embedded.com/columns/technicalinsights/201000339?_requestid=450633

[Domonoky]

to friendlyzookeeper:
While it is nice that you want to help this project, it seem you often dont really read what others have written.  casainho wants to blink a LED on the Development Board. So he surely has the right resistors for the led, as the LED is already on the Dev-Board.

to casainho:
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.
 

[casainho]

Try to generate a Mapfile by adding "-Map flash_led.map" to LDFLAGS.
this should give you some hints in the generated mapfile.

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

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.

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

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.

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]

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.

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]

In the old days we would use a hex editor to find memory location of an executed application, if that helps.

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