Showing posts with label linux. Show all posts
Showing posts with label linux. Show all posts

2012-02-13

[IPNC][DM368] BBT problem after patch to new ECC layout (Bad block table not found for chip 0))

This is follow-up section of another NAND ECC topic  NAND ECC issue - ECC layout incompatible between RBL/UBL and U-Boot/Linux

After patching new ECC table, we found that "Bad block table not found for chip 0" keeps showing even if "Bad block table written to 0x07ffc000" follows every time boot up. It means that the BBT is not written correctly, in both u-boot and linux kernel.

After (painfully) tracing ECC and BBT relevant source code in u-boot, I found the root cause is the incorrect location of writing BBT/mirror patterns.

1. look at following illustration which capture from TI's wiki (http://processors.wiki.ti.com/index.php/DM365_Nand_ECC_layout)


in the file drivers/mtd/nand/nand_bbt.c, there are two nand_bbt_descr structure, bbt_main_descr and bbt_mirror_descr which contain the information how bbt is placed and searched.

originally, the structures are like below (2010-12 u-boot release, I compared with the latest one,Dec 2011, and there isn't meaningful difference regarding ECC and BBT).
===

static uint8_t bbt_pattern[] = {'B', 'b', 't', '0' };
static uint8_t mirror_pattern[] = {'1', 't', 'b', 'B' };
static struct nand_bbt_descr bbt_main_descr = {
.options = NAND_BBT_LASTBLOCK | NAND_BBT_CREATE | NAND_BBT_WRITE
| NAND_BBT_2BIT | NAND_BBT_VERSION | NAND_BBT_PERCHIP,
.offs = 8,
.len = 4,
.veroffs = 12,
.maxblocks = 4,
.pattern = bbt_pattern
};
static struct nand_bbt_descr bbt_mirror_descr = {
.options = NAND_BBT_LASTBLOCK | NAND_BBT_CREATE | NAND_BBT_WRITE
| NAND_BBT_2BIT | NAND_BBT_VERSION | NAND_BBT_PERCHIP,
.offs = 8,
.len = 4,
.veroffs = 12, .maxblocks = 4,
.pattern = mirror_pattern
};


===

2. in check_pattern()@nand_bbt.c, we know that the structure member
offs - the offset from start of oob of block, to place the bbt_pattern
len - the length of bbt pattern
veroffs - the offset from the start of oob of block, to place the bbt version number

Apparently the setting was wrong after deploying the new ECC layout (the upper table in the picture) because the bbt pattern, starting from the 8th byte of OOB, is conflict with ECC.

I change it to 16th and veroffs at 32th, and BBT is back again!  The corresponding portion in Linux source should be changed too. In appro's ipnc release, the change can be made at ti-davinci/arch/arm/mach-davinci/board-dm368-ipnc.c

2011-11-29

[DM368][IPNC][UBL] GPIO and Pinmux Initialization

[Prolog]
In order to adapt my new hardware board, I have to change many of GPIO settings in Appro's IPNC SDK. I thought the major GPIO setting code would reside at linux arch, but it was wrong. Surprisely,  most of the setting including pinmux and GPIO direction is done at UBL!


[Main]
Restore your memory to school life...yeah, the good old time. All lectures taught you that the settings should be made where it needed during boot process. i.e. GPIO should be only configured  at the stage it will be used during boot straps.


UBL apparently is not a good place to perform GPIO configuration. TI even doesn't provide UBL source code with dvsdk! 


1. the code to set GPIO@ubl is at flash_utils/DM36x/Common/src/device.c, DEVICE_init()
==========

  DEVICE_pinmuxControl(0,0xFFFFFFFF,0x00FD0000);  // All Video Inputs  DEVICE_pinmuxControl(1,0xFFFFFFFF,0x00145555);  // All Video Outputs  DEVICE_pinmuxControl(2,0xFFFFFFFF,0x000000DA);  // EMIFA  DEVICE_pinmuxControl(3,0xFFFFFFFF,0x60000000);  // SPI0, SPI1, UART1, I2C, SD0, SD1, McBSP0, CLKOUTs 00180000  DEVICE_pinmuxControl(4,0xFFFFFFFF,0x5555D555);  // MMC/SD0 instead of MS, SPI0 55555555    GPIO->DIR23 &= 0xfeffffff;  GPIO->CLRDATA23 = 0x01000000;

==========


Moreover, you can find the system and peripheral clocks are set in  DEVICE_PLL1Init() and DEVICE_PLL2Init(), which I think can be move some to u-boot or even linux.


2. I decide to follow what textbook said - minimize the configure in ubl and u-boot and leave board specific changes to linux boot code. the benefit is obvious - I don't have to change code and recompile ubl (and maybe even better: u-boot as well) if hardware is changed. 


to be compatible with most DM368 hardware, I set most pin to GPIO, except MMC/SD0, VIN, UART0, UART1, I2C, CLKOUT0. The changes is listed below: 
==========

 //MMC/SD0, GIO49-43, YIN7-0, VD, HD, C_WE_FIELD  DEVICE_pinmuxControl(0,0xFFFFFFFF,0x00000000);   //GIO79-92 DEVICE_pinmuxControl(1,0xFFFFFFFF,0x00430000); 
//CMNT: GIO57-78 and EM_A[1] is configured by AECFG setting. leave it as-is and change in u-boot or os// CE0(GIO56) set to GPIO Interfacing to a Non-CE Don't Care NAND Flash  DEVICE_pinmuxControl(2,0x00000080,0x00000080);
//consider to enable emac for emac-boot  DEVICE_pinmuxControl(3,0xFFFFFFFF,0x61580000);  //UART1_TX, UART0, I2C
  DEVICE_pinmuxControl(4,0xFFFFFFFF,0x0030c000);  //CLKOUT0, UART1_RX


==========

There is also patch of NAND CE for Non-CE Don't card NAND flash. The CE is configured to GPIO and driven low manually.



GPIO->DIR23 &= 0xFEFFFFFF; //DIR56(bit24) set to output (L)
GPIO->CLRDATA23 = 0x01000000; //nand_ce low


The binary file can be downloaded at dm36x ubl gpio bin (uart0 and uart1 message). please be noted that you may want to revise GPIOs which are used by UART0 or UART1 in either u-boot or linux because they are all configured as UART in this binary.


[Option]
1. Turn on PINMUX to Ethernet in U-boot 
board_eth_init@dm365evm.c

//CMNT: manipulate eth pinmux only, PINMUX3[18:0]
// writel((readl(PINMUX3) | 0x1affff), PINMUX3); //RR CMNT: [18:0]-eth, [20:19]-UART0, [31:21] GIO26-20
writel(((readl(PINMUX3) & 0xfff80000) | 0x2ffff), PINMUX3); //CMNT: [18:0]-eth, [20:19]-UART0, [31:21] GIO26-20
2. Extend PHY reset time at board_eth_init@dm365evm.c from 1ms to 10ms, according DAVICOM PHY specification
udelay(10000);



[Epilog]

Unfortunately, GPIO settings in Linux vary from versions. The worse is that the setting scatters in different files. If you want to do it all at one place, you can put them in board_init()@board-dm368-ipnc.c. 
The Pinmux definition files have to be changed as well - check 
arch/arm/plat-davinci/mux.c
arch/arm/mach-davinci/mux_cfg.c
include/arch/arm/mach-davinci/mux.h 

2011-08-17

[DM368][IPNC] Using GDB on IPNC

[Prolog]

To dig into Appro's application, I decided to enable gdb on IPNC platform. There are two useful page provided by TI's wiki and they let me enable gdb on IPNC in one hour.
==============================
==============================

[Main]
1. get the latest gdb from gdb download page

2. configure and make gdb and gdbserver

for gdb
==============================
host# ./configure --host=i686-pc-linux-gnu --target=armv5tl-montavista-linux-gnueabi --prefix=/opt/mv_pro_5.0.0/montavista/pro/devkit/arm/v5t_le
host# make
host# make install
==============================

for gdbserver
==============================
host# cd gdb/gdbserver
host# CC=/opt/mv_pro_5.0.0/montavista/pro/devkit/arm/v5t_le/bin/arm_v5t_le-gcc ./configure  --host=armv5tl-montavista-linux-gnueabi --prefix=/home/user/workdir/filesys
host# make && make install
==============================

there was an error during "make install". the screen showed
==============================
cannot stat 'libinproctrace.so': No such file or directory
==============================

after quick google search, it can be fixed by modifying "gdb/gdbserver/Makefile.in"
==============================
original:
if [ x$IPA_DEPFILES != x ]; then \
fixed:
if [ x${IPA_DEPFILES} != x ]; then \
==============================


3. Running gdbserver at target
==============================
target# gdbserver 192.168.100.1:1000 ./sample
==============================



4. Running gdb at host
==============================
host# /opt/mv_pro_5.0.0/montavista/pro/devkit/arm/v5t_le/bin/armv5tl-montavista-linux-gnueabi-gdb ./sample
==============================

at gdb prompt
==============================
(gdb) set solib-search-path /home/user/workdir/filesys/lib (gdb) target remote 192.168.100.2:1000
==============================


5. (optional) using ddd
==============================
host# ddd --debugger arm_v5t_le-gdb
==============================

6. (optional) error "Malformed packet(b) (missing colon)" 
    in Appro reference design, there is an existing gdbserver under /usr/bin. However, the installation of gdbserver is toward /bin, and the PATH setting will select the old gdbserver (GNU gdbserver 6.6.50.20070301 in my case). Easy to fix though.




[Epilog]
Easy works as far! multitread debugging could be challenge though
[Extend readings]

Debugging on DaVinci using kgdb



2011-07-18

[Linux][kernel][DM368] Cannot Change Kernel Config Variable

After changing variables in the (default)config file, davinci_dm368_ipnc_defconfig, "make sys" generates .config but the .config file doesn't match the changes in davinci_dm368_ipnc_defconfig.

turning on USB_STORAGE at defconfig for example

# may also be needed; see USB_STORAGE Help for more information
#
# CONFIG_USB_STORAGE is not set
# CONFIG_USB_LIBUSUAL is not set
CONFIG_USB_STORAGE=m
CONFIG_USB_LIBUSUAL=y 
the .config will be still
# CONFIG_USB_STORAGE is not set
# CONFIG_USB_LIBUSUAL is not set
check steps:
1. track what's performed after executing "make sysall"  (make -n)
make sysall -> make lspall -> make lspclean, make lsp
make lsp -> make lspcfg
make lspcfg->
make lspbuild MAKE_TARGET=davinci_dm368_ipnc_defconfig => make ARCH=arm davinci_dm368_ipnc_defconfig   <==== I after this, .config is generated with incorrect config variables
make lspbuild MAKE_TARGET=checksetconfig

2.  locate potential trouble maker:
"make ARCH=arm davinci_dm368_ipnc_defconfig" executes "scripts/kconfig/conf -D arch/arm/configs/davinci_dm368_ipnc_defconfig arch/arm/Kconfig" to generate .config

suspicious screen output
arch/arm/configs/davinci_dm368_ipnc_defconfig:1037:warning: trying to reassign symbol USB_STORAGE
arch/arm/configs/davinci_dm368_ipnc_defconfig:1038:warning: trying to reassign symbol USB_LIBUSUAL
3. first, check if the variable USB_STORAGE has dependency problem.
the variable is defined at driver/usb/storage/Kconfig
config USB_STORAGE
    tristate "USB Mass Storage support"
    depends on USB
    select SCSI
but I am sure that CONFIG_USB is enabled in the generated .config file.

4. find more information about making kernel.

kernel 移植笔记(从omap linux-02.01.03.11 到 fred 版本kernel 学习)

史上最经典的Linux内核学习方法论

 "make ${PLATFORM}_defconfig"
     Create a ./.config file by using the default
     symbol values from
     arch/$ARCH/configs/${PLATFORM}_defconfig.
     Use "make help" to get a list of all available
     platforms of your architecture.

however, it seems not to have any problem. even I wasted couple hour to compare with the latest kernel.... no luck though

  5. back to fundamental, why "scripts/kconfig/conf -D arch/arm/configs/davinci_dm368_ipnc_defconfig arch/arm/Kconfig" outputs incorrect value.

[PATCH] Allow kconfig to accept overrides - Kernel

inspired me. so trace confdata.c
at conf_read_simple( )
    while (fgets(line, sizeof(line), in)) {
        conf_lineno++;
        sym = NULL;
        switch (line[0]) {
        case '#':
            if (memcmp(line + 2, "CONFIG_", 7))
                continue;
            p = strchr(line + 9, ' ');
            if (!p)
                continue;
            *p++ = 0;
            if (strncmp(p, "is not set", 10))
                continue;
it is surprised me that the line starting with "#" is not a comment !!

Solution
use double hash (##) as comment to "CONFIG_xxx is not set"


## CONFIG_USB_STORAGE is not set
## CONFIG_USB_LIBUSUAL is not set
CONFIG_USB_STORAGE=m
CONFIG_USB_LIBUSUAL=y  



Followups
in montavista releases, there is "Base Configuration for MontaVista Linux" file (scripts/kconfig/baseconfig), which will be compared with .config generated by make xxx_defconfig. The rules are

# If an option is marked as "m", the .config will only
# be modified if the option is turned off.
#
# If an option is marked as "y", the .config will be modified
# if the options in the "m" or the off states.
#
# If an option is marked as "n", the .config will be modified
# if the option is in the "m" or "y" states.
It could influence the final .config for making kernel.