ZoomGo ZX10 and OpenWrt

122 views
Skip to first unread message

Tomasz Maciej Nowak

unread,
Jun 18, 2021, 11:52:13 AM6/18/21
to mips-cre...@googlegroups.com
Hi everyone.

First I would like to thank You for keeping the Ingenic SoCs alive in
kernel, without it, this would not be possible.

I write here to announce a support for ZoomGo Media Stick (ZX10) in my fork
of OpenWrt at: https://github.com/tmn505/openwrt/tree/zx10.
For more curious people there is a wiki page set up at:
https://openwrt.org/toh/zoomgo/zx10 and for anyone wishing to buy it,
there are still some offers on eBay.
After community will decide which path to support, I intend to send the
patches upstream, so everyone can get ready-made images and packages
directly from OpenWrt. Until the patches are upstream, I'll occasionally
rebase that branch, anyway that shouldn't be difficult for anyone, since
that code doesn't touch much of shared code.

Now to more technical side of it. The device (FCC: A4XZX10) is a in-car
charger with WiFi file-sharing ability. It is built from two modules, one
consist of charging module (Walmart C0534) presumably made by CE-Link
(probably they also were in charge of producing the whole device), and
second is a "intelligent" module (NW5030) produced by Damai. What is
interesting about the second module, is that it employs Damai DM6291A SoC,
which seems to be Ingenic X1000 IP with 256 MiB LPDDR memory. Unfortunately
the information about this SoC is very scarce, I could only find this:
https://web.archive.org/web/20201027173620/http://www.dmsys.com/portfolio/dm6291a-processor
on now defunct Damai page. The block diagram seems to be indicating that
it's really a X1000, but without datasheet it's just a guess. Has someone
access to datasheet of this SoC and/or can confirm it's same core?
From operation of OpenWrt on this device, nothing is bugging out and system
works properly and stable.

Aside from The SoC identity, has anyone started working on SFC (Serial
Flash Controller) driver for X1000? I found some old code drops from
Ingenic kernel 4.4.x on GitHub, but porting that driver, given my
abilities, is impossible. Would be nice to use some speed-up for NOR flash
operations for this device, since now I use GPIO bit banging to access it.

Thanks and Regards
Tomek

--
TMN

Paul Cercueil

unread,
Jun 25, 2021, 6:30:20 PM6/25/21
to Tomasz Maciej Nowak, mips-cre...@googlegroups.com, Zhou Yanjie
Hi Tomasz,

First time I hear about this Damai DM6271A SoC, but maybe Zhou (in Cc)
can shed some light.

-Paul


Le ven., juin 18 2021 at 17:52:10 +0200, Tomasz Maciej Nowak
<tmn...@gmail.com> a écrit :
> --
> You received this message because you are subscribed to the Google
> Groups "MIPS Creator CI20" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to mips-creator-c...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/mips-creator-ci20/a9fae85f-2da0-7f9d-bd77-7862e0005aac%40gmail.com.


周琰杰

unread,
Jun 26, 2021, 2:28:01 AM6/26/21
to Paul Cercueil, Tomasz Maciej Nowak, mips-cre...@googlegroups.com
Hi Tomasz & Paul,

于 Fri, 25 Jun 2021 23:30:10 +0100
Paul Cercueil <pcer...@gmail.com> 写道:

> Hi Tomasz,
>
> First time I hear about this Damai DM6271A SoC, but maybe Zhou (in
> Cc) can shed some light.
>

I happened to used this processor, Attached is its photo.
In fact, it is exactly the same as the X1000 except for the difference
in memory capacity and the slightly different package size.

The memory capacities of X1000, X1000E, and DM6291A are 32MiB, 64MiB,
and 256MiB. The relationship between them is similar to that of X2000,
X2000E, X2000H (128MiB, 256MiB, 512MiB). The only difference is that
DM6291A is launched by a third-party company, while all three types of
X2000 are directly launched by Ingenic.

In addition, I have the u-boot source code of DM6291A (some codes are
slightly different from X1000), but the quality of the code is
relatively poor. I can provide it to you if you need it.

> > From operation of OpenWrt on this device, nothing is bugging out
> > and system
> > works properly and stable.
> >
> > Aside from The SoC identity, has anyone started working on SFC
> > (Serial Flash Controller) driver for X1000? I found some old code
> > drops from Ingenic kernel 4.4.x on GitHub, but porting that driver,
> > given my abilities, is impossible. Would be nice to use some
> > speed-up for NOR flash
> > operations for this device, since now I use GPIO bit banging to
> > access it.
> >

Ingenic recently announced the kernel code of 5.10 (for X2000 series),
which includes support for SFC (SFC hardware of X2000 has made some
enhancements compared with X1000, but I think that as long as we remove
the new enhancements from SFC driver, theoretically the basic functions
of the driver are backward compatible). I am trying to port it to kernel
5.13, but the progress is very slow. Later I will make a temporary
patch on SFC for people who are interested to study together. I believe
that if we work together, we should be able to speed up the progress.

Thanks and best regards!
1624686976803.jpg

Tomasz Maciej Nowak

unread,
Jun 30, 2021, 12:58:01 PM6/30/21
to 周琰杰, Paul Cercueil, mips-cre...@googlegroups.com
W dniu 26.06.2021 o 08:27, 周琰杰 pisze:
> Hi Tomasz & Paul,

Hi, sorry for late reply and thanks for chiming in.

