talos-obmc-linux/drivers/mtd, branch dev-4.10

mtd: spi-nor: aspeed: set 4B setting for all chips

2017-07-25T01:52:13+00:00

The driver made the wrong assumption that the 4B setting was autodetected for all chips of the AST2500 FMC flash controller. This is only the case for the CS0. OpenBMC-Staging-Count: 1 Signed-off-by: Cédric Le Goater Signed-off-by: Joel Stanley

spi-nor: Add Winbond w25m512jv

2017-06-21T05:14:02+00:00

Similar to the other ones, different size. The "JV" suffix is in the datasheet, I haven't seen mentions of a different one. The datasheet indicates DUAL and QUAD are supported. http://www.winbond.com/resource-files/w25m512jv%20revc%2001062017.pdf Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Joel Stanley Signed-off-by: Cyrille Pitchen (cherry picked from commit 0cbef932bd82857823c0e52b08218b0c9920a475) Signed-off-by: Joel Stanley

Merge tag 'v4.10.17' into dev-4.10

2017-06-05T02:24:15+00:00

This is the 4.10.17 stable release

spi-nor: aspeed-smc: Fix flash window size message

2017-05-24T01:16:37+00:00

When booting we see something like this: aspeed-smc 1e620000.flash-controller: Using IRQ 17 aspeed-smc 1e620000.flash-controller: DMA support disabled. aspeed-smc 1e620000.flash-controller: mx25l25635e (32768 Kbytes) aspeed-smc 1e620000.flash-controller: CE0 window [ 0x20000000- 0x22000000 ] 32MB aspeed-smc 1e620000.flash-controller: CE1 window [ 0x22000000- 0x2a000000 ] 128MB The lack of space after the first hex number haunts me every time I boot a BMC. With this fix we see the pleasingly symmetrical: aspeed-smc 1e620000.flash-controller: CE0 window [ 0x20000000 - 0x22000000 ] 32MB aspeed-smc 1e620000.flash-controller: CE1 window [ 0x22000000 - 0x2a000000 ] 128MB Acked-by: Cédric Le Goater Reviewed-by: Andrew Jeffery Signed-off-by: Joel Stanley

mtd: nand: Add OX820 NAND hardware dependency

2017-05-14T12:08:19+00:00

commit de0b34455afd1204a3644c9eb25b0b3b0aeb2fe9 upstream. The oxnas NAND driver is only needed for a specific platform, do not propose it on other platforms unless build-testing. Signed-off-by: Jean Delvare Fixes: 668592492409 ("mtd: nand: Add OX820 NAND Support") Cc: Rob Herring Cc: Neil Armstrong Cc: Boris Brezillon Cc: Richard Weinberger Cc: David Woodhouse Cc: Brian Norris Cc: Marek Vasut Cc: Cyrille Pitchen Acked-by: Marek Vasut Acked-by: Neil Armstrong Signed-off-by: Boris Brezillon Signed-off-by: Greg Kroah-Hartman

ubi/upd: Always flush after prepared for an update

2017-04-27T07:12:59+00:00

commit 9cd9a21ce070be8a918ffd3381468315a7a76ba6 upstream. In commit 6afaf8a484cb ("UBI: flush wl before clearing update marker") I managed to trigger and fix a similar bug. Now here is another version of which I assumed it wouldn't matter back then but it turns out UBI has a check for it and will error out like this: |ubi0 warning: validate_vid_hdr: inconsistent used_ebs |ubi0 error: validate_vid_hdr: inconsistent VID header at PEB 592 All you need to trigger this is? "ubiupdatevol /dev/ubi0_0 file" + a powercut in the middle of the operation. ubi_start_update() sets the update-marker and puts all EBs on the erase list. After that userland can proceed to write new data while the old EB aren't erased completely. A powercut at this point is usually not that much of a tragedy. UBI won't give read access to the static volume because it has the update marker. It will most likely set the corrupted flag because it misses some EBs. So we are all good. Unless the size of the image that has been written differs from the old image in the magnitude of at least one EB. In that case UBI will find two different values for `used_ebs' and refuse to attach the image with the error message mentioned above. So in order not to get in the situation, the patch will ensure that we wait until everything is removed before it tries to write any data. The alternative would be to detect such a case and remove all EBs at the attached time after we processed the volume-table and see the update-marker set. The patch looks bigger and I doubt it is worth it since usually the write() will wait from time to time for a new EB since usually there not that many spare EB that can be used. Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman

