MP4 Nation Forums
Back to MP4 Nation - The MP4 Nation Blog - The Raz Special - Themes

Why don't they work? I suppose you already tried them, but with my player (Onda VX747) it seems the USB protocol is the same (haven't tried it yet though due to problems with my computer).

Have you already tried logging which traffic is sent through USB? You could use for example HHD USB Monitor while doing a firmware upgrade.

Pay special notice to the Control Packets sent to Endpoint0 as the commands are in there (as seen in the source of Ingenic's usbboot).

really?
usb boot have 5 stage:
1. mini boot, send less 4K code to SDRAM.
2. send command request CPU run code in RAM. those code would init cpu , timer , RAM .... etc. (called BOOT1)
3. PC's program will wait those code run over .
4. send more code about 3XX KB .
5. send command request CPU run code in RAM. (called BOOT2)

I can run usb_boot_tools before step 3.
step 3 will return ERROR

1. mini boot -> wherefrom does this code come? NAND flash? some (internal) ROM?
2. BOOT1 -> is this the same as stage1 mentioned in the usbtoolsv1.3.zip?
5. BOOT2 -> is this the same as stage2?

isn't there some program similar to vx747writer for the V2000SE which allows you to get past step 3?

I also have some questions regarding the .DL format in the (ChinaChip) firmware: you seem to understand them quite well. Could you look here and see if something is wrong or something is missing?

As far as I understand there are 4 (header) structures in a .DL file: CCDL, EXPT, IMPT & RAWD.
* RAWD -> raw data
* IMPT -> imported symbols
* EXPT -> exported symbols (including the main() routine)
* CCDL -> china chip dynamic loader?
Is this correct?

Now the symbols in IMPT: are pointers to the particular symbol loaded at the addresses in the structure or .. ?
And how about EXPT? Are pointers to these symbols loaded at these addresses?

Then some info about similarity between the V2000SE and the VX747: I've tried loading the V2000SE firmware (and the VX757) on my VX747 and succeeded, but both got stuck at the loading screen.
This means 2 things:
1) either the LCD init code is the same across the devices (unlikely)
2) or the Onda bootloader inits the LCD and loads ccpmp.bin which doesn't have to do anything anymore

So for getting Rockbox running I though about these possibilities:
* in development phase, we should compile code and upload them to SDRAM where it should get runned
* in public phase, we could use the official method and make a .HXF file or just go for the USBtools method and flash it like that OR we could use the method you're doing at the moment: replacing a game with our own (bootloader) code
* for dual booting there is the possibility of moving the original ccpmp.bin a bit further in NAND (and putting a bootloader before it which decides to load Rockbox or original firmware by pressing the hold button or similar) or just going for the game replacement way
What do you think?

I would also like to ask you if you could provide (some of) your source code from the emulator, first hello world application, ... ? That could help in easying development.

Thanks!

P.S.: I see you are talking about a dl format generator at bbs.imp3.net, could you release the source code for that too?

1. mini boot -> wherefrom does this code come? NAND flash? some (internal) ROM? (code in CPU internel)
2. BOOT1 -> is this the same as stage1 mentioned in the usbtoolsv1.3.zip? (code write by usb , less 4K)
5. BOOT2 -> is this the same as stage2? (code write by usb , limit by sdram)

isn't there some program similar to vx747writer for the V2000SE which allows you to get past step 3?
( i have only V2000SE , i don't konw about VX747 )

As far as I understand there are 4 (header) structures in a .DL file: CCDL, EXPT, IMPT & RAWD.
* RAWD -> raw data (YES)
* IMPT -> imported symbols (YES)
* EXPT -> exported symbols (including the main() routine) ( NO function main ,only export function location table)
* CCDL -> china chip dynamic loader? (YES, i think this is fix field )
Is this correct?

Now the symbols in IMPT: are pointers to the particular symbol loaded at the addresses in the structure or .. ?
And how about EXPT? Are pointers to these symbols loaded at these addresses?

( IMPT is point out dl file want what .
EXPT is point out what it can give .
if CCPMP.BIN can't give all function request by dl , the load action will not do.
EXPT like windows dll file DLL_EXPORT
)

Then some info about similarity between the V2000SE and the VX747: I've tried loading the V2000SE firmware (and the VX757) on my VX747 and succeeded, but both got stuck at the loading screen.
This means 2 things:
1) either the LCD init code is the same across the devices (unlikely)
2) or the Onda bootloader inits the LCD and loads ccpmp.bin which doesn't have to do anything anymore

(
VX989+ have three type LCM . but use same firmware. so i think LCM driver is save at an other location.
those MP4 have same CPU,but other hardware not same, so firmware can boot, but can't run success.
)