>
> 于 Fri, 25 Jun 2021 23:30:10 +0100
> Paul Cercueil <pcer...@gmail.com> 写道:
>
>> Hi Tomasz,
>>
>> First time I hear about this Damai DM6271A SoC, but maybe Zhou (in
>> Cc) can shed some light.
>>
>
> I happened to used this processor, Attached is its photo.

And here's a snipet from bootlog:
[ 0.000000] Linux version 5.10.46 (tomek@minix-neo) (mipsel-openwrt-linux-musl-gcc (OpenWrt GCC 8.4.0 r16153+3-fc5b101c06) 8.4.0, GNU ld (GNU Binutils) 2.34) #0 Wed Jun 30 14:00:41 2021
[ 0.000000] CPU0 revision is: 2ed1024f (Ingenic XBurst)
[ 0.000000] FPU revision is: 00330000
That's great. Now I know that what's in upstream kernel is enough for
this SoC to work.

>
> In addition, I have the u-boot source code of DM6291A (some codes are
> slightly different from X1000), but the quality of the code is
> relatively poor. I can provide it to you if you need it.

Fortunately I found some code dumps[1][2] on GitHub with U-Boot for this
device, which was accurate with the U-Boot on the device. I made some
slight functionality changes in my fork[3]. The device is working as an
simple IoT device, so it's not pushed to the limits, but till now it's
stable and nothing bugs out on initialization.

>
>>> From operation of OpenWrt on this device, nothing is bugging out
>>> and system
>>> works properly and stable.
>>>
>>> Aside from The SoC identity, has anyone started working on SFC
>>> (Serial Flash Controller) driver for X1000? I found some old code
>>> drops from Ingenic kernel 4.4.x on GitHub, but porting that driver,
>>> given my abilities, is impossible. Would be nice to use some
>>> speed-up for NOR flash
>>> operations for this device, since now I use GPIO bit banging to
>>> access it.
>>>
>
> Ingenic recently announced the kernel code of 5.10 (for X2000 series),
> which includes support for SFC (SFC hardware of X2000 has made some
> enhancements compared with X1000, but I think that as long as we remove
> the new enhancements from SFC driver, theoretically the basic functions
> of the driver are backward compatible).

That's good news, although it's a pity they don't publish their changes
in a accessible mirror, that would make our life bit easier. But hey,
at the very least it somehow "leaks" sometime[4].

> I am trying to port it to kernel
> 5.13, but the progress is very slow. Later I will make a temporary
> patch on SFC for people who are interested to study together. I believe
> that if we work together, we should be able to speed up the progress.

That would be great, I'm very eager to test it. At some point I tried to
"dumb-port" the driver from the GH code dump[4], but failed miserably.
I first ripped the NAND support from it (ZX10 has NOR flash) and adjusted
to compile with kernel 5.10. It built fine but failed at probing.
Unfortunately I'm not a programmer so I couldn't move forward with that
and given up on it, since the device with my U-Boot fork[3] can boot from
µSD card, which is much faster than booting from bit banged NOR flash.
Anyway, hit me with any patch You've got. I'm also subscribed to
mips-creator-ci20-dev but if it's not sent here or there please Cc me.

>
> Thanks and best regards!
>

Regards

1. https://github.com/tonystark3188/6291/tree/master/uboot
2. https://github.com/lxl1140989/6291-xl/tree/master/uboot
3. https://github.com/tmn505/u-boot/tree/zx10
4. https://github.com/Clemagik/A926/tree/master/kernel-4.4.93

--
TMN

Zhou Yanjie

unread,
Jul 2, 2021, 8:25:49 AM7/2/21
to Tomasz Maciej Nowak, Paul Cercueil, mips-cre...@googlegroups.com

Hi Tomasz & Paul,

At present, I can see the mtd device in /dev, and I used mtd_utils to test, write a image to mtd, and then read this image from mtd, by comparing this image with the original one, the two are exactly the same.

But there are still a few known issues:

1.The original pinctrl driver of sfc is a bit unreasonable. It is necessary to spliting the data, clk, and ce pins into different groups in order to adapt to different pin mapping relationships.

2.At present, it can only read the partitions that have been burned to the flash, but cannot pass the partition information through the device tree.

3.Maybe I missed some menuconfig options, which caused an error when trying to mount mtdblock.

4.For the time being, only support for nor is implemented, but support for nand is still missing.


I think I can complete an initial version of the patch tomorrow, including the modification of pinctrl, the initial sfc support, and the corresponding device tree changes, but the code quality will be relatively poor.


Thanks and best regards!

Tomasz Maciej Nowak

unread,
Jul 4, 2021, 10:14:49 AM7/4/21
to Zhou Yanjie, Paul Cercueil, mips-cre...@googlegroups.com
W dniu 02.07.2021 o 14:25, Zhou Yanjie pisze:
The partitions node should be a child of the flash controller as here
https://github.com/tmn505/openwrt/blob/zx10/target/linux/xburst/dts/zoomgo_zx10.dts#L55

So it should look something like this:

