CI20 "stress testing" and mixed results

[Riccardo Mottola]

Hi All!

writing to the mailinglist, although I lost track who is onboard and who
not.. we are a spare group already.
Given the positive initial results after the latest patches and the
Kernels done by Nikolaus which enabled Keyboard and HDMI and made thus
the administration of the small board much easier, I decided it to
promote it to a usable system. I bought a decent SSD (since flash is not
bootable) and started compiling on it and using it remotely through ssh
(not yet able to run X11).

At a first test the only issue is that a "soft reboot" often does not
boot or has a non-functional machine (not working, keyboard most often,
sometimes also no HDMI), however a hard reboot as a higher change of
success!

At first, I had several lock-ups, e.g. while doing a larger git
checkout... or sometimes without specific reason.
But when it did work I started "stressing" the little board with
compiling lots of stuff, not last a big program which as of now fails to
compile but will run for 6 hours about before aborting and I know it
makes "heavy use" of memory and disk while linking.

The first times I tried, it did run half, then the machine locked up for
memory starvation - on the console I read about programs being killed,
however something was not graceful, since it locked up. I retried... and
compilation ended "correctly" with an error... and so for some days. I
always "hard reboot".

I think the board doesn't come up always stable... don't know, even if
all peripheral come up "sometimes" it still doesn't mean it is stable.

I added a small 512MB swap file which while of little size, apparently
has eased kernel OOM kill handling and started testing again

Incredible, I launched several builds .... and the board stays up.. so
if it wants I can!
The equivalent build tends to overheat my ThinkPad for example... now
the board is up 3 days and may run 6hours flawlessly.
I hope to get everything compiling (and then working) since this is some
sort of "performance benchmark" we can use, I have several machines. I
don't much how much is left, but... e.g. 7-8 hours would make it nice.

The performance may not be super-fast, but what impresses is me is that
the CPU (board left on the table, no case either) runs extremely cool.
This means that it has a very high performance/Watt ratio, even if the
Performance is low... it runs as cool as a Raspberry PI 1.... since the
newer ones heat up to the self-destruction if not massively cooled.

So... let's keep up the good work, this JZ4780 is really interesting!

Riccardo

[Riccardo Mottola]

Hi,

Riccardo Mottola wrote:
> I think the board doesn't come up always stable... don't know, even if
> all peripheral come up "sometimes" it still doesn't mean it is stable.

just a little after I wrote this "wow" mail... I did a "git pull" and
the system did hang.
I did a reset - no HDMI output, I did "pull the plug" and got it
working, but no USB. Sssh'd in did some cleanup.. and after a while when
the build started, the machine froze again, not completely. Here is what
happens:
In an open console I can "type" so it is not frozen.
I can "interrupt" the buid for example and get back to console
I left "htop" open.... and see that very little RAM was used, so no swap
necessary.

Then I tried interesting things. Launch "top"... and it hangs, nothing
happens.
If I quit the running "htop" and relaunch it ... it works.

At first, i thought no new processes can be started, but this is not
totally true! also "ls" or "dmesg" work. "ps" too!

vmstat:

procs -----------memory---------- ---swap-- -----io---- -system--
------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy
id wa st
 0  1      0 415716  74360 369092    0    0    31     7  194   44  1  1
97  1  0


for that, dmesg, shows nothing suspect at the end, no hard errors:

[   16.752743] usb 3-1.1: ctrl urb status -62 received
[   16.819915] hid-generic 0003:05AC:0202.0002: input: USB HID v1.00
Keyboard [Alps Electric M2452] on usb-134a0000.ohci-1.1/input0
[   17.048795] rc rc0: two consecutive events of type space
[   29.678726] dm9000 16000000.dm9000: eth0: link down
[   29.718729] dm9000 16000000.dm9000 eth0: link down
[   31.328707] dm9000 16000000.dm9000: eth0: link up, 100Mbps,
full-duplex, lpa 0xC1E1
[   31.337378] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   32.538881] wlan0_power: disabling
[   44.753734] using random self ethernet address
[   44.759683] using random host ethernet address
[   44.764754] using host ethernet address: 32:70:05:18:ff:78
[   44.764765] using self ethernet address: 46:10:3a:b3:af:d9
[   44.776911] usb0: HOST MAC 32:70:05:18:ff:78
[   44.813085] usb0: MAC 46:10:3a:b3:af:d9
[   44.817525] using random self ethernet address
[   44.825107] using random host ethernet address
[   44.832378] g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
[   44.841761] g_ether gadget: g_ether ready
[   44.846343] dwc2 13500000.usb: bound driver g_ether

