Re: [U-Boot] [PATCH v3 0/7] tegra: Add NAND flash support
On Tue, Apr 17, 2012 at 11:38 AM, Simon Glass wrote: > This series adds NAND flash support to Tegra and enables it on Seaboard. Sorry, please ignore this email, will re-issue. - Simon > > Included here is a proposed device tree binding with most of the properties > private to "nvidia,". The binding includes information about the NAND > controller as well as the connected NAND device. The Seaboard has a > Hynix HY27UF4G2B. > > The driver supports ECC-based access and uses DMA and NAND acceleration > features of the Tegra SOC to provide access at reasonable speed. > > Changes in v2: > - Add new patch to align default buffers in nand_base > - Added comment about the behaviour of the 'resp' register > - Call set_bus_width_page_size() at init to report errors earlier > - Change set_bus_width_page_size() to return an error when needed > - Change timing structure member to u32 to match device tree > - Check for supported bus width in board_nand_init() > - Fix tegra nand header file to remove BIT defines > - Implement a dummy nand_select_chip() instead of nand_hwcontro() > - Make nand_command() display an error on an unknown command > - Minor code tidy-ups in driver for style > - Move cache logic into a separate dma_prepare() function > - Remove CMD_TRANS_SIZE_BYTESx enum > - Remove space after casts > - Remove use of 'register' variables > - Rename struct nand_info to struct nand_drv to avoid nand_info_t confusion > - Support 4096 byte page devices, drop 1024 and 2048 > - Tidy up nand_waitfor_cmd_completion() logic > - Update NAND binding to add "nvidia," prefix > - Use s32 for device tree integer values > > Changes in v3: > - Change note in fdt binding about the need for a hardware-specific binding > - Fix up typos in fdt binding, and rename the file > - Update fdt binding to make everything Nvidia-specific > > Jim Lin (1): > tegra: nand: Add Tegra NAND driver > > Simon Glass (6): > nand: Try to align the default buffers > fdt: Add debugging to fdtdec_get_int/addr() > tegra: Add NAND support to funcmux > tegra: fdt: Add NAND controller binding and definitions > tegra: fdt: Add NAND definitions to fdt > tegra: Enable NAND on Seaboard > > arch/arm/cpu/armv7/tegra2/funcmux.c | 7 + > arch/arm/dts/tegra20.dtsi | 6 + > arch/arm/include/asm/arch-tegra2/funcmux.h | 3 + > arch/arm/include/asm/arch-tegra2/tegra2.h | 1 + > board/nvidia/dts/tegra2-seaboard.dts | 15 + > .../nand/nvidia,tegra20-nand.txt | 61 ++ > drivers/mtd/nand/Makefile | 1 + > drivers/mtd/nand/nand_base.c | 3 +- > drivers/mtd/nand/tegra2_nand.c | 1095 > > drivers/mtd/nand/tegra2_nand.h | 257 + > include/configs/seaboard.h | 9 + > include/fdtdec.h | 1 + > include/linux/mtd/nand.h | 7 +- > lib/fdtdec.c | 23 +- > 14 files changed, 1479 insertions(+), 10 deletions(-) > create mode 100644 doc/device-tree-bindings/nand/nvidia,tegra20-nand.txt > create mode 100644 drivers/mtd/nand/tegra2_nand.c > create mode 100644 drivers/mtd/nand/tegra2_nand.h > > -- > 1.7.7.3 > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/7] tegra: Add NAND flash support
* Simon Glass wrote: > This series adds NAND flash support to Tegra and enables it on Seaboard. > > Included here is a proposed device tree binding with most of the properties > private to "nvidia,". The binding includes information about the NAND > controller as well as the connected NAND device. The Seaboard has a > Hynix HY27UF4G2B. > > The driver supports ECC-based access and uses DMA and NAND acceleration > features of the Tegra SOC to provide access at reasonable speed. I've been working on getting a similar driver up and running in the Linux kernel. While I can successfully read data from the flash (my hardware has the same Hynix chip) I've run into a bit of a problem with the partition tables. When I use nvflash with a given configuration file to write the BCT, the PT and U-Boot to the NAND, I noticed that the partitioning is not quite as it should be. For example I use this: [device] type=nand instance=0 [partition] name=BCT id=2 type=boot_config_table allocation_policy=sequential filesystem_type=basic size=262144 file_system_attribute=0 partition_attribute=0 allocation_attribute=8 percent_reserved=0 [partition] name=PT id=3 type=partition_table allocation_policy=sequential filesystem_type=basic size=262144 file_system_attribute=0 partition_attribute=0 allocation_attribute=8 percent_reserved=0 [partition] name=EBT id=4 type=bootloader allocation_policy=sequential start_location=2097152 filesystem_type=basic size=524288 file_system_attribute=0 partition_attribute=0 allocation_attribute=8 percent_reserved=0 filename=u-boot.bin That however doesn't produce the expected results. Looking at the UART output produced by the bootstrap fastboot.bin it looks like it's actually allocating more blocks than necessary. On the Hynix chip, 256K is 2 blocks, but fastboot.bin seems to want to allocate more: Erase Partition part-id=3: Start=6,End=11 Format partition BCT Erase Partition part-id=2: Start=0,End=5 Format partition EBT Erase Partition part-id=4: Start=12,End=19 On another board things are even worse. It has a bad block, which causes the bootstrap to skip that when allocating the partitions: Erase Partition part-id=3: Start=6,End=12 Factory Bad block: Chip0 Block=8 Runtime Bad block: Chip0 Block=8,RTB=0xed Format partition BCT Erase Partition part-id=2: Start=0,End=5 Format partition EBT Erase Partition part-id=4: Start=13,End=20 Both of these issues lead to the problem that if I encode the same partition information in the DT, the kernel's representation will not match what the nvflash tool did. There seems to be more output during bootstrap that indicates that nvflash does some remapping from logical blocks to physical blocks: PartId 2: LB[0 2] PB[0 6] IL1 LS[0 128] Factory Bad block: Chip0 Block=8 Runtime Bad block: Chip0 Block=8,RTB=0xed Chip0 Block=8 bad PartId 3: LB[2 2] PB[6 7] IL1 LS[128 128] PartId 4: LB[4 4] PB[13 8] IL1 LS[256 256] If we can get at this information (maybe it is stored within the partition table partition?), then it should be possible to use it to automatically build a correct partition table for both U-Boot and the kernel. Anyway, I was wondering how you solved this problem. Or maybe you didn't have the same problem in the first place? Thierry pgpAUUHKsCbC5.pgp Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/7] tegra: Add NAND flash support
On 04/26/2012 04:50 AM, Thierry Reding wrote: > * Simon Glass wrote: >> This series adds NAND flash support to Tegra and enables it on Seaboard. >> >> Included here is a proposed device tree binding with most of the properties >> private to "nvidia,". The binding includes information about the NAND >> controller as well as the connected NAND device. The Seaboard has a >> Hynix HY27UF4G2B. >> >> The driver supports ECC-based access and uses DMA and NAND acceleration >> features of the Tegra SOC to provide access at reasonable speed. > > I've been working on getting a similar driver up and running in the Linux > kernel. While I can successfully read data from the flash (my hardware has > the same Hynix chip) I've run into a bit of a problem with the partition > tables. ... > That however doesn't produce the expected results. Looking at the UART output > produced by the bootstrap fastboot.bin it looks like it's actually allocating > more blocks than necessary. ... > Both of these issues lead to the problem that if I encode the same partition > information in the DT, the kernel's representation will not match what the > nvflash tool did. Yes, I'd recommend not putting information in DT that can be easily extracted from the partition table on the device itself. Out of curiosity though, why do you even need the Tegra PT support; I'd assume in a situation like this, you'd just replace the whole flash with BCT, PT, EBT at once rather than attempting to update just parts of it (since the BCT must be updated when writing a new EBT content anyway), so the existing partition layout wouldn't matter, and the whole device could just be treated raw. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/7] tegra: Add NAND flash support
* Stephen Warren wrote: > Yes, I'd recommend not putting information in DT that can be easily > extracted from the partition table on the device itself. The problem is that neither the format of the BCT nor that of the PT is documented anywhere. It seems like the BCT contains a reference to where in the flash the PT starts but I wasn't able to find out where. Ideally I think we could probably create a separate partition parser, similar to ofpart, that takes the information directly from the PT. Or alternatively it could be extracted manually at probe time to create the partitions in Linux. > Out of curiosity though, why do you even need the Tegra PT support; I'd > assume in a situation like this, you'd just replace the whole flash with > BCT, PT, EBT at once rather than attempting to update just parts of it > (since the BCT must be updated when writing a new EBT content anyway), > so the existing partition layout wouldn't matter, and the whole device > could just be treated raw. Actually I'd need more than those three partitions. I need at least five, optimally six. In addition to BCT, PT and EBT I need one for the uImage and the root filesystem. Those can probably go onto the same partition with JFFS2 or YAFFS. But a fifth will be required to store some other data. If all else fails it could probably be done via the fourth partition as well, but that'd be suboptimal. As I said before, the biggest problem with updating the whole content is that there's no documentation about either the BCT or the PT. There's cbootimage on gitorious that has some information about the BCT, but it's incomplete. For production use it is also impractical to bootstrap using nvflash, boot the system to Linux and create all the partitions as well. If that turns out to be the only option, then better documentation is certainly required. In that case I think it may be possible to not use the PT because the partition layout will actually be deterministic and it can be encoded with DT. Thierry pgpmMc8lk867h.pgp Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/7] tegra: Add NAND flash support
On 04/26/2012 12:32 PM, Thierry Reding wrote: > * Stephen Warren wrote: >> Yes, I'd recommend not putting information in DT that can be easily >> extracted from the partition table on the device itself. > > The problem is that neither the format of the BCT nor that of the PT is > documented anywhere. It seems like the BCT contains a reference to where in > the flash the PT starts but I wasn't able to find out where. I have filed an internal bug to request this information be added to the TRM. We will see what happens. > Actually I'd need more than those three partitions. I need at least five, > optimally six. In addition to BCT, PT and EBT I need one for the uImage and > the root filesystem. Oh I see; you're mingling the boot flash and filesystem into a single memory device. It simpler (but I imagine more costly) not too:-) > As I said before, the biggest problem with updating the whole content is that > there's no documentation about either the BCT or the PT. There's cbootimage > on gitorious that has some information about the BCT, but it's incomplete. Out of curiosity, what's missing from cbootimage? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/7] tegra: Add NAND flash support
* Stephen Warren wrote: > On 04/26/2012 12:32 PM, Thierry Reding wrote: > > The problem is that neither the format of the BCT nor that of the PT is > > documented anywhere. It seems like the BCT contains a reference to where in > > the flash the PT starts but I wasn't able to find out where. > > I have filed an internal bug to request this information be added to the > TRM. We will see what happens. I have filed a similar bug (#976261 in the NVIDIA bug tracker) and Vincent has been informed, so that may help. > > Actually I'd need more than those three partitions. I need at least five, > > optimally six. In addition to BCT, PT and EBT I need one for the uImage and > > the root filesystem. > > Oh I see; you're mingling the boot flash and filesystem into a single > memory device. It simpler (but I imagine more costly) not too:-) Yes, it's all about the money. =) On a more serious note it makes a lot of sense. Firstly we want to use the MMC/SD slot for user storage on Plutux and therefore need to have the OS on internal storage (i.e. NAND). And secondly we build a very minimalistic distribution in-house it fits without a problem. > > As I said before, the biggest problem with updating the whole content is > > that > > there's no documentation about either the BCT or the PT. There's cbootimage > > on gitorious that has some information about the BCT, but it's incomplete. > > Out of curiosity, what's missing from cbootimage? It's missing support for PT. That may not be necessary in a setup where we initialize the NAND from Linux user space, though, so maybe it would be enough. One thing I just remembered which may be a little problem is that currently our boards need to use the L4T binaries for OpenGL ES support, which means they need to run a Chromium kernel and that sadly doesn't properly boot from a mainline U-Boot but requires a setup where we use quickboot as first stage and U-Boot as a second stage bootloader. I haven't had time to investigate this further, though. But having this kind of setup complicates the NAND setup from user space further. The long term plan was to incrementally move to a mainline system by first replacing the QuickBoot/U-Boot combo that we use now with a mainline U-Boot. Most of the pieces for that are now in place. I'm not sure if the SMSC95xx is already supported by U-Boot (we need it to program the MAC address) during bootstrap. Subsequently we were planning to move to a mainline kernel, which is obviously even longer term because it requires the DRM driver to be merged along with an updated user space to take advantage of it. pgpAqcpVLdoos.pgp Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/7] tegra: Add NAND flash support
On 04/26/2012 11:10 PM, Thierry Reding wrote: > * Stephen Warren wrote: >> On 04/26/2012 12:32 PM, Thierry Reding wrote: >>> The problem is that neither the format of the BCT nor that of the PT is >>> documented anywhere. It seems like the BCT contains a reference to where in >>> the flash the PT starts but I wasn't able to find out where. ... >>> As I said before, the biggest problem with updating the whole content is >>> that >>> there's no documentation about either the BCT or the PT. There's cbootimage >>> on gitorious that has some information about the BCT, but it's incomplete. >> >> Out of curiosity, what's missing from cbootimage? > > It's missing support for PT. That may not be necessary in a setup where we > initialize the NAND from Linux user space, though, so maybe it would be > enough. I don't believe the Tegra boot process actually /requires/ the PT even exist. IIRC, the boot ROM searches for the BCT, and the BCT contains a pointer to the bootloader (e.g. U-Boot), so it's only at a later stage in the game that anything would care about the PT. As such, worrying about the PT (or even including it) may be pointless. I believe that TrimSlice's firmware recovery SD card images are created solely using cbootimage, and hence most likely have no PT, although obviously no additional partitions/file-systems on the media. Perhaps you could define some hard-coded "MTD" partitions (e.g. the first 1MB and the rest), where the first 1MB contains BCT + U-Boot and the rest contains a regular MBR or GPT partition table. I /think/ there may even be a kernel command-line option to define the MTD partition layout? Or, you could probably even get away with using a GPT for the entire NAND by placing just the secondary GPT at the end of the NAND, putting the BCT+U-Boot right at the start, and defining a GPT partition to protect/cover BCT+U-Boot. I vaguely recall trying this on some Tegra device, but I may be wrong. Note that while most/all of the suggestions above probably work fine in practice, you should probably run them by your support contacts at NVIDIA in order to determine if we'd actually provide support for any of them and/or whether they negatively interact with the boot ROM in any way. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/7] tegra: Add NAND flash support
* Stephen Warren wrote: > On 04/26/2012 11:10 PM, Thierry Reding wrote: > > * Stephen Warren wrote: > >> On 04/26/2012 12:32 PM, Thierry Reding wrote: > >>> The problem is that neither the format of the BCT nor that of the PT is > >>> documented anywhere. It seems like the BCT contains a reference to where > >>> in > >>> the flash the PT starts but I wasn't able to find out where. > ... > >>> As I said before, the biggest problem with updating the whole content is > >>> that > >>> there's no documentation about either the BCT or the PT. There's > >>> cbootimage > >>> on gitorious that has some information about the BCT, but it's incomplete. > >> > >> Out of curiosity, what's missing from cbootimage? > > > > It's missing support for PT. That may not be necessary in a setup where we > > initialize the NAND from Linux user space, though, so maybe it would be > > enough. > > I don't believe the Tegra boot process actually /requires/ the PT even > exist. IIRC, the boot ROM searches for the BCT, and the BCT contains a > pointer to the bootloader (e.g. U-Boot), so it's only at a later stage > in the game that anything would care about the PT. As such, worrying > about the PT (or even including it) may be pointless. After digging into this some more, I get the same impression. PT seems entirely optional. Information about the bootloader seems to be stored within the BCT. > I believe that TrimSlice's firmware recovery SD card images are created > solely using cbootimage, and hence most likely have no PT, although > obviously no additional partitions/file-systems on the media. It looks like cbootimage does have support for generating the bootloader bits, so maybe I can get this to work. > Perhaps you could define some hard-coded "MTD" partitions (e.g. the > first 1MB and the rest), where the first 1MB contains BCT + U-Boot and > the rest contains a regular MBR or GPT partition table. I /think/ there > may even be a kernel command-line option to define the MTD partition layout? > > Or, you could probably even get away with using a GPT for the entire > NAND by placing just the secondary GPT at the end of the NAND, putting > the BCT+U-Boot right at the start, and defining a GPT partition to > protect/cover BCT+U-Boot. I vaguely recall trying this on some Tegra > device, but I may be wrong. I didn't even know that you could put an MBR or GPT onto NAND. I was under the impression that the only way to partition flash was via MTD partitions. I'll have to see if I can make such a setup work. Thierry pgpSe8qrANJsD.pgp Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