sfc@13440000 {
compatible = "ingenic,sfc";
reg = <0x13440000 0x10000>;
interrupt-parent = <&intc>;
interrupts = <7>;

clocks = <&cgu X1000_CLK_SFC>;
clock-names = "cgu_sfc";

cs-gpios = <&gpa 27 GPIO_ACTIVE_LOW>;
num-cs = <1>;
ingenic,sfc-max-frequency = <150000000>;
ingenic,spiflash_param_offset = <0>;
ingenic,use_board_info = /bits/ 8 <0>;

pinctrl-names = "default";
pinctrl-0 = <&pins_sfc>;

flash@0 {
compatible = "jedec,spi-nor";
reg = <0>;

partitions {
compatible = "fixed,partitions";
#address-cells = <1>;
#size-cells = <1>;

partition@ {
label = "whole-flash";
reg = 0x0000000 0x1000000;
};
};
};
};

>
> 3.Maybe I missed some menuconfig options, which caused an error when trying to mount mtdblock.

These are the symbols I use to access mtd:
CONFIG_MTD=y
CONFIG_MTD_OF_PARTS=y
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_COMPLEX_MAPPINGS=y
CONFIG_MTD_SPI_NOR=y

>
> 4.For the time being, only support for nor is implemented, but support for nand is still missing.

Personally I'm interested in NOR only, so I can live with that :)
At some point if the driver will be upstream, maybe Ingenic engineers
will be interested to add the NAND support themselves.

>
>
> I think I can complete an initial version of the patch tomorrow, including the modification of pinctrl, the initial sfc support, and the corresponding device tree changes, but the code quality will be relatively poor.

I'm not the one to judge, since usually a consumer not a programmer.
--
TMN

Zhou Yanjie

unread,
Jul 4, 2021, 10:52:07 PM7/4/21
to Tomasz Maciej Nowak, Paul Cercueil, mips-cre...@googlegroups.com
Hi
Sure, I will try it.


>> 3.Maybe I missed some menuconfig options, which caused an error when trying to mount mtdblock.
> These are the symbols I use to access mtd:
> CONFIG_MTD=y
> CONFIG_MTD_OF_PARTS=y
> CONFIG_MTD_BLKDEVS=y
> CONFIG_MTD_BLOCK=y
> CONFIG_MTD_COMPLEX_MAPPINGS=y
> CONFIG_MTD_SPI_NOR=y


Looks like I missed "CONFIG_MTD_BLKDEVS=y" and "CONFIG_MTD_BLKDEVS=y"

I will try it later.


>
>> 4.For the time being, only support for nor is implemented, but support for nand is still missing.
> Personally I'm interested in NOR only, so I can live with that :)
> At some point if the driver will be upstream, maybe Ingenic engineers
> will be interested to add the NAND support themselves.


Sure.


>
>>
>> I think I can complete an initial version of the patch tomorrow, including the modification of pinctrl, the initial sfc support, and the corresponding device tree changes, but the code quality will be relatively poor.
> I'm not the one to judge, since usually a consumer not a programmer.


Attached is the patches, based on kernel 5.13, please try it.


Thanks and best regards!
0001-pinctrl-Ingenic-Improve-the-code.patch
0002-temp-init-support-for-sfc.patch

Tomasz Maciej Nowak

unread,
Jul 7, 2021, 10:53:50 AM7/7/21
to Zhou Yanjie, Paul Cercueil, mips-cre...@googlegroups.com
W dniu 05.07.2021 o 04:51, Zhou Yanjie pisze:
> Hi
>

[big snip]
Thank You. I tried them Yesterday, unfortunately when the SFC is
initialized it does not detect the attached NOR flash (full kernel log
in attachment):

[ 0.446616] ingenic-sfc 13440000.sfc: No dts param_offset, use default.
[ 0.448517] ingenic-sfc 13440000.sfc: magic is 0xffffffff version is 0xffffffff
[ 0.450680] WARNING : cannot get nor flash params or partitions !!!
[ 0.451552] ingenic-sfc 13440000.sfc: Failed to match correct nor flash device!

mtdinfo found no devices. When I checked if pins were claimed, none of
the specified ones were, but I guess the driver was unloaded and they
were properly released.

This is what I added to the dts

&sfc {
status = "okay";

ingenic,sfc-max-frequency = <150000000>;
ingenic,use_board_info = /bits/ 8 <0>;

pinctrl-names = "default";
pinctrl-0 = <&pins_sfc>;
};

Can You show Your kernel output when the SFC is initialized?

Additionally my kernel config is attached.

>
>
> Thanks and best regards!
>
>

Regards

kernel.config
sfc.txt

Zhou Yanjie

unread,
Jul 15, 2021, 7:36:54 AM7/15/21
to Tomasz Maciej Nowak, Paul Cercueil, mips-cre...@googlegroups.com

On 2021/7/15 下午6:37, Zhou Yanjie wrote:
> Hi Tomasz,
>
>
> Sorry for the delay, got busy last few days.
> I have encountered this situation. This is because the driver did not
> read the partition information in the specified location of Nor Flash,
> and then did not obtain the partition information through dts (I still
> have not resolved this at present).
>
> The current feasible method is to perform a burn through the cloner
> tool to write the partition information to the specified location
> (used for uboot, kernel, rootfs burn, and it will write the partition
> information to the specified location while burning). The attachment
> is the cloner burning tool and its documentation.
>

It seems that the attachment failed to be sent, I will send you the
cloner tool in other ways later.


