[OpenWrt-Devel] [PATCH] kernel: tolerate using UBI/UBIFS on MLC flash (FS#1830)

Christian Lamparter chunkeey at gmail.com
Tue Oct 23 11:41:27 EDT 2018


On Tuesday, October 23, 2018 2:37:16 PM CEST Koen Vandeputte wrote:
> 
> On 22.10.18 19:27, Christian Lamparter wrote:
> > On Monday, October 22, 2018 3:48:29 PM CEST Koen Vandeputte wrote:
> >> On 20.10.18 17:46, Hauke Mehrtens wrote:
> >>> On 10/18/2018 02:28 PM, Koen Vandeputte wrote:
> >>>> starting from upstream commit 577b4eb23811 ("ubi: Reject MLC NAND")
> >>>> it is not allowed to use UBI and UBIFS on a MLC flavoured NAND flash chip. [1]
> >>>>
> >>>> According to David Oberhollenzer [2]:
> >>>>
> >>>> The real problem is that on MLC NAND, pages come in pairs.
> >>>>
> >>>> Multiple voltage levels inside a single, physical memory cell are used to
> >>>> encode more than one bit. Instead of just having pages that are twice as big,
> >>>> the flash exposes them as *two different pages*. Those pages are usually not
> >>>> ordered sequentially either, but according to a vendor/device specific
> >>>> pairing scheme.
> >>>>
> >>>> Within OpenWrt, devices utilizing this type of flash,
> >>>> combined with ubi(fs) will be bricked when a user upgrades
> >>>> from 17.01.4 to a newer version as the MLC will be refused.
> >>>>
> >>>> As these devices are currently advertised as supported by OpenWrt,
> >>>> we should at least maintain the original state during the lifecycle
> >>>> of the current releases.
> >>>>
> >>>> Support can be gracefully ended when a new release-branch is created.
> >>>>
> >>>> Signed-off-by: Koen Vandeputte <koen.vandeputte at ncentric.com>
> >>>>
> >>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v4.14.77&id=577b4eb23811dfc8e38924dc476dbc866be74253
> >>>> [2] https://lore.kernel.org/patchwork/patch/920344/
> >>>> ---
> >>>>
> >>>> Mainly intended for discussion first on this approach before applying it.
> >>>> Can be cherrypicked to 18.06.
> >>>>
> >>>> Feel free to drop your (n)ack on this approach
> >>> Have you checked if these are really MLC chips or if they are just
> >>> getting detected wrongly?
> >>> I think I saw some SPI NAND chips which a patched Linux detected as MLC
> >>> but the datasheet said they are SLC chips.
> >>>
> >>> Hauke
> >> Very good point.
> >> I've requested Mikrotik this morning to provide some details about the
> >> actual chips being used since the launch of that board ..
> > For the RB450/G you can take a look at the User Guide on their side:
> > <https://mikrotik.com/product/RB450G#fndtn-downloads>
> > <https://i.mt.lv/cdn/rb_files/rb450GugA.pdf>
> >
> > On Page 3 there's a "System Board View" with a bottom view of the PCB
> > and this is where the NAND chip is located. It reads:
> >
> > HY27UT084G2A
> >
> > This translates to:
> > <http://natisbad.org/NAS/refs/Hynix_NAND_flash_part_number_decoding.pdf>
> >
> > HY27UT084G2A
> >    ||||
> >    |||^--- T = MLC + Single Die + Large Block
> >    ||^---U = 2.7V~3.6V
> >    |^---7 = NAND FLASH
> >    ^---2 = FLASH
> >   
> > So, it is NAND MLC FLASH.
> >
> Received a reply from Mikrotik tech dept.:
> 
> 
> Hello,
> 
> Mainly there are two possible NAND chips for RB450G:
> W29N04GVSIAA (see attachment);
> MT29F4G08ABADAWPD.
> 
> Can you provide some device serial numbers?
> 
> 
> Best regards,
> Elans L.
> 
> 
> 
> 
> Checking the datasheets from both chips mentioned above shows they are both SLC flash.
> @Christian, do you have this board?  Could you provide the serial?
No, luckily it isn't one of mine. But Mikrotik want to dig: I do have a serial number
of an affected board: 1DFC018EF642.

I found it on the OpenWrt's Device wiki:
<https://openwrt.org/toh/mikrotik/rb450g?s[]=rb450g#photos>

And interestingly enough, there's also a 


 . You can find this one on the OpenWrt WIKI


> 
> 
> Thanks,
> 
> Koen
> 
> 

 



_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel



More information about the openwrt-devel mailing list