one error is about wifi, one for usb that probably caused it not to work...

"top" hangs, but also "poweroff" did hang.. Isn't that a strange behaviour?

Riccardo

[Gabriele Svelto]

On 17/11/20 16:04, 'Riccardo Mottola' via MIPS Creator CI20 Development

> In an open console I can "type" so it is not frozen.> I can
"interrupt" the buid for example and get back to console> I left "htop"
open.... and see that very little RAM was used, so no swap> necessary.

> [...]

> "top" hangs, but also "poweroff" did hang.. Isn't that a strange behaviour?

I encountered this issue multiple times with my board when running large
builds (which often used swap space). I never could tell what caused
them but given that they were random-ish in nature (different stack
traces in dmesg and slightly different "freezing" behavior) I chalked
them up to an issue with memory.

This u-boot change mostly fixed the issue on my board:

https://github.com/gabrielesvelto/CI20_u-boot/commit/3c4bdbd749edc344abf11823282363d79c1d5eeb

I say mostly in the sense that it did greatly reduce the number of
occurrences of these freezes but they never fully went away. My guess is
that there's still something wrong with the timings. One might try to
lower the memory clock to see if it helps with the issue.

Gabriele

[Zhou Yanjie]

Hi Riccardo,

On 2020/11/17 上午7:30, 'Riccardo Mottola' via MIPS Creator CI20

Development wrote:
> Hi All!
>
> writing to the mailinglist, although I lost track who is onboard and
> who not.. we are a spare group already.
> Given the positive initial results after the latest patches and the
> Kernels done by Nikolaus which enabled Keyboard and HDMI and made thus
> the administration of the small board much easier, I decided it to
> promote it to a usable system. I bought a decent SSD (since flash is
> not bootable) and started compiling on it and using it remotely
> through ssh (not yet able to run X11).
>

Glad to hear that!

> At a first test the only issue is that a "soft reboot" often does not
> boot or has a non-functional machine (not working, keyboard most
> often, sometimes also no HDMI), however a hard reboot as a higher
> change of success!
>
> At first, I had several lock-ups, e.g. while doing a larger git
> checkout... or sometimes without specific reason.
> But when it did work I started "stressing" the little board with
> compiling lots of stuff, not last a big program which as of now fails
> to compile but will run for 6 hours about before aborting and I know
> it makes "heavy use" of memory and disk while linking.
>
> The first times I tried, it did run half, then the machine locked up
> for memory starvation - on the console I read about programs being
> killed, however something was not graceful, since it locked up. I
> retried... and compilation ended "correctly" with an error... and so
> for some days. I always "hard reboot".
>
> I think the board doesn't come up always stable... don't know, even if
> all peripheral come up "sometimes" it still doesn't mean it is stable.
>

Would it be convenient to tell me the name of the software you compiled?
I am currently trying to write the new SMP driver and new cache driver
of CI20.

At present, I am testing the stability by running SPEC CPU2000 on
debian9. I hope to use the same method and environment as yours to test
in order to try to solve the unstable problem you mentioned.

> I added a small 512MB swap file which while of little size, apparently
> has eased kernel OOM kill handling and started testing again
>
> Incredible, I launched several builds .... and the board stays up.. so
> if it wants I can!
> The equivalent build tends to overheat my ThinkPad for example... now
> the board is up 3 days and may run 6hours flawlessly.
> I hope to get everything compiling (and then working) since this is
> some sort of "performance benchmark" we can use, I have several
> machines. I don't much how much is left, but... e.g. 7-8 hours would
> make it nice.
>
> The performance may not be super-fast, but what impresses is me is
> that the CPU (board left on the table, no case either) runs extremely
> cool. This means that it has a very high performance/Watt ratio, even
> if the Performance is low... it runs as cool as a Raspberry PI 1....
> since the newer ones heat up to the self-destruction if not massively
> cooled.
>
> So... let's keep up the good work, this JZ4780 is really interesting!

