13 replies to this topic

[charliebrown]

Hi,

 

can I someone tell me, or give me developer contact to ask if OpenPLI supports X16 nand access?. It looks like many of the scripts are hardcoded for X8 nand access. I've replaced the nand in my box (see my other post) and it looks like my issues are down to the new nand being in X16 mode and not x8.

 

Anyone?

 

[Erik Slagter]

This is either a driver (closed source manufacturer) or kernel issue. OpenPLi takes no part in this issue.

[charliebrown]

Thing is the build scripts for openPLI specifically mention block/erase size for the UBIFS, this is why I ask here. Are you saying openPLI is abstracted away from the specifics of the filesytem (on nand) layout and therefore no one can offer advice?.

 

Btw we are talking about UBIFS, nothing to do with closed source drivers. The drivers are all part of the Linux kernel, no propitiatory blobs involved. 

Edited by charliebrown, 13 September 2015 - 16:46.

[MiLo]

If you're talking about 16-bit connection to the chip, that's arranged by kernel and bootloader. Scripts and stuff are totally ignorant of the physical connection to the NAND chip.

(Sounds more like a hardware issue - to use x16 NAND you'll need 8 extra wires routed to it. Many chips can run in both modes though.)

Anyway, you have full access to everything. No secrets, if it isn't in the repositories, we don't have it.

[charliebrown]

If you're talking about 16-bit connection to the chip, that's arranged by kernel and bootloader. Scripts and stuff are totally ignorant of the physical connection to the NAND chip.

(Sounds more like a hardware issue - to use x16 NAND you'll need 8 extra wires routed to it. Many chips can run in both modes though.)

Anyway, you have full access to everything. No secrets, if it isn't in the repositories, we don't have it.

 

Actually I was talking to an Engineer at spansion. The problem is the kernel is incorrectly identifying the blocksize. 

 

This is the line I see in the serial output

 

NAND Config: Reg=35142200, chipSize=128 MB, blockSize=512K, erase_shift=13

 

This is 100% wrong, because the chip I have is 100% x8 and not x16. The chip S34ML01G100TFI000 which is x8 , the x16 part is S34ML01G104TFI000 according to the datasheet page 71

 

http://www.spansion....ML01G1_04G1.pdf

 

 

I changed the file oe-alliance/builds/openvix/release/vuuno/tmp/work-shared/vuuno/kernel-source/drivers/mtd/brcmnand/brcmnand_base.c and hard coded values for x8 (128K pages) BUT compiling the image "MACHINE=vuuno DISTRO=openvix make image" did not affect the compiled kernel. Infact I put some debug messages in the .c file so that the above line SHOULD have printk as

 

DEBUGNAND Config: Reg=35142200, chipSize=128 MB, blockSize=512K, erase_shift=13

 

But nothing changed, so that tells me my changes are ignored and the file is either not used OR ignored?.

 

I'm not a C coder (Java) but I can hack the file so that its forced to use 128K pages by modifying function 

 

brcmnand_decode_config(struct brcmnand_chip* chip, uint32_t nand_config)

 

 

And changing lines that look like this

 

 

switch ((nand_config & BCHP_NAND_CONFIG_BLOCK_SIZE_MASK)

                        >> BCHP_NAND_CONFIG_BLOCK_SIZE_SHIFT) {

                case BCHP_NAND_CONFIG_BLOCK_SIZE_BK_SIZE_512KB:

                        chip->blockSize = 512 << 10;

                        break;

                case BCHP_NAND_CONFIG_BLOCK_SIZE_BK_SIZE_8KB:

                        chip->blockSize = 8 << 10;

                        break;

                case BCHP_NAND_CONFIG_BLOCK_SIZE_BK_SIZE_128KB:

                        chip->blockSize = 128 << 10;

                        break;

                case BCHP_NAND_CONFIG_BLOCK_SIZE_BK_SIZE_16KB:

                        chip->blockSize = 16 << 10;

                        break;

        }

 

 

To look like this (hard coding 128K values where 512K is set). I dont care for 512K as I will never use it so its a dirty hack but i dont know how else to fix this

 

switch ((nand_config & BCHP_NAND_CONFIG_BLOCK_SIZE_MASK)

                        >> BCHP_NAND_CONFIG_BLOCK_SIZE_SHIFT) {

                case BCHP_NAND_CONFIG_BLOCK_SIZE_BK_SIZE_512KB:

                        chip->blockSize = 128 << 10;

                        break;

                case BCHP_NAND_CONFIG_BLOCK_SIZE_BK_SIZE_8KB:

                        chip->blockSize = 8 << 10;

                        break;

                case BCHP_NAND_CONFIG_BLOCK_SIZE_BK_SIZE_128KB:

                        chip->blockSize = 128 << 10;

                        break;

                case BCHP_NAND_CONFIG_BLOCK_SIZE_BK_SIZE_16KB:

                        chip->blockSize = 16 << 10;

                        break;

        }

 

Is that the right file to edit?, I'm unsure as if I change it and compile, my changes are not present, like its not using that file.

[charliebrown]

I dont have permission to edit the above post (dont know why?) 

 

This is the page from the datasheet

 

[Erik Slagter]

And now what are we supposed to do?

[charliebrown]

And now what are we supposed to do?

 

I'm simply looking for advice as to where the config for the nand comes from. I'm not demanding you to do anything, just after some advice from devs who are more familiar with the build environment than I am 

[betacentauri]

Try this
cd oe-alliance/builds/openvix/release/vuuno
MACHINE=vuuno
MACHINEBUILD=vuuno
DISTRO=openvix
source env.source
bitbake -c cleansstate virtual/kernel
bitbake -c patch virtual/kernel
Now change the file in the tmp/work/.... directory. I don't think its in tmp/work-shared, but I'm not 100% sure.
Then execute
bitbake virtual/kernel
This should build new kernel Ipk with the changed sources.

[charliebrown]

Try this
cd oe-alliance/builds/openvix/release/vuuno
MACHINE=vuuno
MACHINEBUILD=vuuno
DISTRO=openvix
source env.source
bitbake -c cleansstate virtual/kernel
bitbake -c patch virtual/kernel
Now change the file in the tmp/work/.... directory. I don't think its in tmp/work-shared, but I'm not 100% sure.
Then execute
bitbake virtual/kernel
This should build new kernel Ipk with the changed sources.

 

Thank you, i;ll give it a whirl.

[athoik]

I suggest to create a bbappend file and add the extra patch to SRC_URI. Then build will contain the patch for sure.

Edited by athoik, 15 September 2015 - 19:41.

[charliebrown]

Try this
cd oe-alliance/builds/openvix/release/vuuno
MACHINE=vuuno
MACHINEBUILD=vuuno
DISTRO=openvix
source env.source
bitbake -c cleansstate virtual/kernel
bitbake -c patch virtual/kernel
Now change the file in the tmp/work/.... directory. I don't think its in tmp/work-shared, but I'm not 100% sure.
Then execute
bitbake virtual/kernel
This should build new kernel Ipk with the changed sources.

 

SUCCESS!!... previously I had the box boot but it would corrupt the filesystem if I wrote one byte. now that's not happening and i can use the box like it came from factory.

 

YOU ARE THE MAN!... One dead Vu Uno to one revived Uno with a new NAND

 

I suggest to create a bbappend file and add the extra patch to SRC_URI. Then build will contain the patch for sure.

 

Its a one line change, I would love to know how to do what you say so the "fix" is automated.

[athoik]

Its a one line change, I would love to know how to do what you say so the "fix" is automated.

Create a file named linux-vuuno_3.9.6.bbappend and place it under meta-local (eg meta-local/recipes-local/images or create folder meta-local/recipes-local/ovverides etc).

The file linux-vuuno_3.9.6.bbappend should contain the following:

FILESEXTRAPATHS_prepend := "${THISDIR}:"
SRC_URI += "file://nand-blocksize.patch"

The nand-blocksize patch is the "hack" you already have and this should be at the same folder where bbappend exists.

The advantage of bbappend is that you can create your customized builds without making "meta-(oe|openpli|vu|...)" dirty..

[charliebrown]

Thank you very much. Going to have a go with this as its much easier (and cleaner) to apply the patch than to do it by hand every time.