>
>>
>> mtdinfo found no devices. When I checked if pins were claimed, none of
>> the specified ones were, but I guess the driver was unloaded and they
>> were properly released.
>>
>> This is what I added to the dts
>>
>> &sfc {
>>    status = "okay";
>>
>>    ingenic,sfc-max-frequency = <150000000>;
>>    ingenic,use_board_info = /bits/ 8 <0>;
>>
>>    pinctrl-names = "default";
>>    pinctrl-0 = <&pins_sfc>;
>> };
>>
>> Can You show Your kernel output when the SFC is initialized?
>
>
> Sure, But now the hardware of X1000 is not by my side, so I need to
> wait a few days to test it. If I remember correctly, it should display
> the start and end addresses of uboot, kernel, rootfs partition in the
> place where the error message is printed in your log.
>
>
> In addition, I checked the link you gave, and I saw that in the
> discussion, some developers mentioned that there is no hardware for
> development and testing. If you need it, I think I can donate some
> development boards to you for free (It is the CU-Neo series that
> appears in the main line). They have a replaceable core board that can
> be replaced with different processors. Currently available core boards
> are based on X1000E and X1830. The core boards based on JZ4775 and
> X2000E/X2000H are under design.
>
>
> Thanks and best regards!

Tomasz Maciej Nowak

unread,
Jul 15, 2021, 1:25:44 PM7/15/21
to Zhou Yanjie, Paul Cercueil, mips-cre...@googlegroups.com
W dniu 15.07.2021 o 13:36, Zhou Yanjie pisze:
>
> On 2021/7/15 下午6:37, Zhou Yanjie wrote:
>> Hi Tomasz,
>>
>>
>> Sorry for the delay, got busy last few days.

No worry, I myself usually write an reply I find the time, that why it's
usually delayed few days.
I didn't know that the driver expects some predefined partition table.
This reminds me a lot of situation with RedBoot based devices, where
partition table resides in specific location on flash then a parser reads
this blob and provides kernel with proper partition table. Kernel has
this parser included in source tree under drivers/mtd/parsers/redboot.c,
so maybe this could be used as some template for Ingenic parser.
Kernel also has some additional parsers i.e. MTD_CMDLINE_PARTS where the
partitions are passed in kernel command line from bootloader (mtdparts).
I'll try to use the mtdparts and see if it'll work.

>>
>> The current feasible method is to perform a burn through the cloner tool to write the partition information to the specified location (used for uboot, kernel, rootfs burn, and it will write the partition information to the specified location while burning).

Thanks for clarification, after You pointed the usage of cloner I found
pointers in U-Boot source[1]. Not sure if I understand it correctly, is
that partition table stored in SPL? The issue with ZX10 is that it has
no boot_sel[n] pins exposed, so to trigger the burner mode I needed to
short data pins on NOR chip, for that the disassembly of the device is
needed. The second issue is to rely on tool provided in binary form
without source available, this could lead to tool requiring some old
distro or Windows to work in the future. The third issue is that, Linux
is usually updated from running system and if the partition layout
changed the partition table would need an update, usage of the cloner
would require assist of a PC. In OpenWrt for RedBoot based devices this
has been solved by an extension to mtd which updates the FIS partition
table with new values on system upgrade. Perhaps it could be a solution
to this issue. The fourth issue is that Damai source is based on some old
Ingenic U-Boot source and I don't know if it'll work with latest cloner.
I'll try do dig in all the source dumps I could find and extract the
Damai changes, and maybe port it to newest Ingenic U-Boot source.

>> The attachment is the cloner burning tool and its documentation.
>>
>
> It seems that the attachment failed to be sent, I will send you the cloner tool in other ways later.

What is the needed version of cloner? The latest I could find is 2.5.0.

>
>
>>
>>>
>>> mtdinfo found no devices. When I checked if pins were claimed, none of
>>> the specified ones were, but I guess the driver was unloaded and they
>>> were properly released.
>>>
>>> This is what I added to the dts
>>>
>>> &sfc {
>>>    status = "okay";
>>>
>>>    ingenic,sfc-max-frequency = <150000000>;
>>>    ingenic,use_board_info = /bits/ 8 <0>;
>>>
>>>    pinctrl-names = "default";
>>>    pinctrl-0 = <&pins_sfc>;
>>> };
>>>
>>> Can You show Your kernel output when the SFC is initialized?
>>
>>
>> Sure, But now the hardware of X1000 is not by my side, so I need to wait a few days to test it. If I remember correctly, it should display the start and end addresses of uboot, kernel, rootfs partition in the place where the error message is printed in your log.

Yeah, that's what I would expect to see if the kernel would see the
partitions.

>>
>>
>> In addition, I checked the link you gave, and I saw that in the discussion, some developers mentioned that there is no hardware for development and testing. If you need it, I think I can donate some development boards to you for free (It is the CU-Neo series that appears in the main line). They have a replaceable core board that can be replaced with different processors. Currently available core boards are based on X1000E and X1830. The core boards based on JZ4775 and X2000E/X2000H are under design.

Thanks, that OpenWrt forum topic[2] is 2 years old and it slowly died
out. Fortunately at least one person (robimarko) is still very much
active, so maybe he would be interested. I can drop a note in that topic
of Your offer if that would be of interest. To be fair adding the
additional devices to xburst target could increase visibility and
interest in these SoCs. I myself am not proficient coder but can easily
add the device to OpenWrt tree from what is upstreamed in kernel and
prepare images for flashing the device, so if that's enough count me in
Your offer.

Regards

1. https://github.com/yongli3/x1000-u-boot/blob/master/arch/mips/include/asm/arch-x1000/sfc.h#L30
2. https://forum.openwrt.org/t/support-for-zoomgo-media-stick/19156