Ingenic processors have always had a good performance/Watt ratio. After
JZ4780, they also launched a series of new processors, such as the X1830
with stronger single-thread performance.

The single-thread performance of X1830 is about 1.5 times of JZ4780, but
it is a pity X1830 is only a single core processor, and only have 128MiB
built-in DDR2 memory, which limits its use range, and because the
built-in DDR2, makes it work at a higher temperature than thee previous
Ingenic processors.

After the X1830, Ingenic launched the X2000/X2000E with SMT
(singel-core, dual-thread). This is a product using  the new XBurst2
core, each single-core has two thread (logic core). The X2000E has a
built-in 256MiB LPDDR2, and the single-thread performance at the same
frequency is about twice that of JZ4780. The overall performance at the
default frequency is approximately 3.5 times of JZ4780.

There are rumors that next year, Ingenic will also launch an external
memory version processor using the XBurst2 core. If you are interested
in these new processors or X1830 and X2000, I can donate some
development boards that use these processors to you when appropriate.


Thanks and best regards!


>
> Riccardo
>

[Riccardo Mottola]

Hi

Zhou Yanjie wrote:
> Would it be convenient to tell me the name of the software you
> compiled? I am currently trying to write the new SMP driver and new
> cache driver of CI20.
>

Sure! I wanted it to be a surprise, like "hey, it compiled and works"...
I am compiling ArcticFox, which is a PaleMoon/Firefox derivative
browser. It is older, but lighter and usable on older computers. I want
to reinstantiate MIPS and ARM builds by pulling in missing patches from
Firefox which Palemoon left out apparenlty.

> At present, I am testing the stability by running SPEC CPU2000 on
> debian9. I hope to use the same method and environment as yours to
> test in order to try to solve the unstable problem you mentioned.

I noticed that more than compiling itself (=raw CPU power, cache, memory
access) I get frequent hiccups in the build scripts (which means more
file I/O I think) and quite often in using git on such a large
repository. Sometimes just a pull or a git status cause the CI20 to
hang. (More about that later)

>
> Ingenic processors have always had a good performance/Watt ratio.
> After JZ4780, they also launched a series of new processors, such as
> the X1830 with stronger single-thread performance.
>
> The single-thread performance of X1830 is about 1.5 times of JZ4780,
> but it is a pity X1830 is only a single core processor, and only have
> 128MiB built-in DDR2 memory, which limits its use range, and because
> the built-in DDR2, makes it work at a higher temperature than thee
> previous Ingenic processors.

That is really a "downgrade" compared to the CI20 board

>
> After the X1830, Ingenic launched the X2000/X2000E with SMT
> (singel-core, dual-thread). This is a product using  the new XBurst2
> core, each single-core has two thread (logic core). The X2000E has a
> built-in 256MiB LPDDR2, and the single-thread performance at the same
> frequency is about twice that of JZ4780. The overall performance at
> the default frequency is approximately 3.5 times of JZ4780.

That seems very much geared to embedded market and of little use for
single-board computers which I am intersted in, external RAM allows
easily 1-2GB is better cooled and can also easily make a "new revision"
of a board by doubling it.

>
> There are rumors that next year, Ingenic will also launch an external
> memory version processor using the XBurst2 core. If you are interested
> in these new processors or X1830 and X2000, I can donate some
> development boards that use these processors to you when appropriate.

That would be interesting... dual-coure it would even be very
interesting, suppose 2core with 4threads, 3 or 4GB of RAM would compete
with Raspberries, but hopefully without the overheating issues those have!!

Do those processor board run the same linux and kernel we are working
on? Debian?


As said, I foten crash the machine using GIT on the large repository I
have for ArcticFox.
Today I was able to see a message on the console, since it was still active.
I attach a screenshot.

Riccardo

[Zhou Yanjie]

