Porting Rockbox to YP-R0 (FAQ in the 1st post)

[SekraSoft]

Lorenz092, I tried to rewrite sources ( \ -> /, : -> / ) 10-15 minutes ago.
They are in code.zip

I do not know will it works or no. I changed sources using only intuition (without compiler and linux) so I recomend you DO NOT RUN IT on computer which have important data or you should deny acces to all important folders.

[Lorenz092]

Originally Posted by SekraSoft

Lorenz092, I tried to rewrite sources ( \ -> /, : -> / ) 10-15 minutes ago.
They are in code.zip

I do not know will it works or no. I changed sources using only intuition (without compiler and linux) so I recomend you DO NOT RUN IT on computer which have important data or you should deny acces to all important folders.

Good...but i tried befored you posted these
Results: I had to change something, but it worked. Not good because of the different path separators (i saw that you changed them, so now i'll try to recompile them )

In linux direct.h doesn't exists-> sys/stat.h instead

EDIT: it is better to use defines, so one source is good for many platforms

[SekraSoft]

Lorenz092: Good luck...

[Lorenz092]

Here the new source file (for now only unpacker as I've got no time ) and also the executable! No special libs are used...
(the code is to cleaned, like good identation, though)
Please see the changes because I've not tested it carefully...but the extraction works well!

[SekraSoft]

Originally Posted by Lorenz092

EDIT: it is better to use defines, so one source is good for many platforms

Yes... But when I wrote this programs I thinked "oh, it should work, it should work as fast as I can write, no matter how"

Originally Posted by Lorenz092

Here the new source file

Good... But MSVS can't find stdint.h.
So I rewrote this file and now:
* MSVS can compile it
* you can see my russian comments (about file format) (you killed them when you opened my file in CP1251 using your encoding ) and english (very bad english) translations.
+ I returned macros GET(offset) to its old state because we defined "uint"

Lorenz092, new sysdata.bin equals to original after repacking cycle using your edition of unpacker. So it works under windows.

[Lorenz092]

Originally Posted by SekraSoft

Yes... But when I wrote this programs I thinked "oh, it should work, it should work as fast as I can write, no matter how"

Good... But MSVS can't find stdint.h.
So I rewrote this file and now:
* MSVS can compile it
* you can see my russian comments (about file format) (you killed them when you opened my file in CP1251 using your encoding ) and english (very bad english) translations.
+ I returned macros GET(offset) to its old state because we defined "uint"

Lorenz092, new sysdata.bin equals to original after repacking cycle using your edition of unpacker. So it works under windows.

Good
Later I'll fix the packer

EDIT: hey slade! where are u? We need to test the new packer...or i can actually with linux try to repack the ROM file and then lebellium can test it! Right?

EDIT2:

Originally Posted by slade

Reserved for Changelogs

Last 4 Kernel builds failed. Still stuck on includes and porting MX37 to new Kernel

If I really understood, the main problem of running Android is the linux kernel that must be upgraded, right?
And with RockBox? What are the problems here? If I were able to flash and reflash without restrictions...This is the main issue testing I think.
But before that we need to mod some contents of the original firmware

EDIT3: i found something that could maybe be interesting! http://www.timesys.com/supported/processors/freescale
In this page you can find (for free??) some small linux images for freescale processors, and maybe an updated version of kernel for the mx37

[Lorenz092]

As I previously said, here the linux version of the packer! Tested with the original files and then compared both sysdata's (cmp linux cmd): they're the same!
@Sekra: i had to add some modifications, please see them

The usage is the same as the windows version...Included sources, object file (I don't know if it is really useful) and executable ready to use!

EDIT: the program works but maybe we should clean the sources a bit . I was thinking also to store them in google code (I...you must decide ), to keep track of changes and other things!

[SekraSoft]

Originally Posted by Lorenz092

As I previously said, here the linux version of the packer! Tested with the original files and then compared both sysdata's (cmp linux cmd): they're the same!
@Sekra: i had to add some modifications, please see them

I will check you changes under Windows.

Originally Posted by Lorenz092

EDIT: the program works but maybe we should clean the sources a bit .

Ohoho.

Originally Posted by Lorenz092

I was thinking also to store them in google code (I...you must decide ), to keep track of changes and other things!

I think it is good idea. But I can only make programs and do not know what should I do. So you should publish sources in G.C.
----------------------
EDIT 1:
I saw your changes. All have started to work (MSVS) when I replace "#include <dir.h>" to "#include <direct.h>"
And I don't find whre you define "uint". I see only my "#define uint unsigned __int32" for Windows & MSVS and your "#define __int64 int64_t" for Linux. I think it is magic.
+ All is OK under Win32. New sysdata.bin is good.
----------------------
EDIT 2:
What should we change (places where we can optimize)
1. Packer: int read_dir(uint parent); I think we can rewrite code and it will work without uint str_offset;
(for people who count every byte in stack and have veeeeeery fast acces to files)
2. Unpacker: archive (packed file) is being loaded in memory entirely so we may rewrite it. (for people who thinks that 30+ Mb for sysdata.bin is very bad or for very big files) But program may work slowly (I think I read every byte olny one time so we should read file only one time and file don't need to be loaded in memory. But I use random acces so some of bytes will be read twice or more times (because we have HDD). But we have a cache. But it can "forget" something and read again... And we have a swap... So I stop to think and say "I don't know".)
3. Packer & unpacker are work with 32b sizes of file (because all offsets is 32b) So it can't unpack archive whitch size is more 2GB.
4. We can don't define "LOG_ALL" or disable logging
5. We can rewrite packer and set buf_size=(2^N) or change last number in pack.ini to (2^N). "2^N" is not expression "2^N", it is requirenemt for number. This magic is for best memory allocating, fastest working of fread & fwrite, for best interaction with cache. Because usually some buffers have size 2^N.
6..infinity. Somebody may find something to add to this list
But we should not change this because we will waste much time and not find visible changes of repacking time for sysdata.bin

[Lorenz092]

Originally Posted by SekraSoft

I will check you changes under Windows.

Ohoho.

I think it is good idea. But I can only make programs and do not know what should I do. So you should publish sources in G.C.
----------------------
EDIT 1:
I saw your changes. All have started to work (MSVS) when I replace "#include <dir.h>" to "#include <direct.h>"
And I don't find whre you define "uint". I see only my "#define uint unsigned __int32" for Windows & MSVS and your "#define __int64 int64_t" for Linux. I think it is magic.
+ All is OK under Win32. New sysdata.bin is good.
----------------------
EDIT 2:
What should we change (places where we can optimize)
1. Packer: int read_dir(uint parent); I think we can rewrite code and it will work without uint str_offset;
(for people who count every byte in stack and have veeeeeery fast acces to files)
2. Unpacker: archive (packed file) is being loaded in memory entirely so we may rewrite it. (for people who thinks that 30+ Mb for sysdata.bin is very bad or for very big files) But program may work slowly (I think I read every byte olny one time so we should read file only one time and file don't need to be loaded in memory. But I use random acces so some of bytes will be read twice or more times (because we have HDD). But we have a cache. But it can "forget" something and read again... And we have a swap... So I stop to think and say "I don't know".)
3. Packer & unpacker are work with 32b sizes of file (because all offsets is 32b) So it can't unpack archive whitch size is more 2GB.
4. We can don't define "LOG_ALL" or disable logging
5. We can rewrite packer and set buf_size=(2^N) or change last number in pack.ini to (2^N). "2^N" is not expression "2^N", it is requirenemt for number. This magic is for best memory allocating, fastest working of fread & fwrite, for best interaction with cache. Because usually some buffers have size 2^N.
6..infinity. Somebody may find something to add to this list
But we should not change this because we will waste much time and not find visible changes of repacking time for sysdata.bin

I agree haha...seriously good ideas and good it works...
For the google code is not a problem...I can do it, have you got a gmail access? To become the main developer...

I'm quite new to C++ and I don't know really how is the best solution to manage files but with python i used to define a BUFFER (like 1 MB), then read this amount of data, do what you have to do, and then read this data again until EOF.

Then another idea is to add some error codes (like you previous said)

Before that, we need to test if the basics work really in the real device (I mean a new modified sysdata...like my soundmod)
Oh man I should also port the python aui modder to C++! (I'll do it when I'll got some free time to learn also some C++ tricks)

All in all, nice!

[SekraSoft]

Originally Posted by Lorenz092

I can do it, have you got a gmail access? To become the main developer...

I think I have: sekrasoft at gmail.com

Originally Posted by Lorenz092

I'm quite new to C++ and I don't know really how is the best solution to manage files but with python i used to define a BUFFER (like 1 MB), then read this amount of data, do what you have to do, and then read this data again until EOF.

It is for unpacker, is not it? So we should keep filesystem (first kilobytes of sysdata.bin) in memory. Or do not making changes in program.

Originally Posted by Lorenz092

Then another idea is to add some error codes (like you previous said)

Yes... Now they are only 0 (now errors) and 1...

Originally Posted by Lorenz092

Before that, we need to test if the basics work really in the real device

I am speaking about running repacking under linux and about optimization... But nobody said that player is working...

Originally Posted by Lorenz092

Oh man I should also port the python aui modder to C++! (I'll do it when I'll got some free time to learn also some C++ tricks)

I don't like object oriented programming so I use C every day but not C++

[slade]

hey guys,
some good news.
Android did a boot and crashed right at the android booting screen. I somewhat managed to hack together a filesystem from other arm v6 phones. but I am still using the samsung kernel which i guess will make it impossible to boot android normaly. so now the bad news
kernel is still the old one and I haven't been able to compile a working one with the needed changes for imx37 architecture. I hope i will be able someday to get the kernel compiled. but i am unsure if i'll manage to keep the r0 samsung firmware intact. I need space loooots of space for android my best guess will be to kexec into the other kernel and load fs out of an image if thats even possible, but for now i was happy to see the booting screen for 1 second

have a good day guys

[MademoiselleGeek]

Hey guys!
I've been following this thread since the very beginning. Just registered to tell you that you've got another cheerleader.
This is quite cool. I like the idea of using Android on my YPR0.
My C++ skills aren't good enough - or else I'd started contributing long ago. Sorry.

[Lorenz092]

Originally Posted by slade

hey guys,
some good news.
Android did a boot and crashed right at the android booting screen. I somewhat managed to hack together a filesystem from other arm v6 phones. but I am still using the samsung kernel which i guess will make it impossible to boot android normaly. so now the bad news
kernel is still the old one and I haven't been able to compile a working one with the needed changes for imx37 architecture. I hope i will be able someday to get the kernel compiled. but i am unsure if i'll manage to keep the r0 samsung firmware intact. I need space loooots of space for android my best guess will be to kexec into the other kernel and load fs out of an image if thats even possible, but for now i was happy to see the booting screen for 1 second

have a good day guys

Good good goooood
But for rockbox?
EDIT: ah and sekra have done a functional packager...both for win and linux! YOu should test to mod it with my previous default.aui modded and test if works...

[slade]

ok guys, i am switching compiles now instead of code sourcery i am switiching to android compiler arm-eabi-4.4.0.
I think i am getting close to get the source code for the kernel done. I have only a few errors left but they are bugging me like crazy. Next step will be a full vendor setup and then figure out to a)how to make new rootfs work b) dual boot and c) where and how to store android so it could actually boot and be put inside the rom file

[SprayMyPerfume]

Any images of android on the Samsung R0? I want to see the device in detail.

[slade]

not that far yet to show anything really basically nothing is working

[Appick]

Originally Posted by MademoiselleGeek

Hey guys!
I've been following this thread since the very beginning. Just registered to tell you that you've got another cheerleader.
This is quite cool. I like the idea of using Android on my YPR0.
My C++ skills aren't good enough - or else I'd started contributing long ago. Sorry.

We'll have to set up a cheerleading team ......... might have to shave my knees though if I have to wear a frilly skirt!

[MademoiselleGeek]

Originally Posted by Appick

We'll have to set up a cheerleading team ......... might have to shave my knees though if I have to wear a frilly skirt!

lol, it's cooler if you don't. Besides, the hair and the frills will interlock and therefore keep your skirt down.

[Lorenz092]

Slade you're the best
But I think you lost my post where I found a site "offering" some linux kernel versions for the mx37...I don't actually explored it but it may be useful!

Good luck!!! (because also coding is sometimes questions of luck )

[Lorenz092]

Maybe I'm crazy but I was thinking about the sd card. Now I haven't any little sd but I use to boot linux on a fuc***ng ARM (Via WM8505) netbook (it is really slow...but i'm not here to speak about it ) via the SD card.
The card is simply formatted and splitted into 2 partitions (well I use a usb stick formatted in ext to do the trick but it is the same). The first is bootable fat that contains the kernel and boot related files (I'm not really expert in those things...) and the ext partition is the linux filesystem.
Turning device on, shows a half second the original ce bootscreen and then boots up the sd. I read that this device has U-BOOT, and it hasn't any bios.

Is the imx37 capable to boot from sd? if so is it really useful for us? I think yes! In particular it is useful to do every test without touching the internal flash (I'm really curios to experiment but i can't )

And now a question: in fact what does the bootloader do? Preload kernel? Or initialize hardware?

Some links:

- Discussion about sd booting (read between the comments)
http://imxcommunity.org/group/imx23/...3AGroup%3A1488

- Bentoo linux (fat part and ext part)
http://bento-linux.org/wiki/vt8505/wm8505/debian

If this could be useful, ok, otherwise no problem

EDIT: other links about mx37

http://www.google.it/url?sa=t&source...QC8O8A&cad=rja