> The flash chip in question is the one used to boot the host (OpenPOWER P8), > not the BMC (ASpeed AST2400). U-boot on AST2400 has nothing to do with > the chip. yes. The Aspeed SoCs has multiple SMC Controllers. On the AST2400, the first SMC controller (called FMC) is for the BMC Firmware and supports SPI, NOR, NAND flash devices. The second is a SPI only controller for the host Firmware. In the OpenBMC terminology, the flash device holding the host Firmware is referred as the "PNOR" ... On the AST2500, the FMC controller supports SPI and NOR flash devices. There are two other controllers supporting only SPI, the first is used for the host Firmware. OpenPOWER platforms using the AST2500 don't have the problem because the flash content is accessed differently from the host. [ ... ] > I start thinking about maybe adding an option to "jedec,spi-nor" DTS > binding like "enable-4byte-mode", so that we could get rid of our local > patch and just specify that option in the devicetree. The option would > force EN4B on the chip if it supports that mode. What do you think? Are you proposing to add an extra property that would be handled at the spi-nor level to choose which set of SPI commands should be the default read_opcode ? either the ones requiring EN4B (SPINOR_OP_READ*) or the others which would not (SPINOR_OP_READ*_4B) ? I think it would be better to introduce the property in the aspeed-smc driver because this is very specific usage of the Aspeed SoC done by a platform. and/or, maybe, introduce a new SNOR_HWCAPS to inform spi_nor_scan() that some driver we doesn't want the SPI_NOR_4B_OPCODES ? > How do I do it if you approve? Send patches separately in here and in > the devicetree mailing list or cross-post both patches to both lists? You need to send a patch to both mailing lists, openbmc@ and linux-mtd@ Thanks, C. ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/