On 2020/11/20 上午7:09, Riccardo Mottola wrote:
> Hi
>
> Zhou Yanjie wrote:
>> Would it be convenient to tell me the name of the software you
>> compiled? I am currently trying to write the new SMP driver and new
>> cache driver of CI20.
>>
>
> Sure! I wanted it to be a surprise, like "hey, it compiled and
> works"... I am compiling ArcticFox, which is a PaleMoon/Firefox
> derivative browser. It is older, but lighter and usable on older
> computers. I want to reinstantiate MIPS and ARM builds by pulling in
> missing patches from Firefox which Palemoon left out apparenlty.
>

Could you give me a specific repository address? I searched several 
ArcticFox on github, but none of them seem to be web browsers.

>
>> At present, I am testing the stability by running SPEC CPU2000 on
>> debian9. I hope to use the same method and environment as yours to
>> test in order to try to solve the unstable problem you mentioned.
>
> I noticed that more than compiling itself (=raw CPU power, cache,
> memory access) I get frequent hiccups in the build scripts (which
> means more file I/O I think) and quite often in using git on such a
> large repository. Sometimes just a pull or a git status cause the CI20
> to hang. (More about that later)
>

We (Nikolaus and Paul and I) have noticed that the MMC of CI20 seems to
be unstable. I don't know if it is related to the phenomenon you
mentioned. I used to compile kernel 5.7 on CI20 and it was completed
normally.

>>
>> Ingenic processors have always had a good performance/Watt ratio.
>> After JZ4780, they also launched a series of new processors, such as
>> the X1830 with stronger single-thread performance.
>>
>> The single-thread performance of X1830 is about 1.5 times of JZ4780,
>> but it is a pity X1830 is only a single core processor, and only have
>> 128MiB built-in DDR2 memory, which limits its use range, and because
>> the built-in DDR2, makes it work at a higher temperature than thee
>> previous Ingenic processors.
>
> That is really a "downgrade" compared to the CI20 board
>

Yes, too small memory makes me have to set up a large SWAP when I use
it, and the performance of SWAP is really not flattering, so even the
single-thread performance of X1830 is improved, but using it (running
debian9) is really painful.

>>
>> After the X1830, Ingenic launched the X2000/X2000E with SMT
>> (singel-core, dual-thread). This is a product using  the new XBurst2
>> core, each single-core has two thread (logic core). The X2000E has a
>> built-in 256MiB LPDDR2, and the single-thread performance at the same
>> frequency is about twice that of JZ4780. The overall performance at
>> the default frequency is approximately 3.5 times of JZ4780.
>
> That seems very much geared to embedded market and of little use for
> single-board computers which I am intersted in, external RAM allows
> easily 1-2GB is better cooled and can also easily make a "new
> revision" of a board by doubling it.
>

Indeed, according to Ingenic's introduction, X2000/X2000E is mainly for 
the embedded market, but the 256MiB memory of X2000E can support it to
complete some simple single-board computer tasks.

>>
>> There are rumors that next year, Ingenic will also launch an external
>> memory version processor using the XBurst2 core. If you are
>> interested in these new processors or X1830 and X2000, I can donate
>> some development boards that use these processors to you when
>> appropriate.
> That would be interesting... dual-coure it would even be very
> interesting, suppose 2core with 4threads, 3 or 4GB of RAM would
> compete with Raspberries, but hopefully without the overheating issues
> those have!!
>

I guess it is probably an external memory version processor with
specifications similar to X2000, single-core dual-thread, 1.5~1.8GHz
frequency. If this is the case, I think we should be able to design a
board with 2GiB of memory.

> Do those processor board run the same linux and kernel we are working
> on? Debian?
>

Yes, all boards can run debian (9 or 10).

>
> As said, I foten crash the machine using GIT on the large repository I
> have for ArcticFox.
> Today I was able to see a message on the console, since it was still
> active.
> I attach a screenshot.
>

After I find the correct address, I am going to give it a try. In
addition, I am also going to try to compile the source code of docker.io
on CI20. On X1830, it takes nearly 50 hours.

[Riccardo Mottola]

Hello Zhou!

Zhou Yanjie wrote:
>
> Could you give me a specific repository address? I searched several 
> ArcticFox on github, but none of them seem to be web browsers.

Of course. Here it is:

