Rockbox Development > New Ports
Rockbox Player - Project to design and build a Free/Open hardware audio player
casainho:
--- Quote from: Llorean on March 11, 2009, 02:48:44 PM ---(...) As it is, we could be asking YOU to communicate more here about your software development work (patches on the tracker, and such). At the moment you've basically forked Rockbox and are working on it in your own space, rather than attempting to bring your software work back to the core project (we could probably have much of your in-progress code in SVN as long as you've been trying to follow the Rockbox coding styles, etc). (...)
--- End quote ---
Llorean, I think you were talking with Alex Cantos, however I can explain this part. I am the only one working on porting the firmware and as that, I don't have time nor knowledge to make patches. Well, I just learned recently to make patches and all this technologies were new to me at begin of the project.
I am trying to make patches and am I sharing them here, like the last one: 0001-20090310-rockbox_player-r19939.patch. Before, other Rockbox developers suggest me the same and even help doing the first patches.
And I put a patch one Rockbox tracker, however, I prefer now to focus on development and in the end (that is very near) I want to work on the patch for apply it again to the tracker.
We are few developers and we have very limited time and knowledge(as me). We have being getting a lot of help on Rockbox IRC channel and others Open Source projects (for schematics, code drivers, tutorials, etc) :-)
bluebrother:
--- Quote from: casainho on March 11, 2009, 06:16:31 PM ---And I put a patch one Rockbox tracker, however, I prefer now to focus on development and in the end (that is very near) I want to work on the patch for apply it again to the tracker.
--- End quote ---
A single big patch that adds a complete new target is something that is almost impossible to review. Prepare to get asked breaking that monster-patch down into smaller pieces.
The (somewhat) original is to have multiple smaller changes that even might be possible to get applied now. Which would mean less work for you (no need to maintain that piece against svn) and easier review of your patches, thus better chances to get it into svn soon. Of course, that would require to follow the Rockbox coding guidelines ...
casainho:
--- Quote from: bluebrother on March 11, 2009, 06:37:50 PM ---
--- Quote from: casainho on March 11, 2009, 06:16:31 PM ---And I put a patch one Rockbox tracker, however, I prefer now to focus on development and in the end (that is very near) I want to work on the patch for apply it again to the tracker.
--- End quote ---
A single big patch that adds a complete new target is something that is almost impossible to review. Prepare to get asked breaking that monster-patch down into smaller pieces.
The (somewhat) original is to have multiple smaller changes that even might be possible to get applied now. Which would mean less work for you (no need to maintain that piece against svn) and easier review of your patches, thus better chances to get it into svn soon. Of course, that would require to follow the Rockbox coding guidelines ...
--- End quote ---
So I will start working on it. Thanks ;-)
I have question, bluebrother wrote on tracker, respective to the patch:
I still find this structure for registers weird and broken. IMO registers shouldn't get accessed through a structure pointer but directly as done in the rest of Rockbox (unless I was missing something here).
Can registers get accessed through a structure pointer on our patch? Because we have a header file that have all registers like that, and it works. Can we use that file or will we really need to re-write it?
For a first simple patch I was thinking in starting on the bootloader and initialize Rockbox kernel, and with that kernel flash a LED on the dev. board. What do you guys think? Would this be a good and simple patch for start?
bluebrother:
--- Quote from: casainho on March 12, 2009, 09:14:16 AM ---Can registers get accessed through a structure pointer on our patch? Because we have a header file that have all registers like that, and it works. Can we use that file or will we really need to re-write it?
--- End quote ---
Simply put: it's not the way it's done in the rest of Rockbox. Having two completely different ways sounds like a bad idea to me. Also, I haven't seen this way of doing it much -- the usual way is by using register defines.
As an example, do you access registers like register->PORTA on AVRs? No. So why should you do on the SAM? 'Besides, how do you suppose will this work if register addresses aren't consecutive?
"We already have a header file" is not a reason, it's an excuse at best. IMO.
casainho:
--- Quote from: bluebrother on March 12, 2009, 01:47:18 PM ---
--- Quote from: casainho on March 12, 2009, 09:14:16 AM ---Can registers get accessed through a structure pointer on our patch? Because we have a header file that have all registers like that, and it works. Can we use that file or will we really need to re-write it?
--- End quote ---
Simply put: it's not the way it's done in the rest of Rockbox. Having two completely different ways sounds like a bad idea to me. Also, I haven't seen this way of doing it much -- the usual way is by using register defines.
As an example, do you access registers like register->PORTA on AVRs? No. So why should you do on the SAM? 'Besides, how do you suppose will this work if register addresses aren't consecutive?
"We already have a header file" is not a reason, it's an excuse at best. IMO.
--- End quote ---
Bluebrother, I asked on IRC, you weren't there but Bagder help me and told that we should not use that way of structs.
We will make that patch with just kernel_init(), with that "good" scheme for defines of registers and with new name of the project.
--- Quote from: bluebrother on March 12, 2009, 01:47:18 PM ---"We already have a header file" is not a reason, it's an excuse at best. IMO.
--- End quote ---
Not, it is the reason, and I bet that is the same reason many people use it, because that header files cames on Atmel AT91 Lib.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version