mtd: spi-nor: aspeed: optimize read mode

2017-03-28T09:27:09+00:00

This is only for SPI controllers as U-Boot should have done it already for the FMC controller using DMAs. The algo is based on the one found in the OpenPOWER pflash tool. It first reads a golden buffer at low speed and then performs reads with different clocks and delay cycles settings to find the fastest configuration for the chip. It can be deactivated at boot time with the kernel parameter : aspeed_smc.optimize_read=0 OpenBMC-Staging-Count: 1 Signed-off-by: Cédric Le Goater Signed-off-by: Joel Stanley

mtd: spi-nor: aspeed: link controller with the ahb clock

2017-03-28T09:27:04+00:00

We will need the AHB frequency to set the HCLK settings in the SMC controller to optimize the reads. OpenBMC-Staging-Count: 1 Signed-off-by: Cédric Le Goater Signed-off-by: Joel Stanley

mtd: spi-nor: aspeed: use command mode for reads

2017-03-28T09:26:56+00:00

When reading flash contents, try to use the "command mode" if the AHB window configured for the flash module is big enough. Else, just fall back to the "user mode" to perform the read. OpenBMC-Staging-Count: 1 Signed-off-by: Cédric Le Goater Signed-off-by: Joel Stanley

mtd: spi-nor: aspeed: configure chip window on AHB bus

2017-03-28T09:26:42+00:00

The segment registers of the SMC controller provide a way to configure the mapping windows of the chips on the AHB bus. The settings are required to be correct when the controller operates in Command mode, which is the case for DMAs and the LPC mapping. This tries to set the segment registers of each chip depending on the size of the flash device and depending on the previous segment settings, in order to have a contiguous window across multiple chip. Unfortunately, the AST2500 SPI controller has a bug and it is not possible to configure a full 128MB window for a chip of the same size. The window size needs to be restricted to 120MB. This issue only applies to CE0. Sample kernel dmesg on a Witherspoon : aspeed-smc 1e620000.flash-controller: Using IRQ 17 aspeed-smc 1e620000.flash-controller: DMA support disabled. aspeed-smc 1e620000.flash-controller: mx25l25635e (32768 Kbytes) aspeed-smc 1e620000.flash-controller: CE0 window [ 0x20000000- 0x22000000 ] 32MB aspeed-smc 1e620000.flash-controller: CE1 window [ 0x22000000- 0x2a000000 ] 128MB 5 ofpart partitions found on MTD device bmc Creating 5 MTD partitions on "bmc": 0x000000000000-0x000000060000 : "u-boot" 0x000000060000-0x000000080000 : "u-boot-env" 0x000000080000-0x0000004c0000 : "kernel" 0x0000004c0000-0x000001c00000 : "rofs" 0x000001c00000-0x000002000000 : "rwfs" aspeed-smc 1e620000.flash-controller: mx25l25635e (32768 Kbytes) aspeed-smc 1e620000.flash-controller: CE1 window [ 0x22000000- 0x24000000 ] 32MB aspeed-smc 1e620000.flash-controller: CE2 window [ 0x24000000- 0x2c000000 ] 128MB aspeed-smc 1e630000.flash-controller: mx66l1g45g (131072 Kbytes) aspeed-smc 1e630000.flash-controller: CE0 window resized to 120MB (AST2500 HW quirk) aspeed-smc 1e630000.flash-controller: CE0 window [ 0x30000000- 0x37800000 ] 120MB aspeed-smc 1e630000.flash-controller: CE0 window too small for chip 128MB aspeed-smc 1e630000.flash-controller: CE1 window [ 0x37800000- 0x38000000 ] 8MB OpenBMC-Staging-Count: 1 Signed-off-by: Cédric Le Goater Acked-by: Andrew Jeffery Signed-off-by: Joel Stanley