https://github.com/rmottola/Arctic-Fox
(dev branch for latest
Also, news of the day, I was able to fix build enough so that it
compiles to the end on MIPS! YAY! It crashes on startup though...

Compilation takes 6-7 hours by using both cores.. That is not bad at
all! I have no comparison to ARM since I am unable to build on raspberry
yet.
However, to give an idea, an i7 takes 35 minutes, an i5 1gen 40 about...
and a venerable 32bit Pentium4 HT takes 2hours (which is incredibly fast
if you think, proving that in some task the NetBurst architecture was
really powerful, now that it made the 20th anniversary general usage
makes the computer feel slower actually) an G4 single takes about the same.
So, not overly fast, but still very respectable. I also think that some
more RAM would have helped, e.g. 2GB.
Times are just a reference, since they are different computers, disks,
compiler revisions, not an real benchmark at all, just a ballpark.

>
> We (Nikolaus and Paul and I) have noticed that the MMC of CI20 seems
> to be unstable. I don't know if it is related to the phenomenon you
> mentioned. I used to compile kernel 5.7 on CI20 and it was completed
> normally.

Could be related, as said.. I often crash the system with just a git
operation like status pull or push. Have you seen my screenshot?
Sometimes the board"freezes", sometimes not, remaining with blinking
LEDs, a typeable console, but unable to start new processes.

>
>> That is really a "downgrade" compared to the CI20 board
>>
>
> Yes, too small memory makes me have to set up a large SWAP when I use
> it, and the performance of SWAP is really not flattering, so even the
> single-thread performance of X1830 is improved, but using it (running
> debian9) is really painful.
>

Especially since we swap to slow devices, even subject to wear....

> Indeed, according to Ingenic's introduction, X2000/X2000E is mainly
> for the embedded market, but the 256MiB memory of X2000E can support

> it to complete some simple single-board computer tasks. Ys

Yes,.. although the  JZ4780 looks flexible.... I wonder if it can take
2GB of RAM? Perhaps even 4? I don't know how its memory addresses are.
The X2000 looks more limited.
Also, dual-core is better than dual-thread, usually.

What do you have, some "demo" boards?

>
> I guess it is probably an external memory version processor with
> specifications similar to X2000, single-core dual-thread, 1.5~1.8GHz
> frequency. If this is the case, I think we should be able to design a
> board with 2GiB of memory.

Wonderfull! Planning even a 4GB upgrade for the thirsty people.

>
>
>> Do those processor board run the same linux and kernel we are working
>> on? Debian?
>>
>
> Yes, all boards can run debian (9 or 10).

perfect. That makes access to software beyond the kernel easy enough,
like the CI20!

>
>
> After I find the correct address, I am going to give it a try. In
> addition, I am also going to try to compile the source code of
> docker.io on CI20. On X1830, it takes nearly 50 hours.

That's a lot of time, mine is faster, but as said, the experience is it
stresses the machine quite a bit.

We should pinpoint out if the issues are MMC issues or memory issues as
Gabriele tries to suggest.


Riccardo

[Paul Boddie]

On Saturday, November 21, 2020 at 11:23:51 PM UTC+1 Riccardo Mottola wrote:

Hello Zhou!


Zhou Yanjie wrote:
>
> We (Nikolaus and Paul and I) have noticed that the MMC of CI20 seems
> to be unstable. I don't know if it is related to the phenomenon you
> mentioned. I used to compile kernel 5.7 on CI20 and it was completed
> normally.

Could be related, as said.. I often crash the system with just a git
operation like status pull or push. Have you seen my screenshot?
Sometimes the board"freezes", sometimes not, remaining with blinking
LEDs, a typeable console, but unable to start new processes.

Just to note that I found the 3.18 kernel to be very stable with no MMC issues to speak of. It could just be a case of the usual Linux kernel decay processes at work, even with supposedly upstreamed drivers.

 

[...]

Yes,.. although the  JZ4780 looks flexible.... I wonder if it can take
2GB of RAM? Perhaps even 4? I don't know how its memory addresses are.

I imagine that the JZ4780 is limited to 2GB in practice, due to limitations with MIPS32 and the equal division of the address space into user and kernel regions. Even if MIPS reworked the memory model, I doubt that the JZ4780 would support whatever architecture revision would be involved.

A few years ago now, when Luke Leighton was doing his EOMA68 crowdfunding and was trying to figure out whether he should go with an somewhat-finished JZ4775-based board with 2GB and with no binary blob issues [1] or an almost-finished Allwinner A10 board with 1GB and some uncertainty about blobs [2], I was enthusiastic about the JZ4775 option, particularly since it seemed as if he was getting some support from Ingenic with the design. Part of that enthusiasm was to see a single-board computer with 2GB which was not particularly common at that time (2016), and to give the product a longer lifespan. Understandably, he went with the 1GB A10-based board, but then spent some time revising it to give it 2GB, which delayed things considerably.

[1] http://rhombus-tech.net/ingenic/jz4775/news/

[2] http://rhombus-tech.net/allwinner_a10/news/

One of the reasons why the A10 was ultimately acceptable was that FSF endorsement, which was sought, appears to be available to products that might need binary blobs to use certain peripherals but where such peripherals are not essential and are also not advertised. Had that been known earlier, the JZ4780 might have been a consideration. But now I think I am way off topic!

I think a 64-bit MIPS architecture CPU would be needed to use larger amounts of memory, but it sounds like Ingenic aren't so interested in making one at the moment.

[...]

 

> > After I find the correct address, I am going to give it a try. In
> > addition, I am also going to try to compile the source code of
> > docker.io on CI20. On X1830, it takes nearly 50 hours.
>
> That's a lot of time, mine is faster, but as said, the experience is it
> stresses the machine quite a bit.
>
> We should pinpoint out if the issues are MMC issues or memory issues as
> Gabriele tries to suggest.

I would imagine that any lack of memory is definitely a performance inhibitor below 1GB. I recall that the 32MB, JZ4720-based Ben NanoNote was dependent on swap to do compilation at all, or to run things like apt-get. A system with 128MB was probably enough for Debian about ten years ago, and I imagine that lighter compilation jobs would work fine, but having used the ARM-based Efika Smartbook with 512MB, it becomes clear that even lightweight desktop environments can struggle. On the CI20, I've used MATE and it is just about usable.

Paul

[Zhou Yanjie]

Hello Riccardo, Nikolaus, Paul,

The new SMP patch and cache driver have been completed. The current test
shows that some known instabilities have been resolved, and the
performance has also been improved (UnixBench score improved by more
than 10%). I am currently in the final round of testing. I expect to
send it out this week (before Christmas) for you to test.

Thanks and best regards!


On 2020/11/22 上午6:23, 'Riccardo Mottola' via MIPS Creator CI20

[H. Nikolaus Schaller]

Hi,

> Am 20.12.2020 um 15:23 schrieb Zhou Yanjie <zhouy...@wanyeetech.com>:
>
> Hello Riccardo, Nikolaus, Paul,
>
> The new SMP patch and cache driver have been completed.

Great!

> The current test shows that some known instabilities have been resolved,

After I disabled the old SMP code a while ago my board did run very stable. I could debootstrap ca. 5 different user-space images.
It did freeze only once when I accidentially touched the SD card. It seems the SD card reader isn't holding the card very strongly.

> and the performance has also been improved (UnixBench score improved by more than 10%).

Great!

> I am currently in the final round of testing. I expect to send it out this week (before Christmas) for you to test.

I guess most of us will have plenty of time to run tests...

> Thanks and best regards!

Thanks and same to you!
Nikolaus

PS: we are working on the old jz4730 minibooks (alpha 400, letux 400, razorbook, elonex etc.). We are currently stuck at reading the SD card, but otherwise it already boots quite well.
So we may need your help and expertise for reviewing the code :)

