Great work! In my opinion you should simply commit (and improve our recent commit statistics) :-)
2013/6/12 Amaury Pouly <amaury.po...@gmail.com> > Hello everybody, > I felt I should disclose some information about the imx233 target and the > roadmap that I have been pursuing in the last months. I'll try to start > from scratch and give you an overview of what I'm doing and why. > > For those for don't know about it, the imx233 is a port to the Sigmatel > STMP3780 (aka Freescale i.MX233) SoC. It is used in at least three recent > devices: Creative Zen X-Fi2, Zen X-Fi3 and Sansa Fuze+. The port to the > Fuze+ is close to stable, same for the Zen X-Fi3 and the Zen X-Fi2 is > unstable but already has a solid basis. > > The world seemed beautiful and all but then someone came and told us he > had a device based on the STMP3700 SoC for which we didn't have the > datasheet but some Linux code. It was obvious from the start that this chip > was extremely close to the imx233 and that a Rockbox port was possible. At > this point, we realised that some other devices were using another > undocumented chip named STMP3770 and we even realised that the older and > documented STMP3600 family was also very close. Here is a list of devices > with those SoCs to give you an idea of the situation (you can find more > information on http://www.rockbox.org/wiki/SigmaTelSTMP3xxx) > > * I.MX233: Zen X-Fi Style, Zen X-Fi2, Zen X-Fi3, Sansa Fuze+ > * STMP3770: Zen Style M100/300 > * STMP3700: Zen, Zen Mozaic, Zen X-Fi, YP-Q2 > * STMP3600: Sansa Express, Zen V (Plus), YP-Z5 > * Unsure: Zen MX, Zen Style 100/300 (probably STMP3700 and STMP 3780) > > To summarise, there are lots of target out there using those chips and I > thought that it would be great to port Rockbox to them. I concluded that it > was possible to handle them all in the imx233 port with a reasonable amount > of modification and with careful handling. A major pain in handling those > SoC at once is that the registers are very similar but not exactly similar > and there are many of them (~500). Another major issue was that we had the > datasheet of the STMP3600 and i.MX233 but not the STMP3700/3770. > > I am glad to say today that I solved both issues. I managed to get my hand > on the two missing datasheets, that wasn't exactly easy but I managed to > got them without any NDA or anything! (please contact me if you are > interested). > > In order to solve the issue of keeping consistent a set of three big > register set, I decided that the best way was to automatically generate the > headers for them, out of the messy and buggy sigmatel/freescale headers > extracted from Linux ports. This works in two steps: first I produced an > XML description of the register map from those headers and then I produced > the rockbox headers from the XML description. The register set is chosen at > compile time with a switch in the target specific configuration header. > This way we ensure a correct use of registers at all time. > A byproduct of this register map being available is the (wonderful) hwstub > tool: it is a small blob that one can upload to any STMP device and allows > to control the device over USB. Using the shell tool I wrote, one can > identify the chip, load the register description and poke at registers > easily. The tool is scriptable in Lua which makes it easy and painless to > hack and debug early code for a device. The tool itself is not really STMP > specific and could be used on other SoC provided the blob is ported to > those obviously (the TCC and RK27xx are good candidates for it). > > This is still work in progress but the majority of the switch to the new > headers has now been done in my personal branch and proven successful. With > the help of Lorenzo we are currently porting Rockbox to the STMP3600 and > specifically to the Creative ZEN V and YP-Z5. I also have some solid > codebase for the STMP3700 with the Zen Mozaic and Zen X-Fi, port to the Zen > is in progress too. > > I will start to integrate those changes in the trunk soon. The amount of > modifications outside of the imx233/ subdir should be minimal (mostly > SOURCES, tools and configure) so I don't expect any breakable*. > If you have any comment/objection, please do so quickly before I begin > merging some code. If you would like all/some of those changes to go on > gerrit before being committed so that everyone is given a chance to review, > i'll be happy to do so. > > Long life to Rockbox! > > Amaury Pouly > > PS(*): the only expected potential breakage is the mkzenboot tool which I > improved/fixed for the more recent STMP based devices. It is used by the > Creative ZVM port I think. I have no way to check this though. >
