Dingoonity.org

Quote from: booboo on May 27, 2011, 11:56:00 am

Currently doing some specific work on a JZ4755 based device. While the kernel would be specific to that SoC, the rootfs is getting a nice deal of improvements too, from which the A320 and other older machines should benefit too. As soon as I'm done with this I'll probably update the A320 work, hopefully give another shot to the x760+ (yes, I'm that stubborn and got a logic analyzer for my birthday!), and see if I can progress with the CC1800 too, but that one is though because absolutely all has to be done from scratch based on uncommented (and possibly buggy) code. No docs.

Thank you very much for your reply.  That keeps my hopes up! I lost my beloved Digoo (aaarrghhh: the thing seems damed for all time: I fried the first one you know... ) and I'm considering a Gemei A330 because build quality is better than the Dingoo, which I had to repair and I've had some battery probs that probably fried the first one... I just repaired the left shoulder button and the speaker of me Dingoo and lost it the next week. I might wait for the PSP of my little nephew to become "available" when the sp*iled little @#$%^& gets a NDS-3D for his birthday. 

All the best and good luck w/ Dingux coding!

Whatever. Mind replying to the original question?. Do you have any docs or reference source code for the SPMP8000?

Would a Linux that uses the native operating system to access the device be an improvement over nothing?

That's quite a non-sense 

I know coLinux. But it runs on Windows, not uCos-II.

I guess it would be possible to hijack the device and use a bin game to load a linux kernel (so basically as way to run your code on the device). But we know how to run code without doing this. It is currently possible to execute code directly from ram after bootup and its also possible to replace the two stages of DRAM Init code as well as the Redboot bootloader. The only thing that that remains unknown is the "filesystem" or partition table that is used to store the firmware image (not the ROFS part).

Btw, the Letcool native OS is ecos based not ucos2.

I strongly support all these linux porting efforts :-)

I know coLinux. But it runs on Windows, not uCos-II.

Forgive me to offtopic, but does it work better\faster than Virtual Box?

it happened today

we see a kernel panic, but there are flags and launching modules 
this is a big step, leading error correction.

Yes, please keep trying.

I recommend to create your gitgub or google-code account where you can store  your current kernel. Thus everybody will see your work.

source code http://www.onlinedisk.ru/file/930896/
WE http://handheld.freeforums.org/linux-spmp8000-f57.html

Hi friends, today we have even more good news

RedBoot> load -m xmodem -r -b 0x200000
CCRaw file loaded 0x00200000-0x002f44ef, assumed entry at 0x00200000
xyzModem - CRC mode, 7818(SOH)/0(STX)/0(CAN) packets, 2 retries
RedBoot> go -c 0x200000
+do_go
image sel: 0, image_sel_set: 0
rmvb enable!
Mask interrupts on all channels
ID-CACHE sync and invalidate
set up a temporary context. workspace_end=0x00f00000, entry=0x00200000
switch context to trampoline. workspace_end=0x00efffb0
Uncompressing Linux... done, booting the kernel.

 machine ID --> OK

Booting Linux on physical CPU 0
Linux version 3.3.8spmp8000 ([email protected]) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-
8ubuntu3) ) #33 PREEMPT Mon Aug 27 17:17:11 MSK 2012
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: Letcool N350JP

 machine ID --> OK

bootconsole [earlycon0] enabled
Memory policy: ECC disabled, Data cache writeback
On node 0 totalpages: 8192
free_area_init_node: node 0, pgdat c01e0220, node_mem_map c0209000
  Normal zone: 64 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 8128 pages, LIFO batch:0
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc:

• 0

Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 8128
Kernel command line: console=ttyS0,115200n8 earlyprintk  debug mem=32M
PID hash table entries: 128 (order: -3, 512 bytes)
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 32MB = 32MB total
Memory: 30344k/30344k available, 2424k reserved, 0K highmem
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0xc2800000 - 0xff000000   ( 968 MB)
    lowmem  : 0xc0000000 - 0xc2000000   (  32 MB)
    modules : 0xbf000000 - 0xc0000000   (  16 MB)
      .text : 0xc0008000 - 0xc01b8000   (1728 kB)
      .init : 0xc01b8000 - 0xc01cf000   (  92 kB)
      .data : 0xc01d0000 - 0xc01e0a00   (  67 kB)
       .bss : 0xc01e0a24 - 0xc02080e4   ( 158 kB)
SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:112
time keeping init --> OK
time keeping init --> OK
spmp8000: unable to find timer node in dtbspmp8000: unable to find timer node in
 dtb
Kernel panic - not syncing: spmp8000: unable to find timer node in dtb

Backtrace:
[<c0011f20>] (dump_backtrace+0x0/0x10c) from [<c0154f00>] (dump_stack+0x18/0x1c)

 r6:c01cbcd0 r5:c01e0a40 r4:00000000
[<c0154ee8>] (dump_stack+0x0/0x1c) from [<c0154f88>] (panic+0x84/0x1c8)
[<c0154f04>] (panic+0x0/0x1c8) from [<c01bd450>] (spmp8000_sys_timer_init+0x38/0
x194)
 r3:c01d53e4 r2:c01d53e4 r1:600000d3 r0:c0196c08
 r7:c0249180
[<c01bd418>] (spmp8000_sys_timer_init+0x0/0x194) from [<c01baf0c>] (time_init+0x
28/0x34)
 r7:c0249180 r6:c01cbcd0 r5:c01e0a40 r4:00000001
[<c01baee4>] (time_init+0x0/0x34) from [<c01b86a0>] (start_kernel+0x1a8/0x31c)
[<c01b84f8>] (start_kernel+0x0/0x31c) from [<00008040>] (0x8040)
 r7:c01d3f88 r6:c01cb8a0 r5:c01d2014 r4:00053175