[Zhou Yanjie]

Hi Nikolaus,

On 2020/12/20 下午10:32, H. Nikolaus Schaller wrote:
> Hi,
>
>> Am 20.12.2020 um 15:23 schrieb Zhou Yanjie <zhouy...@wanyeetech.com>:
>>
>> Hello Riccardo, Nikolaus, Paul,
>>
>> The new SMP patch and cache driver have been completed.
> Great!
>
>> The current test shows that some known instabilities have been resolved,
> After I disabled the old SMP code a while ago my board did run very stable. I could debootstrap ca. 5 different user-space images.
> It did freeze only once when I accidentially touched the SD card. It seems the SD card reader isn't holding the card very strongly.
>
>> and the performance has also been improved (UnixBench score improved by more than 10%).
> Great!
>
>> I am currently in the final round of testing. I expect to send it out this week (before Christmas) for you to test.
> I guess most of us will have plenty of time to run tests...
>
>> Thanks and best regards!
> Thanks and same to you!
> Nikolaus
>
> PS: we are working on the old jz4730 minibooks (alpha 400, letux 400, razorbook, elonex etc.). We are currently stuck at reading the SD card, but otherwise it already boots quite well.
> So we may need your help and expertise for reviewing the code :)
>

Unfortunately, I am not familiar with JZ4730, and I don't have JZ4730
hardware that can works properly. But I think I can help collect some
source code or documents of JZ4730.

