Re: [PATCH v3 0/2] nvmem: brcm_nvram: use buffered nvram data for cell values

Re: [PATCH v3 0/2] nvmem: brcm_nvram: use buffered nvram data for cell values

[Arınç ÜNAL]

On 7.02.2023 11:42, Willem-Jan de Hoog wrote:
> On OpenWrt 22.03.3, Asus RT-AC88U does not boot anymore:
> 
>    UBI: auto-attach mtd4
>    ubi0: attaching mtd4
>    ubi0 error: 0xc04f0b3c: PEB 0 contains corrupted VID header, and the
>       data does not contain all 0xFF
>    ubi0 error: 0xc04f0b4c: this may be a non-UBI PEB or a severe VID
>       header corruption which requires manual inspection
> 
> The problem seems to be that brcm_nvram_read accesses its (mapped) io
> memory. When doing so the correct data is read but after that the
> mtd/ubi process fails to work.
> 
> The bcm47xx_nvram.c code has buffered the nvram data so the cells value
> can be read from there.
> 
> v3:
> - Export symbol for modules.
> - No dependency on Kconfig.
> 
> v2:
> - Fix the wrong author information.
> 
> v1:
> - arinc.unal: Improved patch subject and log
> 
> Willem-Jan de Hoog (2):
>    The bcm47xx code makes a copy of the NVRAM data in ram. Allow access
>      to this data so property values can be read using nvmem cell api.
>    The bcm47xx module has a copy of the NVRAM data in ram. When available
>      use this one instead of reading from io memory since it causes
>      mtd/ubi to fail.

I believe you're supposed to put the subject of the patches here, keep 
that in mind for future contributions. No need to resubmit as this is 
just composition.

Arınç

Re: [PATCH v3 0/2] nvmem: brcm_nvram: use buffered nvram data for cell values

[Arınç ÜNAL]

Who's going to take this series?

Arınç

Re: [PATCH v3 2/2] nvmem: brcm_nvram: use bcm47xx buffered data

[Rafał Miłecki]

On 7.02.2023 09:42, Willem-Jan de Hoog wrote:
> From: Willem-Jan de Hoog <wdehoog@exalondelft.nl>
> 
> The bcm47xx module has a copy of the NVRAM data in ram. When available, use
> this one instead of reading from io memory since it causes mtd/ubi to fail.

This doesn't explain anything. Why do we need that? If anything we
should rather get rid of that NVRAM firmware driver. It was needed
before we had all NVMEM stuff in place. Finally how can reading
iomem break mtd/ubi?!

It seems like some hack instead of proper fix. Possibly because of lack
of understanding the issue / some subsystem.

Re: [PATCH v3 2/2] nvmem: brcm_nvram: use bcm47xx buffered data

[Arınç ÜNAL]

On 8.02.2023 13:25, Rafał Miłecki wrote:
> On 7.02.2023 09:42, Willem-Jan de Hoog wrote:
>> From: Willem-Jan de Hoog <wdehoog@exalondelft.nl>
>>
>> The bcm47xx module has a copy of the NVRAM data in ram. When 
>> available, use
>> this one instead of reading from io memory since it causes mtd/ubi to 
>> fail.
> 
> This doesn't explain anything. Why do we need that? If anything we
> should rather get rid of that NVRAM firmware driver. It was needed
> before we had all NVMEM stuff in place. Finally how can reading
> iomem break mtd/ubi?!

Did you take a look at the bootlog on this post on the thread, I've 
mentioned your user handle a few times but received no response on the 
forum.

https://forum.openwrt.org/t/asus-rt-ac88u-hw-a6-broken-in-22-03-3/147882/6?u=arinc9

Arınç

Re: [PATCH v3 2/2] nvmem: brcm_nvram: use bcm47xx buffered data

[Rafał Miłecki]

On 8.02.2023 11:29, Arınç ÜNAL wrote:
> On 8.02.2023 13:25, Rafał Miłecki wrote:
>> On 7.02.2023 09:42, Willem-Jan de Hoog wrote:
>>> From: Willem-Jan de Hoog <wdehoog@exalondelft.nl>
>>>
>>> The bcm47xx module has a copy of the NVRAM data in ram. When available, use
>>> this one instead of reading from io memory since it causes mtd/ubi to fail.
>>
>> This doesn't explain anything. Why do we need that? If anything we
>> should rather get rid of that NVRAM firmware driver. It was needed
>> before we had all NVMEM stuff in place. Finally how can reading
>> iomem break mtd/ubi?!
> 
> Did you take a look at the bootlog on this post on the thread, I've mentioned your user handle a few times but received no response on the forum.
> 
> https://forum.openwrt.org/t/asus-rt-ac88u-hw-a6-broken-in-22-03-3/147882/6?u=arinc9

Well, it doesn't really matter *in context* of getting this patch
accepted for mainline. It needs to be properly described on its own so
people can review it without looking through dozens of forum posts.

Sorry for not following that closely, I lagged behind due to my work on
other Broadcom topics. Broken LZMA, broken Linksys device support,
broken BCM5358. I'll see if I can figure out sth from that thread.