sama5d27-som1-ek unable to write to qspi mtd partitions

Moderator: nferre

bmpenrod
Posts: 10
Joined: Wed Feb 07, 2018 9:39 pm

sama5d27-som1-ek unable to write to qspi mtd partitions

Wed Feb 07, 2018 11:13 pm

Using the Linux version 4.9.75-linux4sam_5.7 kernel and device tree blob, and booting everything from the sdcard, I get these messages for some of the drivers:

at91_i2c f8038600.i2c: can't get DMA channel, continue without DMA support
at91_i2c f8038600.i2c: Using FIFO (16 data)

at91_i2c f8038600.i2c: AT91 i2c bus driver (hw version: 0x704).

atmel_spi f8000000.spi: DMA TX channel not available, SPI unable to use DMA
atmel_spi f8000000.spi: Atmel SPI Controller using PIO only
atmel_spi f8000000.spi: Using FIFO (16 data)
atmel_spi f8000000.spi: Atmel SPI Controller version 0x311 at 0xf8000000 (irq 30)
atmel_spi fc018400.spi: DMA TX channel not available, SPI unable to use DMA
atmel_spi fc018400.spi: Atmel SPI Controller using PIO only
atmel_spi fc018400.spi: Using FIFO (16 data)
atmel_spi fc018400.spi: Atmel SPI Controller version 0x311 at 0xfc018400 (irq 179)

at91_i2c f8028000.i2c: can't get DMA channel, continue without DMA support
at91_i2c f8028000.i2c: Using FIFO (16 data)
at24 3-0050: 256 byte 24c02 EEPROM, writable, 8 bytes/write
at91_i2c f8028000.i2c: AT91 i2c bus driver (hw version: 0x704).
at91_i2c fc028000.i2c: can't get DMA channel, continue without DMA support
at91_i2c fc028000.i2c: Using FIFO (16 data)

Are these to be expected?

In addition, from my booted linux I am unable to write to the qspi flash raw mtd partitions on the sama5d27-som module:

atmel_qspi f0024000.spi: sst26vf064b (8192 Kbytes)
5 ofpart partitions found on MTD device f0024000.spi
Creating 5 MTD partitions on "f0024000.spi":
0x000000000000-0x000000010000 : "at91bootstrap"
0x000000010000-0x0000000b0000 : "bootloader"
0x0000000b0000-0x0000000c0000 : "bootloader env"
0x0000000c0000-0x0000000e0000 : "device tree"
0x0000000e0000-0x0000004e0000 : "kernel"

I can read them using my hexeditor and see that they are all erased. But writing something to them using dd doesn't seem to write to them, but the command appears to terminate successfully without any errors or warnings. Shouldn't I be able to do this?

Thanks,
Bruce
bmpenrod
Posts: 10
Joined: Wed Feb 07, 2018 9:39 pm

sama5d27-som1-ek unable to write to qspi mtd partitions

Thu Feb 08, 2018 8:55 pm

Using the Linux version 4.9.75-linux4sam_5.7 kernel and device tree blob, and booting everything from the sdcard, I am unable to write to the qspi flash raw mtd partitions on the sama5d27-som module:

atmel_qspi f0024000.spi: sst26vf064b (8192 Kbytes)
5 ofpart partitions found on MTD device f0024000.spi
Creating 5 MTD partitions on "f0024000.spi":
0x000000000000-0x000000010000 : "at91bootstrap"
0x000000010000-0x0000000b0000 : "bootloader"
0x0000000b0000-0x0000000c0000 : "bootloader env"
0x0000000c0000-0x0000000e0000 : "device tree"
0x0000000e0000-0x0000004e0000 : "kernel"

I can read them using my hexeditor and see that they are all erased. But writing something to them using dd, flashcp or mtd_debug doesn't seem to write to them. Shouldn't I be able to do this?

Thanks,
Bruce
blue_z
Location: USA
Posts: 1590
Joined: Thu Apr 19, 2007 10:15 pm

Re: sama5d27-som1-ek linux kernel dma messages

Thu Feb 08, 2018 9:22 pm

bmpenrod wrote:Using the Linux version 4.9.75-linux4sam_5.7 kernel and device tree blob, ...
That's ambiguous. Did you build this kernel, or did you download a prebuilt image? Which .dtb file?

bmpenrod wrote:I get these messages for some of the drivers:
...
Are these to be expected?
Probably, if the DT has null entries for the DMA.