Thanks and best regards!

[H. Nikolaus Schaller]

Hi,

> Am 21.12.2020 um 10:08 schrieb Zhou Yanjie <zhouy...@wanyeetech.com>:
>
> Hi Nikolaus,
>
> On 2020/12/20 下午10:32, H. Nikolaus Schaller wrote:
>> Hi,
>>
>>> Am 20.12.2020 um 15:23 schrieb Zhou Yanjie <zhouy...@wanyeetech.com>:
>>>
>>> Hello Riccardo, Nikolaus, Paul,
>>>
>>> The new SMP patch and cache driver have been completed.
>> Great!
>>
>>> The current test shows that some known instabilities have been resolved,
>> After I disabled the old SMP code a while ago my board did run very stable. I could debootstrap ca. 5 different user-space images.
>> It did freeze only once when I accidentially touched the SD card. It seems the SD card reader isn't holding the card very strongly.
>>
>>> and the performance has also been improved (UnixBench score improved by more than 10%).
>> Great!
>>
>>> I am currently in the final round of testing. I expect to send it out this week (before Christmas) for you to test.
>> I guess most of us will have plenty of time to run tests...
>>
>>> Thanks and best regards!
>> Thanks and same to you!
>> Nikolaus
>>
>> PS: we are working on the old jz4730 minibooks (alpha 400, letux 400, razorbook, elonex etc.). We are currently stuck at reading the SD card, but otherwise it already boots quite well.
>> So we may need your help and expertise for reviewing the code :)
>>
>
> Unfortunately, I am not familiar with JZ4730, and I don't have JZ4730 hardware that can works properly.

Yes, no problem. Where I think you can really help at some point is with structuring the code we need to inject into the existing ingenic code to make it upstream-compatible...

> But I think I can help collect some source code or documents of JZ4730.

We have collected what we could get (u-boot, 2.4 vendor kernel and a working 2.6.24 kernel [1]) and data sheets [2]. The main gap is a complete programming manual which does not seem to exist.
So we are reverse engineering what the 2.4 or the 2.6 kernel or u-boot is doing and try to deduce how to get the 5.10 kernel working (I just managed it to recognise the SD card but the init process is not starting).

>
> Thanks and best regards!

Best regards,
Nikolaus

[1] https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/l400-2.6
[2] https://projects.goldelico.com/p/letux400/doc/
plus

AN4730_001_clock.pdf
AN4730_002_i2s.pdf
JZ4730-datasheet-1.1.pdf
Jz4730_Board_Design Guide_EN.pdf
Jz4730_ds-1.3.pdf
RD4730_PMP-HW 2.2_EN.pdf

[H. Nikolaus Schaller]

Didn't immediately find the download link:

[3] https://download.goldelico.com/letux-400/files/

[Zhou Yanjie]

Hi,

There is good news. I got a complete PM manual, DS manual and hardware
design guide from a friend of Jetronic. I have confirmed with him that
these documents have been released from confidentiality and can be used
freely.

These documents are in the attachment.


Thanks and best regards!

[Paul Boddie]

On Monday, 21 December 2020 10:08:18 CET Zhou Yanjie wrote:
>
> Unfortunately, I am not familiar with JZ4730, and I don't have JZ4730
> hardware that can works properly. But I think I can help collect some
> source code or documents of JZ4730.

