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

[casainho]

friendlyzookeeper, you are writing things that are not important for this project! Can you please create another post to discuss that things and write here just about the hardware and software for the RockboxPlayer??
http://www.rockbox.org/twiki/bin/view/Main/RockboxPlayer

arm-linux-gcc or arm-elf?
I did build u-boot and the example code "hello world" in u-boots source and I had to install the arm-linux-gcc, the arm-elf didn't build the example, It must be the arm-linux-gcc. I would like to know If to build rockbox firmware I must use arm-elf or If arm-linux-gcc is ok? Any suggestions, guidance? - I did read the CrossCompiler TWiki page of rockbox. Thank you.

[casainho]

Casainho, I really don't know what your asking? Did you create  "hello world" and still hooked up to your computer? The example hello world is just an application. The CD that you received with your board has a pre- built Linux version to port to memory of your board. The instructions on how to port it will be on the cd. You do have a choice on which version os. There will be 3 versions of linux and a windows ce. The windows ce is just an evaluation os. There are a few firmware ports also, Busybox is a very good one.
 I hope that I helped, somewhat?

The "hello world" example is in the sources of the u-boot bootloader, not in the sources of the Linux that comes with the board. Also I see in the documentation of u-boot that "hello world" example.

I don't care about Linux that comes with the dev. board because we will not use Linux nor any other OS. But It's important to have Linux sources and bins for the board because when writing drivers for Rockbox firmware we can reuse the code :-)

I tried to build the u-boot with arm-elf installed on my system by the rockboxdev.sh install script but the build fails right on the "hello world" source and I had to build using arm-linux-gcc...

[casainho]

Are you going to use the linux kernel for the drivers?

I don't know yet. I will use what I will need to use and It's good to have u-boot and linux sources for the hardware that I am working, because they use the same license as Rockbox firmware :-)

[casainho]

So, your going to load scripts and commands?

Since what I know, I will load bin files on u-boot.

[Llorean]

friendlyzookeeper: I must repeat in the strongest terms that you should stop and look at what Rockbox is. It really sounds like you're trying to offer advice here without having much knowledge as to the actual goal, or the software he wants to get running on the device.

[Llorean]

Rockbox is not a GUI. Rockbox is an entire OS (firmware), from the ground up, including its own low level code and drivers. It is not based on Linux, and is not merely an application.

As I've said several times throughout this thread, you really need to familiarize yourself with the project first.

It's possible I'm misunderstanding you, but your posts frequently read like you think he will be loading embedded linux or some other OS on this, then "running" Rockbox on top of it, but Rockbox is the OS itself that the device will be running.

[Llorean]

Rockbox is in two layers. The application (GUI) and the firmware (OS). On most of the players, the bootloader is a minimized build of Rockbox itself, to handle hardware initialization and loading of the main Rockbox binary into RAM. When you are using Rockbox on a player, Rockbox is the full OS. It contains low level drivers for hardware. But it is one piece of software. It is not just a GUI.

It's written from scratch. It is not "similar" to anything. Rockbox IS the operating system kernel.

[casainho]

friendlyzookeeper: I must repeat in the strongest terms that you should stop and look at what Rockbox is. It really sounds like you're trying to offer advice here without having much knowledge as to the actual goal, or the software he wants to get running on the device.

I can't look over casainho shoulders to see what his ideas are, at this time. Its hard to interact without imaging what has been done and the objective.

You can't complain about that, the objectives of the project and even of the Prototype version are written in the TWiki pages!! Also what is already defined are what is written.

As I said to you a few times in the past messages, read more here: http://www.rockbox.org/twiki/bin/view/Main/RockboxPlayer

[Llorean]

Rockbox is ported to new hardware. You write drivers for it. You can use much of the information from the Linux drivers to do this, but you ARE trying to create a new version of Rockbox to it. We've done this many times, with VERY different hardware. Believe me, it works, and just fine if you have hardware information.

[casainho]

You are misunderstanding me. Rockbox is a combination of many things, not only a gui. I can't create Rockbox from scratch.

Sorry If I misunderstand you. It's nice that now you say something directly which we can discuss.

The references I looked at was the source code, the board isn't like any of the players that Rockbox  is ported to. Each of the devices on the board may be similar to others, but they're not the same. Trying to hack a version of Rockbox onto the board is out of the question, and that is what it looks like you are trying to do (or want to do)?