Zhou Yanjie

unread,
Jul 24, 2021, 4:29:17 AM7/24/21
to Tomasz Maciej Nowak, Paul Cercueil, mips-cre...@googlegroups.com

Hi Tomasz,


Sorry, I got acute mumps after a few hours after the the previous email, and am not fully recovered until today.

I am not sure if it is in spl. From the linux driver code, it seems to be the partitioninformation

read from the address 0x3c00 (by calling "ingenic_spi_norflash_read_params()").


no boot_sel[n] pins exposed, so to trigger the burner mode I needed to
short data pins on NOR chip, for that the disassembly of the device is
needed. The second issue is to rely on tool provided in binary form
without source available, this could lead to tool requiring some old
distro or Windows to work in the future. The third issue is that, Linux
is usually updated from running system and if the partition layout
changed the partition table would need an update, usage of the cloner
would require assist of a PC. In OpenWrt for RedBoot based devices this
has been solved by an extension to mtd which updates the FIS partition
table with new values on system upgrade. Perhaps it could be a solution
to this issue. 


I think we can pass partition information through dts, but maybe we have to solve the

problem that mtdblock cannot be mounted before we can further explore.


The fourth issue is that Damai source is based on some old
Ingenic U-Boot source and I don't know if it'll work with latest cloner.
I'll try do dig in all the source dumps I could find and extract the
Damai changes, and maybe port it to newest Ingenic U-Boot source.


I have tried porting uboot to the 2018 version, but it was unsuccessful. It seems that there

is a problem in the spl part that prevents it from starting. I am not very familiar with uboot,

so there is no new progress so far.



The attachment is the cloner burning tool and its documentation.

It seems that the attachment failed to be sent, I will send you the cloner tool in other ways later.
What is the needed version of cloner? The latest I could find is 2.5.0.


I think 2.5.0 is ok, but I have the latest version 2.5.10, I will send it to you later.





          
mtdinfo found no devices. When I checked if pins were claimed, none of
the specified ones were, but I guess the driver was unloaded and they
were properly released.

This is what I added to the dts

&sfc {
   status = "okay";

   ingenic,sfc-max-frequency = <150000000>;
   ingenic,use_board_info = /bits/ 8 <0>;

   pinctrl-names = "default";
   pinctrl-0 = <&pins_sfc>;
};

Can You show Your kernel output when the SFC is initialized?

Sure, But now the hardware of X1000 is not by my side, so I need to wait a few days to test it. If I remember correctly, it should display the start and end addresses of uboot, kernel, rootfs partition in the place where the error message is printed in your log.
Yeah, that's what I would expect to see if the kernel would see the
partitions.


[    0.602935] ingenic-sfc 13440000.sfc: No dts param_offset, use default.
[    0.612976] ingenic-sfc 13440000.sfc: magic is 0x726f6e  version is 0x2
[    0.620082] random: fast init done
[    0.628448] ingenic-sfc 13440000.sfc: nor flash quad mode is set, now use quad mode!
[    0.636987] Creating 3 MTD partitions on "sfc_mtd":
[    0.641907] 0x000000000000-0x000000030000 : "uboot"
[    0.653919] 0x000000030000-0x0000003a0000 : "kernel"
[    0.674684] 0x0000003a0000-0x000001000000 : "rootfs"
[    0.694666] ingenic-sfc 13440000.sfc: SPI NOR MTD LOAD OK


Note the "dts param_offset" in the log, this may be a breakthrough point.

The complete log is in the attachment.




In addition, I checked the link you gave, and I saw that in the discussion, some developers mentioned that there is no hardware for development and testing. If you need it, I think I can donate some development boards to you for free (It is the CU-Neo series that appears in the main line). They have a replaceable core board that can be replaced with different processors. Currently available core boards are based on X1000E and X1830. The core boards based on JZ4775 and X2000E/X2000H are under design.
Thanks, that OpenWrt forum topic[2] is 2 years old and it slowly died
out. Fortunately at least one person (robimarko) is still very much
active, so maybe he would be interested. I can drop a note in that topic
of Your offer if that would be of interest. To be fair adding the
additional devices to xburst target could increase visibility and
interest in these SoCs. I myself am not proficient coder but can easily
add the device to OpenWrt tree from what is upstreamed in kernel and
prepare images for flashing the device, so if that's enough count me in
Your offer.


OK, I will send you the information of these hardwares later, then I would like to

trouble you to contact robimarko to ask for his opinion.


Thanks and best regards!

log.txt

周琰杰

unread,
Jul 24, 2021, 4:41:02 AM7/24/21
to Tomasz Maciej Nowak, Paul Cercueil, mips-creator-ci20

Hi Tomasz,


These are cloner tools and corresponding documents.

Thanks and best regards!


超大附件列表
cloner-2.5.10.5-ubuntu_alpha.tar.gz[99.1MB]
cloner-2.5.10.5-windows_alpha.zip[65.5MB]
USBCloner_the Burntool_documentation.pdf
USBCloner The Burn tool Quick Guide.pdf

Zhou Yanjie

unread,
Mar 29, 2022, 7:40:25 AM3/29/22
to Tomasz Maciej Nowak, Paul Cercueil, mips-cre...@googlegroups.com
Hi Tomasz & Paul,


I have some good news, I have preliminarily completed a new SFC driver
based on the spi-mem framework, this driver can configure the partition
information correctly through the device tree, no need to use the cloner
like the old driver.

