[PATCH] arm: dts: Add pnor label for wspoon and romulus

Cédric Le Goater clg at kaod.org
Mon Nov 14 23:29:52 AEDT 2016


On 11/14/2016 06:21 AM, Joel Stanley wrote:
> On Fri, Nov 11, 2016 at 6:32 PM, Cédric Le Goater <clg at kaod.org> wrote:
>> So, according to :
>>
>>         Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
>>         Documentation/devicetree/bindings/mtd/partitions.txt
>>
>> we can not label the flash module node but we can label the
>> partition instead. Would a patch like below fit the need ?
>> Here is what we get on a palmetto and an EVB, the approach
>> are different.
> 
> Okay. That's annoying.
> 
> Is there a reason we can't coax the ast2400 version to call it just
> 'pnor' as well?

none. that was a proposal for different solutions.

>>
>>         root at palmetto:~# cat /proc/mtd
>>         dev:    size   erasesize  name
>>         mtd0: 00060000 00001000 "u-boot"
>>         mtd1: 00020000 00001000 "u-boot-env"
>>         mtd2: 00280000 00001000 "kernel"
>>         mtd3: 001c0000 00001000 "initramfs"
>>         mtd4: 01740000 00001000 "rofs"
>>         mtd5: 00400000 00001000 "rwfs"
>>         mtd6: 02000000 00010000 "1e630000.spi:pnor at 0"

we can do a strstr when parsing /proc/mtd. This is probably the 
best solution to simply handle compatibility.

>>         root at evb-ast2500:~# cat /proc/mtd
>>         dev:    size   erasesize  name
>>         mtd0: 00060000 00001000 "u-boot"
>>         mtd1: 00020000 00001000 "u-boot-env"
>>         mtd2: 00280000 00001000 "kernel"
>>         mtd3: 001c0000 00001000 "initramfs"
>>         mtd4: 01740000 00001000 "rofs"
>>         mtd5: 00400000 00001000 "rwfs"
>>         mtd6: 02000000 00010000 "pnor"

The problem here is that we need to know the size of the pnor ... 

>>
>> The partition definitions probably belongs to the machine dts.
>>
>> And a udev rules would also fit the purpose I think.
> 
> What would you suggest? A symlink to create a /dev/pnor node?

yes. like we did for the vuart. we will need to find a udev 
attribute for it. I think this is the cleanest. 

Cheers,

C. 


> 
> Cheers,
> 
> Joel
> 



More information about the openbmc mailing list