So for getting Rockbox running I though about these possibilities:
* in development phase, we should compile code and upload them to SDRAM where it should get runned
( load RockBoxy by CCPMP.BIN i think we should do .
the loader.dl is a plug . and using this we can load more plugs.
)
* in public phase, we could use the official method and make a .HXF file or just go for the USBtools method and flash it like that OR we could use the method you're doing at the moment: replacing a game with our own (bootloader) code
( i can't write boot loader , because some SoC detail is unknown )
* for dual booting there is the possibility of moving the original ccpmp.bin a bit further in NAND (and putting a bootloader before it which decides to load Rockbox or original firmware by pressing the hold button or similar) or just going for the game replacement way
What do you think?
( dual boot , we must face difference LCM , and difference hardware design.)


I would also like to ask you if you could provide (some of) your source code from the emulator, first hello world application, ... ? That could help in easying development.

( http://www.vote4u.cn/v2000se/cygwin.rar Develop ENV release by me . CYGWIN )

So if EXPT only contains exported function, how does the OS knows which function to load? e.g. SnakeMain() ? Or is this hard-coded in the source?

What does LCM mean? And as you say yourself, the Onda devices (Ainol too?) seem to have some sort of bootloader (miniboot?) which inits LCD, USB, NAND, etc... and loads ccpmp.bin and runs it.

So the ccpmp.bin is more or less universal and could be put on all devices, except for the fact that all these have there buttons mapped on other GPIO locations, some have touchscreen support, FM tuner isn't the same, audio codec could be external, ... ?

The advantage of a loader.dl is:
1) there's already a dual boot possibility
2) no need to worry about (permanently) bricking your device
Disadvantages are:
1) a game will be lost (although this limitation could get overcome by loading the actual game if a key is pressed)
2) bootup speed of Rockbox (you'll first have to boot the original firmware, load the game)

What exactly isn't known and what do you need to know?
And I didn't mean to replace the very first bootloader (the one which inits the CPU, LCD, ...), I meant replacing ccpmp.bin with a bootloader for Rockbox/original firmware.

With different hardware design you mean some devices have different NAND flash chips? Different SDRAM chips?

For example VX747 rev.1 has Samsung NAND, rev.2 has Hynix NAND, rev.3 ... (this isn't true, just an example)
-> You mean something like this?

Thanks!

P.S.: I've created a thread about these players on the Rockbox forums, I'm not sure if the (Rockbox) discussion should be moved over there ..?

So if EXPT only contains exported function, how does the OS knows which function to load? e.g. SnakeMain() ? Or is this hard-coded in the source?
(
Hard coded in source see CCPMP.BIN
)

Now the symbols in IMPT: are pointers to the particular symbol loaded at the addresses in the structure or .. ?
And how about EXPT? Are pointers to these symbols loaded at these addresses?
(
when CCPMP.BIN want load .dl
1. test file exists.
2. check header correct. (CCDL is exists)
3. find address of function CCPMP.BIN want in section EXPT ( ENTRY_FUNCTION )
4. load .dl to memroy
5. fill import table (IMPORT_TABLE)
6. jump to ENTRY_FUNCTION

so RAW DATA format may :

IMPORT_TABLE
FUNC1
FUNC2
ENTRY_FUNCTION
...
...
...

DWORD ImportEntry[IMPL_SIZE*2]={};
ImportEntry[0] = function 0 ;
ImportEntry[2] = function 1 ;
ImportEntry[4] = function 2 ;

)


What does LCM mean? And as you say yourself, the Onda devices (Ainol too?) seem to have some sort of bootloader (miniboot?) which inits LCD, USB, NAND, etc... and loads ccpmp.bin and runs it.
(
LCM = LCD Module .
LCM = LCD + Lcd Control Module
)

So the ccpmp.bin is more or less universal and could be put on all devices, except for the fact that all these have there buttons mapped on other GPIO locations, some have touchscreen support, FM tuner isn't the same, audio codec could be external, ... ?
(
Jz4732 = Jz4740 + secret usb boot code rom
Jz4740 = MIPS CPU + codec + usb device + usb host + iic ......
SoC pin define and reuse , should see Jz4740 uCos SDK
)

The advantage of a loader.dl is:
1) there's already a dual boot possibility
2) no need to worry about (permanently) bricking your device
Disadvantages are:
1) a game will be lost (although this limitation could get overcome by loading the actual game if a key is pressed)
2) bootup speed of Rockbox (you'll first have to boot the original firmware, load the game)
(
advantage is right.
disadvantage we should over come.
patch CCPMP.BIN , we should run special game at first.
)

What exactly isn't known and what do you need to know?
And I didn't mean to replace the very first bootloader (the one which inits the CPU, LCD, ...), I meant replacing ccpmp.bin with a bootloader for Rockbox/original firmware.
(
JZ4740 have an speedup unit . use the unit we can fast decode , encode .
those instruction is not open.
JZ4732 pin define not same as JZ4732 . whan you want direct operate SD-Card , you will find this.
so INGENIC's SDK can't direct use. we have to test hardware , modify sdk , if you want direct operate hardware.
so i select the way to write plug , but not port linux or wince to it.
)

With different hardware design you mean some devices have different NAND flash chips? Different SDRAM chips?
(
different LCM
different SDRAM
different NAND
}

For example VX747 rev.1 has Samsung NAND, rev.2 has Hynix NAND, rev.3 ... (this isn't true, just an example)
-> You mean something like this?
(
NAND have 8bit 16bit etc.
but can't test by software.
)

Could someone with a Ainol V2000SE download this source code and compile it? (you'll need libusb; win32 binary available here)

General:
there is a USB mode which you can enable on your device, I don't have a V2000SE but I thought if you press the PLAY button while turning your player on you'll enter it; you can recognize it if the player starts up but nothing appears on the screen and the only possibility to get out is the reset hole.

Windows users:
connect your device and when it asks for a driver, point the wizard to the inf provided in the ZIP file.
Then open a command prompt and run "usbtool.exe 3"
If you want to compile the source yourself, download libusb32 & mingw32, edit the Makefile and do "mingw32-make usbtoolwin".

Linux users:
compile the source by doing "make usbtool"
connect your device, open a terminal and do "sudo usbtool 3"

This will spit out some information (interrupt controller, RTC & GPIO readouts) if everything worked OK. Please post the results here.

Thank you.

Hi,
I don't have Ainol 2000SE, but i have another player with ingenic chip - clone of onda VX979+ named Laberg nJoy (Poland)

Chip: Jz4732 HXF-D0
SDRAM: 2X hynix 805E HY57V641620FTP-7
NAND FLASH: SAMSUNG 807 K9GAG08U0M-PCB0

>usbtool 3

[INFO] Found device, uploading application.
INTC_ISR -> 1000000
INTC_IMR -> ffffffff
INTC_IMSR -> 0
INTC_IMCR -> 0
INTC_IPR -> 0

RTC_RCR -> 91
RTC_RSR -> dbd9d3f9
RTC_RSAR -> 0
RTC_RGR -> 0
RTC_HCR -> 0
RTC_RCR -> 91
RTC_HWFCR -> 0
RTC_HRCR -> 0
RTC_HWCR -> 0
RTC_HWSR -> 32

GPIO_PXPIN(0) -> ffffffff
GPIO_PXPIN(1) -> feffffff
GPIO_PXPIN(2) -> 77ffffff
GPIO_PXPIN(3) -> 7fffffff


I'm not sure - operations of reading/writing by usbtool are done only to SDRAM, is it true ?

Thanks!

Now the next you should do is hold a button, do "usbtool 3", write down the changed line (GPIO_xx) and value and do this again for every other button.

It seems these players are very generic qua chips (flash, sdram, ..) so perhaps (with a little effort of you) you'll be able of running Rockbox in the near future

And as long as you stay in the 0x80000000 area for reading and writing, you'll be safe (that's SDRAM).

A-B button: GPIO_PXPIN(3) -> 7ffffffd
play/pause button: GPIO_PXPIN(3) -> 5fffffff
joy left: GPIO_PXPIN(3) -> 7fffffef
joy right: GPIO_PXPIN(3) -> 7ffffffb
joy up: GPIO_PXPIN(3) -> 7ffffff7
joy down: GPIO_PXPIN(3) -> 7ffffffe
joy push: GPIO_PXPIN(3) -> 77ffffff

Other GPIO_XX are still the same.

and some combinations of buttons:
A-B & joy right: GPIO_PXPIN(3) -> 7ffffff9
A-B & play/pause: GPIO_PXPIN(3) -> 5ffffffd
A-B & joy left: GPIO_PXPIN(3) -> 7fffffed
joy push & play/pause: GPIO_PXPIN(3) -> 57ffffff
joy down & play/pause: GPIO_PXPIN(3) -> 5ffffffe
joy left & A-B & play/pause: GPIO_PXPIN(3) -> 5fffffed

means that if play/pause is pushed, always is 5 in the beginning (in all combinations). Other positions are calculated. In first example of combinations it is d+b-f=(13+11-15)=9 ( or (d+b)Mod(f) ?)


What can cause error: "Sent data isn't the same as received data..." when I try to write something to sdram ?

p.s. and something other also was changed after reconnecting:

[INFO] Searching for device...
[INFO] Found device, uploading application.
INTC_ISR -> 1000000
INTC_IMR -> ffffffff
INTC_IMSR -> 0
INTC_IMCR -> 0
INTC_IPR -> 0

RTC_RCR -> 81
RTC_RSR -> e0014a66
RTC_RSAR -> 0
RTC_RGR -> 0
RTC_HCR -> 0
RTC_RCR -> 81
RTC_HWFCR -> 0
RTC_HRCR -> 0
RTC_HWCR -> 0
RTC_HWSR -> 32

GPIO_PXPIN(0) -> ffffffff
GPIO_PXPIN(1) -> feffffff
GPIO_PXPIN(2) -> 77ffffff
GPIO_PXPIN(3) -> 7fffffff


i found that before I press not only usb boot button (it is A-B button) when connecting usb cable, but also move joy up

A-B: 0x2
Play/pause: 0x20000000
Joy left: 0x10
Joy right: 0x4
Joy up: 0x8
Joy down: 0x1
Joy push: 0x8000000

The combinations are the above values binary OR'ed (actually: the default value is 0x7fffffff and when a button is pressed the appropriate value is cleared).

What can cause that error you mentioned:
Perhaps the command for reading data isn't the same as for the Onda VX747. What are you trying to upload and how? (what commandline)

And about the changing values, I assume you're talking about the RTC_xx ? That's normal because that is the Real Time Clock, so those values are reflecting the current time (I just put them there to proof there is a RTC in the devices, which is unused by the firmware)

Something (RD4730_PMP_2.2_ucos.zip) what I download from ingenic site. I don't expect anything special, it was only for curiosity

>usbtool 1 ucos.bin 0x80100000 (adress is taken according to usb_boot_manual_CN.pdf from ingenic, means near from the ceiling , with 0x80000000 results are the same)

USBtool v0.2 - (C) 2008 Maurus Cuelenaere
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[INFO] File size: 1116704 bytes
[INFO] Searching for device...
[INFO] Found device, uploading application.
[INFO] GET_CPU_INFO: JZ4740V1
[INFO] SET_DATA_ADDRESS to 0x80100000... Done!
[INFO] Sending data... Done!
[INFO] Verifying data...
[ERR] Sent data isn't the same as received data...

then I try read:

>usbtool 2 test.bin 0x80100000 1024
USBtool v0.2 - (C) 2008 Maurus Cuelenaere
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[INFO] Searching for device...
[INFO] Found device, uploading application.
[INFO] GET_CPU_INFO: JZ4740V1
[INFO] Reading data... Done!

file "test.bin" is empty - 1024 of "0" . But is this problem of writing, or reading ?


- Yes.
But sometimes also INTC_ISR is changing.

I don't want to disturb You in making Ingenic based players better, so - no more question from me (now).
I'm too thiny in programing...

wait i translate something about usb_boot

find usb_boot_guide_cn.pdf
this document have deteil of usb boot.

On basic principles
USB Boot whole process is divided into two stages, first stage is mainly responsible for basic initialization, the second stage to achieve the specific needs of the function. Equipment and reset after a successful connection host the first stage, this time through an order to boot into the second stage.
2.1 The first phase
The first phase of the main task is to guide the chip, and basic peripherals initialization, the second phase of the equipment to download the code to the SDRAM on the equipment and run. The first phase to undergo two USB data transmission. Because of the reduction after the development board SDRAM and other important peripherals not initialized, we can not work, so will download a small section of the code to initialize Cache in the implementation of the SDRAM and other important peripherals work properly after the then main code Downloaded to the implementation of SDRAM. So, the first paragraph of initialization code can not exceed the length of the processor instructions Cache size (Jz4740 for 16 K), and USB Boot dependent on the stability of SDRAM.
The first stage of general operational procedures are as follows:
1. Processor reset to begin the implementation of bootrom code;
2. Bootrom code reader Boot_sel [0:1] == 01, USB start from the beginning;
3. Console via the USB interface will be the first phase of the equipment to download the code to the processor in the Cache;
4. Mainframe equipment sent an order to implement the code in the Cache;
5. Initialization equipment were GPIO, PLL, serial and SDRAM, to return to after the completion of the implementation of bootrom code;
6. Through the USB interface will host the second phase of the equipment to download code equipment SDRAM;
7. Host sent orders to the implementation of SDRAM devices in the code, to this end of the first phase.
In "Usb Boot Manual" mentioned in the Boot operation, is actually the implementation of the 3-7 infantry operation.

So, to finish first phase we have to load good configuration (fconfig USBBoot.cfg in usb_boot), and boot.
I try change some parametrs in USBBoot.cfg but still without results.

in my VX979+ clone I found that SDRAM is 4 banks X 1Mbit X 16, but for NAND FLASH I only know that is 16Gbits , 4KB/page, Bits 8, RAW 3 (probably).

Not enought to boot.

Edit: All of this initialisation data are in upgrade tool - there is Onda VX979P upgrade tool, the problem is to find them. There is VX979P firmware v1.31 (with Polish as default language).