The new driver is in the attachment, I have tested it on the CU1000-Neo
board with OpenWRT. Compared with the GPIO simulated driver, this new
driver can shorten the first boot time from nearly 10 minutes to alittle
more than 2 minutes, and the non-first boot time is less than 1 minute.

But because the current driver does not support DMA and poll_status API in
the spi-mem framework, there will be a high CPU usage and a huge amount of
interrupts when performing erase and write operations.

For example, when use "dd if=/dev /zero of=/dev/mtdblock0 count=65536" to
write the mtdblock0 partition (NOR Flash, 32MiB capacity) will generate
about 22 million interrupts, and the CPU usage during the writing period
is close to 90%.

I am now trying to add DMA and poll_status API support to reduce CPU usage
and avoid huge interrupts.

In addition, I encountered a small problem when testing NOR FLASH: I used
two devices: MX25L12835F and MX25L25635F. the MX25L25635F didn't have any
problems, but the JEDEC ID of the MX25L12835F is exactly the same as that
of the MX25L12805D, and the unfortunate thing is the MX25L12805D does not
support QPI mode.

I don't know if there is a way to get the kernel to correctly identify
these two devices. Do you have any good ideas?


Thanks and  beset regards!
spi-ingenic-sfc.c

Paul Cercueil

unread,
Mar 29, 2022, 8:23:16 AM3/29/22
to Zhou Yanjie, Tomasz Maciej Nowak, mips-cre...@googlegroups.com
Hi Zhou,

Driver looks good but I think it's in the wrong subsystem. I would
expect it to register as a MTD device. Did you have a look at
drivers/mtd/spi-nor/controllers/?

About your flash issues, you may need to add an entry in
macronix_spinand_table[] in drivers/mtd/nand/spi/macronix.c.

Cheers,
-Paul

Le mar., mars 29 2022 at 19:40:18 +0800, Zhou Yanjie
<zhouy...@wanyeetech.com> a écrit :

Zhou Yanjie

unread,
Mar 29, 2022, 10:46:30 AM3/29/22
to Paul Cercueil, Tomasz Maciej Nowak, mips-cre...@googlegroups.com
Hi Paul,

On 2022/3/29 下午8:23, Paul Cercueil wrote:
> Hi Zhou,
>
> Driver looks good but I think it's in the wrong subsystem. I would
> expect it to register as a MTD device. Did you have a look at
> drivers/mtd/spi-nor/controllers/?
>

Actually I was confused as to whether this driver should be in MTD subsystem
or SPI subsystem, at first I tended to put it in MTD subsystem, like Ingenic
did in their SDK, but then I read "Documentation/driver-api/mtd/spi-nor.rst"
while researching spi-mem, and according to the information in the text to
find "spi-fsl-qspi.c", then I found that it is placed in the SPI subsystem,
and in the "spi" directory, I also found the "spi-hisi-sfc-v3xx.c" and the
"spi-ti-qspi.c" which also used the spi-mem framework, so I start to think
maybe it should be placed in the SPI subsystem (but I still don't know which
subsystem it should belong to until now).


> About your flash issues, you may need to add an entry in
> macronix_spinand_table[] in drivers/mtd/nand/spi/macronix.c.
>

Okay, I'll go to look and learn what they do. I also have a little
experience
about poll_status, and I am experimenting. The real trouble now is about the
DMA. The DMA of the SFC does not seem to pass the PDMA controller. The DMA
channel used for the SFC cannot be found in the PDMA chapter of the Program
Manual. And I still don't fully understand what the code about the DMA part
of Ingenic's SFC driver is doing.


Thanks and best regards!

Zhou Yanjie

unread,
Apr 7, 2022, 9:47:09 AM4/7/22
to Paul Cercueil, Tomasz Maciej Nowak, mips-cre...@googlegroups.com
Hi Paul & Tomasz,

The attachment is the latest driver, because I am not sure which
subsystem it
should be placed in, I still put it in the SPI subsystem for the time being.

This patch implements the poll status function, when we perform the same
"dd if=/dev /zero of=/dev/mtdblock0 count=65536" operation as before,
the CPU
usage drops from about 90% to about 15%, The number of interrupts generated
dropped from about 22 million to less than 1.4 million.

Right now I'm trying to add DMA support, and I've made some progress, but
there are still a couple of weird issues that need to be fixed. I expect to
finish this work next week.


Thanks and best regards!
0001-mtd-spi-nor-Use-the-spi-mem-poll-status-APIs.patch
0002-SPI-Ingenic-Add-SFC-support-for-Ingenic-SoCs.patch
0003-MIPS-Ingenic-Add-SFC-nodes-for-Ingenic-SoCs-and-boar.patch

Paul Cercueil

unread,
Apr 9, 2022, 6:14:29 AM4/9/22
to Zhou Yanjie, Tomasz Maciej Nowak, mips-cre...@googlegroups.com
Hi Zhou,

Le jeu., avril 7 2022 at 21:47:03 +0800, Zhou Yanjie
<zhouy...@wanyeetech.com> a écrit :
> Hi Paul & Tomasz,
>
> The attachment is the latest driver, because I am not sure which
> subsystem it
> should be placed in, I still put it in the SPI subsystem for the time
> being.

I think you should send a RFC to the MTD mailing list, with a cover
letter with your questions. I am sure they will point you to the right
direction.

