On Sun, Oct 1, 2017 at 3:29 AM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > On Wed, Sep 27, 2017 at 07:32:20PM -0400, Nicolas Pitre wrote: >> To distinguish between both access types, the cramfs_physmem filesystem >> type must be specified when using a memory accessible cramfs image, and >> the physaddr argument must provide the actual filesystem image's physical >> memory location. > > Sorry, but this still is a complete no-go. A physical address is not a > proper interface. You still need to have some interface for your NOR nand > or DRAM. - usually that would be a mtd driver, but if you have a good > reason why that's not suitable for you (and please explain it well) > we'll need a little OF or similar layer to bind a thin driver. I don't disagree that we may need DT binding here, but DT bindings are h/w description and not a mechanism bind Linux kernel drivers. It can be a subtle distinction, but it is an important one. I can see the case where we have no driver. For RAM we don't have a driver, yet pretty much all hardware has a DRAM controller which we just rely on the firmware to setup. I could also envision that we have hardware we do need to configure in the kernel. Perhaps the boot settings are not optimal or we want/need to manage the clocks. That seems somewhat unlikely if the kernel is also XIP from the same flash as it is in Nico's case. We do often describe the flash layout in DT when partitions are not discoverable. I don't know if that would be needed here. Would the ROM here ever be updateable from within Linux? If we're talking about a single address to pass the kernel, DT seems like an overkill and kernel cmdline is perfectly valid IMO. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
