Hi,
We are testing UBIFS (NOR) on Zynq Ultrascale+ MPSoC GQSPI controller driver.
Apart from my previous mail thread about UBIFS, i.e along with dma issue I am facing one more
Problem related to offsets.
Info about GQSPI Controller:
This controller can access the flash device in the following modes.
1. Single flash mode
2. Two spi flash memories with separate buses (dual parallel)
Single flash mode: it is normal configuration, one controller and one flash memory
In dual parallel mode following are the functionalities:
1) Supporting two SPI flash memories operating in parallel. 8 I/O lines.
2) Chip selects and clock are shared to both the flash devices
3) This mode is targeted for faster read/write speed and also doubles the size
4) Commands/data can be transmitted/received from both the devices(mirror), or only upper or only lower flash memory devices.
5) Data arrangement:
??? With stripe (controller configuration) enabled,
??? Even bytes i.e. 0, 2, 4,... are transmitted on Lower Data Bus
??? Odd bytes i.e. 1, 3, 5,.. are transmitted on Upper Data Bus.
Kernel version : 4.4.0
Controller limitation: ZynqMP gqspi controller supports only even addresses when two flash devices are connected (dual parallel mode).
Issue I am facing:
-> Since our controller supports even addresses in dual parallel mode
We are seeing issues with ubifs in dual parallel mode and jffs2 is working fine and we observed the following:
IN dual parallel mode, the Erase block size was 128KiB whereas single flash mode the Erase block size was 64KiB.
In single flash mode, we are getting pnode_sz value as 16 and for dual parallel mode we are getting an odd value 17
And ltab_sz value in single mode as 12 and in dual parallel mode as 11.
Because of these odd values, check_lpt_type offset argument is odd address and hence lpt_type error.
When I ran the mnt command, I am getting the following error
"UBIFS error (ubi0:0 pid 1882): check_lpt_type: invalid type (4) in LPT node type 2"
Ran the below commands:
a)ubiformat /dev/mtd0 -e 0 -y
b)ubiattach -p /dev/mtd0
c)ubimkvol -N data -m /dev/ubi0
d)mount -t ubifs ubi0:data /mnt
So for temporary hack we did the following change
In fs/ubifs/lpt.c
In do_calc_lpt_geom(), added the following
+?????? if (c->pnode_sz % 2)
+?????????????? c->pnode_sz += 1;
+?????? if (c->ltab_sz % 2)
+?????????????? c->ltab_sz += 1;
Please kindly suggest, I need your inputs, changing the pnode_sz and ltab_sz to even in lpt.c, will it impact on any others?
We can do the same change in spi layer (change the address to even) but the above properties won't reflect in ubi layer.
Kindly please suggest.
If I haven't provided sufficient information, please let me know.
Thanks,
Naga Sureshkumar Relli
Naga Sureshkumar Relli,
On 25.10.2016 08:05, Naga Sureshkumar Relli wrote:
> Hi,
>
> We are testing UBIFS (NOR) on Zynq Ultrascale+ MPSoC GQSPI controller driver.
> Apart from my previous mail thread about UBIFS, i.e along with dma issue I am facing one more
> Problem related to offsets.
>
> Info about GQSPI Controller:
> This controller can access the flash device in the following modes.
> 1. Single flash mode
> 2. Two spi flash memories with separate buses (dual parallel)
>
> Single flash mode: it is normal configuration, one controller and one flash memory
>
> In dual parallel mode following are the functionalities:
> 1) Supporting two SPI flash memories operating in parallel. 8 I/O lines.
> 2) Chip selects and clock are shared to both the flash devices
> 3) This mode is targeted for faster read/write speed and also doubles the size
> 4) Commands/data can be transmitted/received from both the devices(mirror), or only upper or only lower flash memory devices.
> 5) Data arrangement:
> With stripe (controller configuration) enabled,
> Even bytes i.e. 0, 2, 4,... are transmitted on Lower Data Bus
> Odd bytes i.e. 1, 3, 5,.. are transmitted on Upper Data Bus.
But these details are hidden from UBI?
> Kernel version : 4.4.0
> Controller limitation: ZynqMP gqspi controller supports only even addresses when two flash devices are connected (dual parallel mode).
>
> Issue I am facing:
> -> Since our controller supports even addresses in dual parallel mode
> We are seeing issues with ubifs in dual parallel mode and jffs2 is working fine and we observed the following:
>
> IN dual parallel mode, the Erase block size was 128KiB whereas single flash mode the Erase block size was 64KiB.
> In single flash mode, we are getting pnode_sz value as 16 and for dual parallel mode we are getting an odd value 17
> And ltab_sz value in single mode as 12 and in dual parallel mode as 11.
> Because of these odd values, check_lpt_type offset argument is odd address and hence lpt_type error.
>
> When I ran the mnt command, I am getting the following error
> "UBIFS error (ubi0:0 pid 1882): check_lpt_type: invalid type (4) in LPT node type 2"
> Ran the below commands:
> a)ubiformat /dev/mtd0 -e 0 -y
> b)ubiattach -p /dev/mtd0
> c)ubimkvol -N data -m /dev/ubi0
> d)mount -t ubifs ubi0:data /mnt
>
> So for temporary hack we did the following change
> In fs/ubifs/lpt.c
> In do_calc_lpt_geom(), added the following
> + if (c->pnode_sz % 2)
> + c->pnode_sz += 1;
> + if (c->ltab_sz % 2)
> + c->ltab_sz += 1;
>
> Please kindly suggest, I need your inputs, changing the pnode_sz and ltab_sz to even in lpt.c, will it impact on any others?
Hmm, the calculations in lpt.c use basic properties of the MTD (number of blocks, etc...).
Can you please double check which property causes the failure and also verify whether the MTD driver
provides correct properties. i.e. page sizes, block size, number of blocks, ...
Thanks,
//richard
Hi Richard,
-----Original Message-----
From: Richard Weinberger [mailto:[email protected]]
Sent: Wednesday, October 26, 2016 2:44 AM
To: Naga Sureshkumar Relli <[email protected]>; Christoph Hellwig <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Punnaiah Choudary Kalluri <[email protected]>; [email protected]; [email protected]; Boris Brezillon <[email protected]>
Subject: Re: UBIFS LEB properties tree with odd addresses
Naga Sureshkumar Relli,
> Even bytes i.e. 0, 2, 4,... are transmitted on Lower Data Bus
> Odd bytes i.e. 1, 3, 5,.. are transmitted on Upper Data Bus.
> But these details are hidden from UBI?
Yes, Our controller driver will take care of these byte striping.
> So for temporary hack we did the following change In fs/ubifs/lpt.c In
> do_calc_lpt_geom(), added the following
> + if (c->pnode_sz % 2)
> + c->pnode_sz += 1;
> + if (c->ltab_sz % 2)
> + c->ltab_sz += 1;
>
> Please kindly suggest, I need your inputs, changing the pnode_sz and ltab_sz to even in lpt.c, will it impact on any others?
> Hmm, the calculations in lpt.c use basic properties of the MTD (number of blocks, etc...).
> Can you please double check which property causes the failure and also verify whether the MTD driver provides correct properties. i.e. page sizes, block size, number of blocks, ...
Yes, only pnode_sz and ltab_sz are odd values
And MTD info, here are my logs
In Single Flash mode:
Mtd->erasesize = 64KiB
Mtd->size = 64MiB
Mtd->numeraseregions = 0
Nor->pagesize = 256
In Dual parallel mode:
Mtd->erasesize = 128KiB
Mtd->size = 128MiB
Mtd->numeraseregions = 0
Nor->pagesize = 512
Thanks,
Naga Sureshkumar Relli
Naga Sureshkumar Relli,
On 26.10.2016 14:11, Naga Sureshkumar Relli wrote:
> Hi Richard,
>
> -----Original Message-----
> From: Richard Weinberger [mailto:[email protected]]
> Sent: Wednesday, October 26, 2016 2:44 AM
> To: Naga Sureshkumar Relli <[email protected]>; Christoph Hellwig <[email protected]>
> Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Punnaiah Choudary Kalluri <[email protected]>; [email protected]; [email protected]; Boris Brezillon <[email protected]>
> Subject: Re: UBIFS LEB properties tree with odd addresses
>
> Naga Sureshkumar Relli,
>> Even bytes i.e. 0, 2, 4,... are transmitted on Lower Data Bus
>> Odd bytes i.e. 1, 3, 5,.. are transmitted on Upper Data Bus.
>
>> But these details are hidden from UBI?
>
> Yes, Our controller driver will take care of these byte striping.
>
>> So for temporary hack we did the following change In fs/ubifs/lpt.c In
>> do_calc_lpt_geom(), added the following
>> + if (c->pnode_sz % 2)
>> + c->pnode_sz += 1;
>> + if (c->ltab_sz % 2)
>> + c->ltab_sz += 1;
>>
>> Please kindly suggest, I need your inputs, changing the pnode_sz and ltab_sz to even in lpt.c, will it impact on any others?
>
>> Hmm, the calculations in lpt.c use basic properties of the MTD (number of blocks, etc...).
>> Can you please double check which property causes the failure and also verify whether the MTD driver provides correct properties. i.e. page sizes, block size, number of blocks, ...
>
> Yes, only pnode_sz and ltab_sz are odd values
Hm, these values depend only on basic MTD prperties AFAICT.
> And MTD info, here are my logs
> In Single Flash mode:
> Mtd->erasesize = 64KiB
> Mtd->size = 64MiB
> Mtd->numeraseregions = 0
> Nor->pagesize = 256
>
> In Dual parallel mode:
> Mtd->erasesize = 128KiB
> Mtd->size = 128MiB
> Mtd->numeraseregions = 0
> Nor->pagesize = 512
How does UBI report them?
Maybe you miss some bit and set incorrect MTD properties.
A 128MiB MTD with 128KiB erase size is nothing special.
Thanks,
//richard
Hi Richard,
>> Hmm, the calculations in lpt.c use basic properties of the MTD (number of blocks, etc...).
>> Can you please double check which property causes the failure and also verify whether the MTD driver provides correct properties. i.e. page sizes, block size, number of blocks, ...
> Hm, these values depend only on basic MTD prperties AFAICT.
> Mtd->numeraseregions = 0
> Nor->pagesize = 512
As per the above query only, I have given the below inputs.
>Maybe you miss some bit and set incorrect MTD properties.
I double checked the MTD properties (as mentioned above) which were causing the failure, but didn't find any clue.
All mtd properties looks good for dual parallel case(there is no odd value).
Is there any impact by putting below logic in do_calc_lpt_geom() ?
If(c->pnode_sz % 2)
c->pnode_sz += 1;
please suggest me to do any further debugging?
Thanks,
Naga Sureshkumar Relli
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
Naga Sureshkumar Relli,
On 03.11.2016 06:11, Naga Sureshkumar Relli wrote:
> Hi Richard,
>
>>> Hmm, the calculations in lpt.c use basic properties of the MTD (number of blocks, etc...).
>>> Can you please double check which property causes the failure and also verify whether the MTD driver provides correct properties. i.e. page sizes, block size, number of blocks, ...
>
>> Hm, these values depend only on basic MTD prperties AFAICT.
>> Mtd->numeraseregions = 0
>> Nor->pagesize = 512
>
> As per the above query only, I have given the below inputs.
>> Maybe you miss some bit and set incorrect MTD properties.
> I double checked the MTD properties (as mentioned above) which were causing the failure, but didn't find any clue.
> All mtd properties looks good for dual parallel case(there is no odd value).
>
> Is there any impact by putting below logic in do_calc_lpt_geom() ?
> If(c->pnode_sz % 2)
> c->pnode_sz += 1;
Yes, we need to understand first what exactly is going on.
> please suggest me to do any further debugging?
Please find the exact MTD property which causes the odd values.
Can you also please share the full kernel log of both cases? (dual and non-dual).
I'm especially interested in the output of UBI.
I have the feeling that we oversee something.
Thanks,
//richard