Cheers,
-Paul
> --
> You received this message because you are subscribed to the Google
> Groups "MIPS Creator CI20" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to mips-creator-c...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/mips-creator-ci20/0fbb4617-ce25-ada5-c785-cf630afddca4%40wanyeetech.com.


Tomasz Maciej Nowak

unread,
Jun 22, 2022, 3:21:03 PM6/22/22
to Zhou Yanjie, Paul Cercueil, mips-cre...@googlegroups.com
W dniu 7.04.2022 o 15:47, Zhou Yanjie pisze:
> Hi Paul & Tomasz,

Hi, I would like to apologize for lack of response for such long time, sorry.
I started having health issues last Year at the end of July till beginning of
October. That made a lot of work pile up, and only slowly from February this
Year had increasingly free time for hobbies aside from work and personal life.
This weekend I'll go for holidays for one week, but after that I'll try to
promptly response any mail.

> The attachment is the latest driver, because I am not sure which subsystem it
> should be placed in, I still put it in the SPI subsystem for the time being.

That seems sensible, but as Paul mentioned, sending RFC is best option.

> This patch implements the poll status function, when we perform the same
> "dd if=/dev /zero of=/dev/mtdblock0 count=65536" operation as before, the CPU
> usage drops from about 90% to about 15%, The number of interrupts generated
> dropped from about 22 million to less than 1.4 million.

