Hi, > > You get twice more capacity based on that configuration. I can't answer the > > second question because not working with field. But both of that configurations > > are used by customers. Adding Neal if he wants to add something more to it. > > Just to add a comment as I work directly with our customers. The main reason > this support is important is for our older SoCs, zynq and zynqmp. > > Most of our customers are using QSPI flash as the first boot memory to get > from the boot ROM to u-boot. They then typically use other memories, such as > eMMC for the Linux kernel, OS and file system. Agreed and that's probably the most prominent use case for NOR flashes anyway. > The issue we have on the zynq and zynqmp SoCs is that the boot ROM (code that > cannot be changed) will not boot from an OSPI flash. It will only boot from a > QSPI flash. This is what is forcing many of our customers down the QSPI path. > Since many of these customers are interested in additional speed and memory > size, they then end up using a parallel or stacked configuration because they > cannot use an OSPI with zynq or zynqmp. Above you've said, the bootloader is stored on the NOR flash and the bulk storage is eMMC. So why do you need bigger NOR flashes (where even the biggest NOR flash isn't enough)? I also don't understand "the boot ROM will just boot from QSPI". First, you cannot connect an octal flash anyway, because you only have an QSPI controller, right? Secondly, normally the bootrom will (at least) boot the first stage using normal (single line) SPI commands. Is that not the case for zynq and zynqmp? > All of our newer SoCs can boot from OSPI. I agree with you that if someone > could choose OSPI for performance, they would, so I do not expect parallel or > stacked configurations with our newer SoCs. Ok, but then the argument with bigger flashes are void, because you are back to be bound to one OSPI flash. > I get why you see this configuration as a niche, but for us, it is a very > large niche because zynq and zynqmp are two of our most successful SoC > families. Fair enough. But please find a way to support it without butchering the whole core. -michael
Attachment:
signature.asc
Description: PGP signature