bmpenrod wrote:I can read them using my hexeditor and see that they are all erased. But writing something to them using dd doesn't seem to write to them, but the command appears to terminate successfully without any errors or warnings. Shouldn't I be able to do this?
First, you're only providing a summary, loaded with your interpretations. The actual commands and the unfiltered results would be more informative.
Second, are you treating this flash as a block device or as a MTD? I.E. study the MTD FAQ, especially the section on "Why do I keep getting errors whenever I try to write to or erase my MTD device?", and the datasheet of the QSPI flash chip regarding device protection.

Regards
bmpenrod
Posts: 10
Joined: Wed Feb 07, 2018 9:39 pm

Re: sama5d27-som1-ek linux kernel dma messages

Thu Feb 08, 2018 10:21 pm

Regarding qspi issue. As shown in my original post, the kernel is quite happily seeing the SST26V064 chip and configuring mtd partitions. I have no problem reading the chip using several different methods. Using up-to-date version 2.0.1 mtd-utils, I cannot write to it using any method, and the flash_unlock command errors on the device:

flash_unlock -i /dev/mtd0
flash_unlock: error!: could not check lock status device: /dev/mtd0

error 95 (Operation not supported)

flash_unlock -u /dev/mtd0
flash_unlock: error!: could not unlock device: /dev/mtd0

error 95 (Operation not supported)

mtd_debug read /dev/mtd0 0 128 testmtd0
Copied 128 bytes from address 0x00000000 in flash to testmtd0

hexedit testmtd0
00000000 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
00000010 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
00000020 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
00000030 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
00000040 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
00000050 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
00000060 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
00000070 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................

flashcp -v /mnt/BOOT.BIN /dev/mtd0
Erasing blocks: 5/5 (100%)
Writing data: 17k/17k (100%)
Verifying data: 10k/17k (57%)File does not seem to match flash data. First mismatch at 0x00000000-0x00002800

mtdinfo /dev/mtd0
mtd0
Name: at91bootstrap
Type: nor
Eraseblock size: 4096 bytes, 4.0 KiB
Amount of eraseblocks: 16 (65536 bytes, 64.0 KiB)
Minimum input/output unit size: 1 byte
Sub-page size: 1 byte
Character device major/minor: 90:0
Bad blocks are allowed: false
Device is writable: true

Looks to me like this device is not supported well in the current linux kernel I downloaded Jan 25th. I haven't tried doing this from u-boot yet because this needs to work for it to be useful in a product where field firmware updates must be supported.

I'd like to hear from anyone who is successfully writing to the qspi flash from user space in the current linux-at91 kernel.

Bruce
bmpenrod
Posts: 10
Joined: Wed Feb 07, 2018 9:39 pm

Re: sama5d27-som1-ek unable to write to qspi mtd partitions

Fri Feb 09, 2018 4:54 am

I reverted back to the original demo linux4sam-poky-sama5d27_som1_ek-5.7.img and was able to write BOOT.BIN to the /dev/mtd0 partition on the qspi flash chip using the flashcp command present in that file system.

I then went back to my kernel and file system and was able to write to the qspi chip too.

I'm guessing that the chip was locked and there is some magic in the demo file system mtd-utils flashcp command that unlocked it, or the demo kernel is slightly different from the one I compiled, which is a little newer. The flash_unlock command still errors when trying to access the lock status of the chip, on either of the two kernel/file system setups, so something is still not quite right.

Bruce
blue_z
Location: USA
Posts: 1590
Joined: Thu Apr 19, 2007 10:15 pm

Re: sama5d27-som1-ek unable to write to qspi mtd partitions

Fri Feb 09, 2018 8:59 pm

As previously mentioned, you should study the datasheet of the QSPI flash chip regarding device protection.
There's mention a of write-protect condition after a power-on reset.

Apparently the Linux4SAM team choose to unlock the chip in U-Boot to relieve Linux of needing an unlock operation for this chip.
But you're doing your unmentioned boot method to circumvent this scheme.

Regards
bmpenrod
Posts: 10
Joined: Wed Feb 07, 2018 9:39 pm

Re: sama5d27-som1-ek unable to write to qspi mtd partitions

Fri Feb 09, 2018 9:22 pm

My boot scheme uses u-boot. Are you saying that u-boot would unlock the chip automatically during it's startup? Or that I would need to perform some command in the u-boot interface to directly unlock the chip before using it?

I think it unwise to require the bootloader to perform this operation in lieu of allowing control in the kernel mtd driver. While searching on this problem, I had even found a patch from Cyril in 2016 that added this unlock feature when he added support for the SST26V chips, but in looking at the current linux-at91 source, it doesn't appear to be there now.

Return to “SAMA5-based”

Who is online

Users browsing this forum: No registered users and 1 guest