I suspect that the JZ4730 might have been the first product to be designed/
delivered in the series, given various differences between that and the
others. The DMA peripheral is simpler, not supporting descriptor-based
transfers, for example. I also suspect that there may not be a programming
manual, or not one in English, that would have been available to developers.

Following on from work done ten years ago (or more), we have been going
through old kernel code and trying to document the hardware:

https://projects.goldelico.com/p/letux400/doc/

On a slightly different topic, I noticed that the XBurst1 and XBurst2 manuals
are now available on Ingenic's FTP site:

ftp://ftp.ingenic.com/SOC/CPU/

This is likely to be particularly helpful, particularly for those people
interested in the instruction set extensions!

Going beyond this, I did investigate the VPU functionality in the JZ4780 a
year or so ago, just gathering details from the MPlayer code that was made
available, but if Ingenic is willing to make any documentation available for
that, it might be useful to anyone thinking of taking that code further.

I imagine that the JZ4780 uses the "Helix" technology supporting H.264 and
other codecs, whereas newer devices use the "Radix" technology supporting H.
265 and so on:

http://www.ingenic.com.cn/en/?vpu.html

Paul

[H. Nikolaus Schaller]

Hi,

> Am 21.12.2020 um 13:07 schrieb Zhou Yanjie <zhouy...@wanyeetech.com>:
>
> Hi,
>
> On 2020/12/21 下午5:58, H. Nikolaus Schaller wrote:
>> Hi,
>
>

> There is good news. I got a complete PM manual, DS manual and hardware design guide from a friend of Jetronic. I have confirmed with him that these documents have been released from confidentiality and can be used freely.
>
> These documents are in the attachment.
>
>
> Thanks and best regards!

> <JZ4730 PM.zip>

^^^ this is what we have been looking for for years!!! (the other two we had already collected).

Great Xmas present :) There are for example DMAC register descriptions...

BR and thanks,
Nikolaus

[Riccardo Mottola]

Hello!

Zhou Yanjie wrote:
>
> The new SMP patch and cache driver have been completed. The current
> test shows that some known instabilities have been resolved, and the
> performance has also been improved (UnixBench score improved by more
> than 10%). I am currently in the final round of testing. I expect to
> send it out this week (before Christmas) for you to test.

that sounds like good news!
As soon as Nikolaus will make me a new kernel available, I will update
and test it, hoping to be a good one.

I will test compilation and using git, exactly as previously.
Unfortunately Arctic Fox compilation is broken again on MIPS, but maybe
I am able to fix again it during this Christmas Season!
Best would be of course to have it running and not just compiling :)

I will try also GNUstep again, which did compile but crash. Lots of
stress test then.

Riccardo

[Paul Boddie]

On Monday, 21 December 2020 13:07:55 CET Zhou Yanjie wrote:
>
> There is good news. I got a complete PM manual, DS manual and hardware
> design guide from a friend of Jetronic. I have confirmed with him that
> these documents have been released from confidentiality and can be used
> freely.
>
> These documents are in the attachment.

Many, many thanks for sending these, particularly the programming manual! I
have updated the documentation that we were maintaining to include some of the
missing details, and there are some small mysteries that can now be resolved.

https://projects.goldelico.com/p/letux400/doc/

There are some new mysteries that arise, however. For instance, the old Linux
sources use a table to configure the LCD controller frequency whereas the
manual indicates a linear scale for the appropriate register field. Using a
table hasn't impacted anything I have done or used, but maybe this has an
impact on the work we are currently doing.

Thanks once again and, given the day (here, we have less than six hours of
daylight), Happy Midwinter! :-)

Paul

P.S. Happy Midsummer for any Southern Hemisphere readers!

[Zhou Yanjie]

Hi Paul,

Thanks, we call this day (December 21) the Winter Solstice Festival,
which is a solar term in the "Twenty-Four Solar Terms" of Chinese
traditional culture. It originated in the Zhou Dynasty and was regarded
as a festival during the Han Dynasty. People usually eat dumplings on
this day.

Friends from Ingenic said that they might be able to find some JZ4730
source codes. I will forward them to you after I receive them. I hope it
can help.


Thanks and best regards!