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!
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!
Hi Tomasz,
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!