1st: the MCU is an ARM9, was said by old developers to be a good, the smart choice of MCU. About code, It's written on wiki:  "AT91SAM9260 --> ARM926EJ-S -- Texas DM320[ http://www.rockbox.org/twiki/bin/view/Main/TexasInstrumentsTMS320#DM320 ] uses an ARM926EJ core and there is OlympusMR500Info [ http://www.rockbox.org/twiki/bin/view/Main/OlympusMR500Info ] port that have drivers already made for this ARM core -> code can be re-used :-)"

2nd:  the Stereo Audio CODEC TLV320AIC23 have drivers already in RockBox - tlv320.c [ http://svn.rockbox.org/viewvc.cgi/trunk/firmware/drivers/audio/tlv320.c?revision=&view=markup ] - and is used in various Free/Open source hardware digital audio players; --- as written on wiki page.

Others developers that read the project didn't had that same opinion as you - I may be novice but I believe in possibilty and I am working on that since December.

[saratoga]

Trying to hack a version of Rockbox onto the board is out of the question,

No.

and that is what it looks like you are trying to do (or want to do)? I could be wrong and I hope that I am. I'm not offering advice, just questioning the procedures. Questions is a form of knowledge intake.

Its really, really annoying when people try to learn by thoughtlessly guessing every possible permutation and expecting other to correct them.  I'm going to ask you now to stop doing this now.

[casainho]

OK!! Now, the core is ARM926EJ-S, atmel and texas instruments licensed it from arm. Do they both have the exact same mcu or did they conform to their needs? They are both different companies in to sell software for their products and have debuggers to sell as well. It may cause a problem.

No problem because there is Free Software tools to build the software, as debuggers -- the ARM-GCC :-) -- as the tools being used for Rockbox Firmware, since late 2001 :-)

OK, I'm going to stop,since I'm not a developer and have no business in this forum. Thanks to all that helped, its been gratifying. Hope you all the success that well worthing.   

Would be nice If you just post just few messages with direct questions to what is already defined on wiki pages and new suggestions. Stay tunned :-)

[spark]

I would like to put up these questions to senior Rockbox Developers.

• Why do you think we should develop a Rockbox hardware player?

• If ever, such a player is built as per our requirements, how many developers are eager to buy prototype versions  to assist in porting ? (Please mention affordable prototype cost)

• When the player enters production phase, who is going to buy this player and why? (Please mention favorable production piece cost)

Thanks.

[Llorean]

Hmm... I'm not sure I quite understand the first question. Shouldn't it be something more like the developers asking "What about this player you're designing is so interesting as to make some of us help you with adding Rockbox support for it?" I'm not trying to sound offensive, mind you. But the Rockbox developers have dozens if not hundreds of potential targets, and did not go out asking people to make custom hardware. While there's a benefit to a truly "open" player, asking the developers "Why should we build hardware for you?" is silly. If you don't want to, don't, they didn't ask you to.

Second question: What does the phrase "as per our requirements" mean? There's really no way to predict how many developers will buy a prototype, but I would hazard it depends on exactly what the prototype does (and how much it will differ from the final). Like ANY port, you shouldn't depend on existing developers becoming interested. Count it as a nice bonus if they do but expect, in advance, to be doing the majority, if not all, of the work.

Third question: Again, I'm not sure why the developers are expected to know this. It sounds, to me at least, like you expect them to be involved somehow in the selling of your player?

Again, I'm not trying to sound argumentative. Just seeking some clarification on what, exactly, you mean with your questions and why you're asking each one.

[spark]

First of all let me clarify
we = our = interested people

1) i did not say "why should we develop for you". I said "why should we develop for us". you are treating me as if i want to develop it for you. sorry, i don't want to do that.

2) "as per our requirements" means whatever is long discussed in this forum and mentioned in the wiki. It is a mutually agreed list of requirements and nothing specific to a single person.

3) selling of my player? if it was my player i would not be posting here or asking you to sell it for me. i  already have my own player at http://dspdap.sourceforge.net.

Let me put it this way. "Why make an open hardware player to run Rockbox, when there are players available for less than $100 that can run Rockbox?"