I did only simple tests and with regard to speed, the driver is very good.
The same userspace bootup was only 2 to 3 sec longer when compared to ramfs
image. The whole erase/write cycle of 16MiB NOR flash took close to 2 min,
which is even better than other embedded systems that I have. I updated my
OpenWrt tree fork (https://github.com/tmn505/openwrt/tree/zx10-sfc) with
attached patches plus fixes from Aidan (which he sent upstream).

BTW. When testing the flash speed I accidentally erased bootloader.
Fortunately Ingenic updated their cloner tool on FTP server and I
successfully used the cloner-2.5.24-ubuntu_alpha to write the flash (YAY!
no solder needed). Previously didn't succeed when I used older versions
found on GitHub or the version You sent. For the record I used the
x1000_sfc_nor_16mb.cfg config with small modifications, in case someone
wants the full file please ask, I'll attach it.

> Right now I'm trying to add DMA support, and I've made some progress, but
> there are still a couple of weird issues that need to be fixed. I expect to
> finish this work next week.

Thanks, I just spotted Your GitHub tree with updated driver, will do tests
as soon I'm back from holidays.

> Thanks and best regards!

Best regards, Tomek

[big snip]

--
TMN

Zhou Yanjie

unread,
Jul 13, 2022, 3:04:43 PM7/13/22
to Tomasz Maciej Nowak, Paul Cercueil, mips-cre...@googlegroups.com

Hi Tomasz,

On 2022/6/23 上午3:20, Tomasz Maciej Nowak wrote:
W dniu 7.04.2022 o 15:47, Zhou Yanjie pisze:
Hi Paul & Tomasz,
Hi, I would like to apologize for lack of response for such long time, sorry.
I started having health issues last Year at the end of July till beginning of
October. That made a lot of work pile up, and only slowly from February this 
Year had increasingly free time for hobbies aside from work and personal life.
This weekend I'll go for holidays for one week, but after that I'll try to 
promptly response any mail.


Sorry to hear that, and glad you've recovered.



The attachment is the latest driver, because I am not sure which subsystem it
should be placed in, I still put it in the SPI subsystem for the time being.
That seems sensible, but as Paul mentioned, sending RFC is best option.

This patch implements the poll status function, when we perform the same
"dd if=/dev /zero of=/dev/mtdblock0 count=65536" operation as before, the CPU
usage drops from about 90% to about 15%, The number of interrupts generated
dropped from about 22 million to less than 1.4 million.
I did only simple tests and with regard to speed, the driver is very good.
The same userspace bootup was only 2 to 3 sec longer when compared to ramfs
image. The whole erase/write cycle of 16MiB NOR flash took close to 2 min,
which is even better than other embedded systems that I have. I updated my
OpenWrt tree fork (https://github.com/tmn505/openwrt/tree/zx10-sfc) with
attached patches plus fixes from Aidan (which he sent upstream).

BTW. When testing the flash speed I accidentally erased bootloader.
Fortunately Ingenic updated their cloner tool on FTP server and I
successfully used the cloner-2.5.24-ubuntu_alpha to write the flash (YAY!
no solder needed). Previously didn't succeed when I used older versions
found on GitHub or the version You sent. For the record I used the
x1000_sfc_nor_16mb.cfg config with small modifications, in case someone
wants the full file please ask, I'll attach it.


I am very interested in it :)



      
Right now I'm trying to add DMA support, and I've made some progress, but
there are still a couple of weird issues that need to be fixed. I expect to
finish this work next week.
Thanks, I just spotted Your GitHub tree with updated driver, will do tests
as soon I'm back from holidays.


Now the driver has some updates again, improving performance and fixing some minor bugs.


Thanks and best regards!

spi-ingenic-sfc.c

Tomasz Maciej Nowak

unread,
Jul 23, 2022, 10:39:18 AM7/23/22
to Zhou Yanjie, Paul Cercueil, mips-cre...@googlegroups.com
W dniu 13.07.2022 o 21:04, Zhou Yanjie pisze:
Attached. No fancy changes. I enabled only flashing of bootloader, as that was
the only thing that I needed.

>
>
>>> Right now I'm trying to add DMA support, and I've made some progress, but
>>> there are still a couple of weird issues that need to be fixed. I expect to
>>> finish this work next week.
>> Thanks, I just spotted Your GitHub tree with updated driver, will do tests
>> as soon I'm back from holidays.
>
>
> Now the driver has some updates again, improving performance and fixing some minor bugs.

Thanks, I tested all three iterations and indeed, starting from the 2nd version
where You added DMA support the interrupt usage really dropped. These are the
results when I booted ZX10 from µSD card, where one terminal session was
through serial gadget and second with SSH on WiFi. The file had 16449536 bytes.
The first run is when firmware partition was not erased; second is erase
operation of firmware partition; third is writing file to erased firmware
partition. For last, an interrupt usage summary when everything was done.

v1

root@OpenWrt:/tmp# time mtd write image.img firmware
Unlocking firmware ...

Writing from image.img to firmware ...
real 1m 56.05s
user 0m 0.01s
sys 0m 4.64s
root@OpenWrt:/tmp# time mtd erase firmware
Unlocking firmware ...
Erasing firmware ...
real 1m 17.80s
user 0m 0.00s
sys 0m 0.03s
root@OpenWrt:/tmp# time mtd write image.img firmware
Unlocking firmware ...

Writing from image.img to firmware ...
real 0m 55.95s
user 0m 0.01s
sys 0m 4.62s

Every 2s: cat /proc/interrupts 2022-07-21 12:28:29

CPU0
2: 853495 MIPS 2 SoC intc cascade interrupt
3: 424339 MIPS 3 OST percpu timer
8: 0 TCU 0 TCU0
9: 775237 INTC 7 13440000.spi
10: 32304 INTC 10 13420000.dma-controller
18: 4687 GPIOC 16 brcmf_oob_intr
21: 1322 INTC 21 13500000.usb, 13500000.usb, dwc2_hsotg:usb1
22: 0 GPIOC 21 13450000.mmc cd
32: 0 INTC 32 10003000.rtc
36: 40500 INTC 36 13460000.mmc
37: 757 INTC 37 13450000.mmc
49: 6 INTC 49 ttyS2
ERR: 0


v2

root@OpenWrt:/tmp# time mtd write image.img firmware
Unlocking firmware ...

Writing from image.img to firmware ...
real 1m 53.89s
user 0m 0.01s
sys 0m 2.27s
root@OpenWrt:/tmp# time mtd erase firmware
Unlocking firmware ...
Erasing firmware ...
real 1m 17.80s
user 0m 0.00s
sys 0m 0.02s
root@OpenWrt:/tmp# time mtd write image.img firmware
Unlocking firmware ...

Writing from image.img to firmware ...
real 0m 52.72s
user 0m 0.02s
sys 0m 2.24s

Every 2s: cat /proc/interrupts 2022-07-21 13:13:23

CPU0
2: 471690 MIPS 2 SoC intc cascade interrupt
3: 406740 MIPS 3 OST percpu timer
8: 0 TCU 0 TCU0
9: 389509 INTC 7 13440000.spi
10: 34025 INTC 10 13420000.dma-controller
18: 4811 GPIOC 16 brcmf_oob_intr
21: 1424 INTC 21 13500000.usb, 13500000.usb, dwc2_hsotg:usb1
22: 0 GPIOC 21 13450000.mmc cd
32: 0 INTC 32 10003000.rtc
36: 42374 INTC 36 13460000.mmc
37: 748 INTC 37 13450000.mmc
49: 6 INTC 49 ttyS2
ERR: 0


v3

root@OpenWrt:/tmp# time mtd write image.img firmware
Unlocking firmware ...

Writing from image.img to firmware ...
real 1m 53.96s
user 0m 0.00s
sys 0m 2.39s
root@OpenWrt:/tmp# time mtd erase firmware
Unlocking firmware ...
Erasing firmware ...
real 1m 17.56s
user 0m 0.00s
sys 0m 0.02s
root@OpenWrt:/tmp# time mtd write image.img firmware
Unlocking firmware ...

Writing from image.img to firmware ...
real 0m 53.51s
user 0m 0.00s
sys 0m 2.34s

Every 2s: cat /proc/interrupts 2022-07-21 16:45:18

CPU0
2: 470378 MIPS 2 SoC intc cascade interrupt
3: 399139 MIPS 3 OST percpu timer
8: 0 TCU 0 TCU0
9: 389413 INTC 7 13440000.spi
10: 33470 INTC 10 13420000.dma-controller
18: 4798 GPIOC 16 brcmf_oob_intr
21: 1385 INTC 21 13500000.usb, 13500000.usb, dwc2_hsotg:usb1
22: 0 GPIOC 21 13450000.mmc cd
32: 0 INTC 32 10003000.rtc
36: 41757 INTC 36 13460000.mmc
37: 746 INTC 37 13450000.mmc
49: 6 INTC 49 ttyS2
ERR: 0


What I forgot was checking of data integrity, but today when checking MD5 sum
of both the file and flash, they do match for v3 iteration.

> Thanks and best regards!

Thank You for Cc-ing me on the sent series. I'll add my Tested-by even tough
that's probably not the last version. Will test any new one.

Best regards, Tomek

>>
>> [big snip]
>>

--
TMN
zx10.cfg
Reply all
Reply to author
Forward
0 new messages