kernel 2.6.35 on imx233: boot problem

[whitewool]

Hi, i'm trying to move from imx233 2.6.31 environment to 2.6.35 kernel by using ltib for mx28 configured for imx233.

Just trying to launch linux on my custom board, where the 2.6.31 kernel runs since some months.

Now on ltib I've set ub a basic 2.6.35 kernel for mx233 to load on the card and I've a bad problem as you can see at the end of the attached log.

I'm using the same boot command I used for 2.6.31:

     noinitrd console=ttyAM0,115200 ubi.mtd=1 root=ubi0:rootfs0 rootfstype=ubifs rw ip=none gpmi

which worked perfectly with 2.6.31 kernel and now I'm not able to understand what's happening.

The boot log for 2.6.3.1 is almost identical, no problem to see the NAND flash, so the problem is ubi, pheraps.

Could anyone give me indications about this problem?

Thanks

Alberto

PowerPrep start initialize power...

Battery Voltage = 4.09V

boot from battery. 5v input not detected

LLCMar 28 201321:14:34

EMI_CTRL 0x1C084040

FRAC 0x92926192

init_mddr_mt46h32m16lf_133Mhz

power 0x00820710

Frac 0x92926192

start change cpu freq

hbus 0x00000003

cpu 0x00010001

Uncompressing

Linux...

done, booting the kernel.

Linux version 2.6.35.3-670-g914558e (clc@ubuntu) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #5 PREEMPT Thu Mar 28 21:07:09 CET 2013

CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177

CPU: VIVT data cache, VIVT instruction cache

Machine: Freescale MX23EVK board

Memory policy: ECC disabled, Data cache writeback

Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256

Kernel command line: -e noinitrd console=ttyAM0,115200 ubi.mtd=1 root=ubi0:rootfs0 rootfstype=ubifs rw ip=none gpmi

PID hash table entries: 256 (order: -2, 1024 bytes)

Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)

Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)

Memory: 64MB = 64MB total

Memory: 57372k/57372k available, 8164k reserved, 0K highmem

Virtual kernel memory layout:

    vector  : 0xffff0000 - 0xffff1000   (   4 kB)

    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)

    DMA     : 0xfde00000 - 0xffe00000   (  32 MB)

    vmalloc : 0xc4800000 - 0xf0000000   ( 696 MB)

    lowmem  : 0xc0000000 - 0xc4000000   (  64 MB)

    modules : 0xbf000000 - 0xc0000000   (  16 MB)

      .init : 0xc0008000 - 0xc0024000   ( 112 kB)

      .text : 0xc0024000 - 0xc0322000   (3064 kB)

      .data : 0xc0334000 - 0xc0359980   ( 151 kB)

SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1

Hierarchical RCU implementation.

        RCU-based detection of stalled CPUs is disabled.

        Verbose stalled-CPUs detection is disabled.

NR_IRQS:224

Console: colour dummy device 80x30

console [ttyAM0] enabled

Calibrating delay loop... 226.09 BogoMIPS (lpj=1130496)

pid_max: default: 32768 minimum: 301

Security Framework initialized

Mount-cache hash table entries: 512

CPU: Testing write buffer coherency: ok

regulator: core version 0.5

NET: Registered protocol family 16

regulator: vddd: 800 <--> 1575 mV at 1550 mV fast normal

regulator: vdddbo: 800 <--> 1575 mV fast normal

regulator: vdda: 1500 <--> 2275 mV at 1750 mV fast normal

regulator: vddio: 2800 <--> 3575 mV at 3300 mV fast normal

regulator: overall_current: fast normal

regulator: mxs-duart-1: fast normal

regulator: mxs-bl-1: fast normal

regulator: mxs-i2c-1: fast normal

regulator: mmc_ssp-1: fast normal

regulator: mmc_ssp-2: fast normal

regulator: charger-1: fast normal

regulator: power-test-1: fast normal

regulator: cpufreq-1: fast normal

i.MX IRAM pool: 28 KB@0xc4808000

bio: create slab <bio-0> at 0

SCSI subsystem initialized

Switching to clocksource mxs clock source

NET: Registered protocol family 1

Trying to unpack rootfs image as initramfs...

rootfs image is not initramfs (junk in compressed archive); looks like an initrd

Freeing initrd memory: 4096K

Bus freq driver module loaded

mxs_cpu_init: cpufreq init finished

msgmni has been set to 120

alg: No test for stdrng (krng)

cryptodev: driver loaded.

io scheduler noop registered

io scheduler deadline registered

io scheduler cfq registered (default)

Console: switching to colour frame buffer device 30x40

mxs-duart.0: ttyAM0 at MMIO 0x80070000 (irq = 0) is a DebugUART

mxs-auart.1: ttySP1 at MMIO 0x8006c000 (irq = 24) is a mxs-auart.1

Found APPUART 3.0.0

brd: module loaded

loop: module loaded

i.MX GPMI NFC

NFC: Version 0, 4-chip GPMI and BCH

Boot ROM: Version 0, Single/dual-chip boot area, no block mark swapping

Scanning for NAND Flash chips...

NAND device: Manufacturer ID: 0xec, Chip ID: 0xd3 (Samsung NAND 1GiB 3,3V 8-bit)

-----------------------------

NAND Flash Device Information

-----------------------------

Manufacturer      : Samsung (0xec)

Device Code       : 0xd3

Cell Technology   : MLC

Chip Size         : 1 GiB

Pages per Block   : 128

Page Geometry     : 2048+64

ECC Strength      : 4 bits

ECC Size          : 512 B

Data Setup Time   : 20 ns

Data Hold Time    : 15 ns

Address Setup Time: 20 ns

GPMI Sample Delay : 6 ns

tREA              : Unknown

tRLOH             : Unknown

tRHOH             : Unknown

Description       : K9G8G08U0M, K9HAG08U1M

-----------------

Physical Geometry

-----------------

Chip Count             : 1

Page Data Size in Bytes: 2048 (0x800)

Page OOB Size in Bytes : 64

Block Size in Bytes    : 262144 (0x40000)

Block Size in Pages    : 128 (0x80)

Chip Size in Bytes     : 1073741824 (0x40000000)

Chip Size in Pages     : 524288 (0x80000)

Chip Size in Blocks    : 4096 (0x1000)

Medium Size in Bytes   : 1073741824 (0x40000000)

------------

NFC Geometry

------------

ECC Algorithm          : BCH

ECC Strength           : 8

Page Size in Bytes     : 2112

Metadata Size in Bytes : 10

ECC Chunk Size in Bytes: 512

ECC Chunk Count        : 4

Payload Size in Bytes  : 2048

Auxiliary Size in Bytes: 16

Auxiliary Status Offset: 12

Block Mark Byte Offset : 0

Block Mark Bit Offset  : 0

-----------------

Boot ROM Geometry

-----------------

Boot Area Count            : 1

Boot Area Size in Bytes    : 41943040 (0x2800000)

Stride Size in Pages       : 64

Search Area Stride Exponent: 2

Scanning for an NCB fingerprint...

  Looking for a fingerprint in page 0x0

  Found a fingerprint

Scanning device for bad blocks

Boot area protection is enabled.

Creating 2 MTD partitions on "gpmi-nfc-main":

0x000000000000-0x000002800000 : "gpmi-nfc-0-boot"

0x000002800000-0x000040000000 : "gpmi-nfc-general-use"

UBI: attaching mtd1 to ubi0

UBI: physical eraseblock size:   262144 bytes (256 KiB)

UBI: logical eraseblock size:    258048 bytes

UBI: smallest flash I/O unit:    2048

UBI: VID header offset:          2048 (aligned 2048)

UBI: data offset:                4096

UBI: attached mtd1 to ubi0

UBI: MTD device name:            "gpmi-nfc-general-use"

UBI: MTD device size:            984 MiB

UBI: number of good PEBs:        3936

UBI: number of bad PEBs:         0

UBI: max. allowed volumes:       128

UBI: wear-leveling threshold:    4096

UBI: number of internal volumes: 1

UBI: number of user volumes:     2

UBI: available PEBs:             39

UBI: total number of reserved PEBs: 3897

UBI: number of PEBs reserved for bad PEB handling: 39

UBI: max/mean erase counter: 3/1

UBI: image sequence number: 0

UBI: background thread "ubi_bgt0d" started, PID 372

mice: PS/2 mouse device common for all mice

input: mxs-kbd as /class/input/input0

MXS RTC driver v1.0 hardware v2.0.0

mxs-rtc mxs-rtc.0: rtc core: registered mxs-rtc as rtc0

i2c /dev entries driver

Linux video capture interface: v2.00

mxs-pxp mxs-pxp.0: initialized

mxs watchdog: initialized, heartbeat 19 sec

mxs-mmc: MXS SSP Controller MMC Interface driver

wp

mxs-mmc mxs-mmc.0: MMC HW configuration failed

mxs-mmc: probe of mxs-mmc.0 failed with error -16

dcp dcp.0: DCP crypto enabled.!

NET: Registered protocol family 17

mxs-rtc mxs-rtc.0: setting system clock to 1970-01-01 00:00:09 UTC (9)

VFS: Cannot open root device "ubi0:rootfs0" or unknown-block(0,0)

Please append a correct "root=" boot option; here are the available partitions:

1f00           40960 mtdblock0 (driver?)

1f01         1007616 mtdblock1 (driver?)

1f02          262332 mtdblock2 (driver?)

1f03          708876 mtdblock3 (driver?)

fe00          262332 ubiblka (driver?)

fe08          708876 ubiblkb (driver?)

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

[OtavioSalvador]

You may look at our branch in Yocto as it had some patches.

[whitewool]

Thanks Otavio,

As you suggested me in another discussion   imx233 hang changing freq from 24MHz to 261MHz   I'm already looking an the 10.12.01 branch on Freescale git hub. I'll come back asap to confirm answers for this and all other discussions about the problems that get me stuck in this moment.

It is not easy going to Yocto now, because we work on ltib and the time is short, but I'll take time to study Yocto also.

Our prototype doesn't provide sd/mmc card, only can be fw updated via usb recovery mode.

Probably it is written somewhere but now I can't understand how in Yocto I can build updater.sb and mx23_linux.sb for this. Can you give me some simple hints about?

[admin]

Alberto, were you able to solve your boot problems on this?

[whitewool]

Sorry Grant, a lot of time passed.

I gave up with 2.6.35 and followed with 2.6.31.

Nevertheless I'm trying to go to 2.6.35 again using the last LTIB for mx28 configured as mx233, but same results.

In the past I used an updater based on 2.631 to load 2.6.35 kernel+rootfs (the boot log above), and now I'm trying to build ad updater based on 2.6.35. in case this was the problem (don't think so but I try)

Initially I had a lot of problems with power supply configuration, (an infinite restart loop at updater boot), which I bypassed, to be solved later, using the 2.6.31 power_prep.c.

Now the updater boots but also stops on UBI problems (look at the end):

All seems to work, flash erased, ubi attached to mtd, ubi volumes created, but mount of ubifs over ubi volume 0 fails. There must be something wrong with UBI/UBIFS on ltib 2.6.35.3 build.

PowerPrep start initialize power...

Battery Voltage = 4.18V

5v source detected.Valid battery                                voltage detected.Booting from battery                           voltage source.

LLCOct 20 201319:13:24

EMI_CTRL 0x1C084040

FRAC 0x92926152

init_mddr_mt46h32m16lf_133Mhz

power 0x00820710

Frac 0x92926152

start change cpu freq

hbus 0x00000003

cpu 0x00010002

LLLLLLLFCLFLJUncompressing Linux... done, booting the kernel.

Linux version 2.6.35.3-670-g914558e (clc@ubuntu) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #4 PREEMPT Tue Oct 22 16:45:22 CEST 2013

CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177

CPU: VIVT data cache, VIVT instruction cache

Machine: Freescale MX23EVK board

Memory policy: ECC disabled, Data cache writeback

Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256

Kernel command line: -e console=ttyAM0,115200 rdinit=/linuxrc rw gpmi

PID hash table entries: 256 (order: -2, 1024 bytes)

Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)

Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)

Memory: 64MB = 64MB total

Memory: 55652k/55652k available, 9884k reserved, 0K highmem

Virtual kernel memory layout:

    vector  : 0xffff0000 - 0xffff1000   (   4 kB)

    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)

    DMA     : 0xfde00000 - 0xffe00000   (  32 MB)

    vmalloc : 0xc4800000 - 0xf0000000   ( 696 MB)

    lowmem  : 0xc0000000 - 0xc4000000   (  64 MB)

    modules : 0xbf000000 - 0xc0000000   (  16 MB)

      .init : 0xc0008000 - 0xc0025000   ( 116 kB)

      .text : 0xc0025000 - 0xc02e5000   (2816 kB)

      .data : 0xc02e6000 - 0xc0308c00   ( 139 kB)

SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1

Hierarchical RCU implementation.

        RCU-based detection of stalled CPUs is disabled.

        Verbose stalled-CPUs detection is disabled.

NR_IRQS:224

Console: colour dummy device 80x30

console [ttyAM0] enabled

Calibrating delay loop... 113.04 BogoMIPS (lpj=565248)

pid_max: default: 32768 minimum: 301

Mount-cache hash table entries: 512

CPU: Testing write buffer coherency: ok

regulator: core version 0.5

regulator: vddd: 800 <--> 1575 mV at 1550 mV fast normal

regulator: vdddbo: 800 <--> 1575 mV fast normal

regulator: vdda: 1500 <--> 2275 mV at 1750 mV fast normal

regulator: vddio: 2800 <--> 3575 mV at 3300 mV fast normal

regulator: overall_current: fast normal

regulator: mxs-duart-1: fast normal

regulator: mxs-bl-1: fast normal

regulator: mxs-i2c-1: fast normal

regulator: mmc_ssp-1: fast normal

regulator: mmc_ssp-2: fast normal

regulator: charger-1: fast normal

regulator: power-test-1: fast normal

regulator: cpufreq-1: fast normal

i.MX IRAM pool: 28 KB@0xc4808000

usb: DR gadget (utmi) registered

bio: create slab <bio-0> at 0

SCSI subsystem initialized

Switching to clocksource mxs clock source

Trying to unpack rootfs image as initramfs...

Freeing initrd memory: 6144K

Bus freq driver module loaded

mxs_cpu_init: cpufreq init finished

msgmni has been set to 120

alg: No test for stdrng (krng)

cryptodev: driver loaded.

io scheduler noop registered

io scheduler deadline registered

io scheduler cfq registered (default)

Console: switching to colour frame buffer device 60x34

mxs-duart.0: ttyAM0 at MMIO 0x80070000 (irq = 0) is a DebugUART

mxs-auart.1: ttySP1 at MMIO 0x8006c000 (irq = 24) is a mxs-auart.1

Found APPUART 3.0.0

brd: module loaded

loop: module loaded

i.MX GPMI NFC

NFC: Version 0, 4-chip GPMI and BCH

Boot ROM: Version 0, Single/dual-chip boot area, no block mark swapping

Scanning for NAND Flash chips...

NAND device: Manufacturer ID: 0xec, Chip ID: 0xd3 (Samsung NAND 1GiB 3,3V 8-bit)

-----------------------------

NAND Flash Device Information

-----------------------------

Manufacturer      : Samsung (0xec)

Device Code       : 0xd3

Cell Technology   : MLC

Chip Size         : 1 GiB

Pages per Block   : 128

Page Geometry     : 2048+64

ECC Strength      : 4 bits

ECC Size          : 512 B

Data Setup Time   : 20 ns

Data Hold Time    : 15 ns

Address Setup Time: 20 ns

GPMI Sample Delay : 6 ns

tREA              : Unknown

tRLOH             : Unknown

tRHOH             : Unknown

Description       : K9G8G08U0M, K9HAG08U1M

-----------------

Physical Geometry

-----------------

Chip Count             : 1

Page Data Size in Bytes: 2048 (0x800)

Page OOB Size in Bytes : 64

Block Size in Bytes    : 262144 (0x40000)

Block Size in Pages    : 128 (0x80)

Chip Size in Bytes     : 1073741824 (0x40000000)

Chip Size in Pages     : 524288 (0x80000)

Chip Size in Blocks    : 4096 (0x1000)

Medium Size in Bytes   : 1073741824 (0x40000000)

------------

NFC Geometry

------------

ECC Algorithm          : BCH

ECC Strength           : 8

Page Size in Bytes     : 2112

Metadata Size in Bytes : 10

ECC Chunk Size in Bytes: 512

ECC Chunk Count        : 4

Payload Size in Bytes  : 2048

Auxiliary Size in Bytes: 16

Auxiliary Status Offset: 12

Block Mark Byte Offset : 0

Block Mark Bit Offset  : 0

-----------------

Boot ROM Geometry

-----------------

Boot Area Count            : 1

Boot Area Size in Bytes    : 41943040 (0x2800000)

Stride Size in Pages       : 64

Search Area Stride Exponent: 2

Scanning for an NCB fingerprint...

  Looking for a fingerprint in page 0x0

  Found a fingerprint

Scanning device for bad blocks

Boot area protection is enabled.

Creating 2 MTD partitions on "gpmi-nfc-main":

0x000000000000-0x000002800000 : "gpmi-nfc-0-boot"

0x000002800000-0x000040000000 : "gpmi-nfc-general-use"

ARC USBOTG Device Controller driver (1 August 2005)

check_parameters:UTP settings are in place now, overriding defaults

g_file_storage gadget: File-backed Storage Gadget, version: 20 November 2008

g_file_storage gadget: Number of LUNs=1

fsl-usb2-udc: bind to driver g_file_storage

mice: PS/2 mouse device common for all mice

input: mxs-kbd as /class/input/input0

input: MXS touchscreen as /class/input/input1

MXS RTC driver v1.0 hardware v2.0.0

mxs-rtc mxs-rtc.0: rtc core: registered mxs-rtc as rtc0

add mma i2c driver

mma7450 0-001d: read chip ID 0xffffff87 is not equal to 0x1d!

mma7450: probe of 0-001d failed with error -121

mxs-mmc: MXS SSP Controller MMC Interface driver

g_file_storage gadget: high speed config #1

mxs-mmc mxs-mmc.0: mmc0: MXS SSP MMC DMAIRQ 14 ERRIRQ 15

dcp dcp.0: DCP crypto enabled.!

mxs-rtc mxs-rtc.0: setting system clock to 2012-01-01 03:18:26 UTC (1325387906)

Freeing init memory: 116K

Starting UTP

ln: /etc/mtab: File exists

disable turn off display

uuc 0.4 [built Oct 20 2013 19:38:06]

UTP: Waiting for device to appear

utp_mk_devnode: creating node '/dev/utp' with 10+222

cpu_id is 23

UTP: received command 'mknod class/mtd,mtd0,/dev/mtd0'

class = 'class/mtd'

item = 'mtd0'

node = /dev/mtd0

type = (null)

UTP: running utp_mk_devnode(class/mtd,mtd0,/dev/mtd0,0x2000)

utp_mk_devnode: creating node '/dev/mtd0' with 90+0

UTP: sending Success

UTP: received command 'mknod class/mtd,mtd1,/dev/mtd1'

class = 'class/mtd'

item = 'mtd1'

node = /dev/mtd1

type = (null)

UTP: running utp_mk_devnode(class/mtd,mtd1,/dev/mtd1,0x2000)

utp_mk_devnode: creating node '/dev/mtd1' with 90+2

UTP: sending Success

UTP: received command 'mknod class/misc,ubi_ctrl,/dev/ubi_ctrl'

class = 'class/misc'

item = 'ubi_ctrl'

node = /dev/ubi_ctrl

type = (null)

UTP: running utp_mk_devnode(class/misc,ubi_ctrl,/dev/ubi_ctrl,0x2000)

utp_mk_devnode: creating node '/dev/ubi_ctrl' with 10+61

UTP: sending Success

UTP: received command '$ flash_erase /dev/mtd0 0 0'

UTP: sending Busy

UTP: executing "flash_erase /dev/mtd0 0 0"

Erasing 256 Kibyte @ 1c8000utp_poll: pass returned.

Erasing 256 Kibyte @ 27c0000 -- 100 % complete

UTP: sending Success

UTP: received command '$ flash_erase /dev/mtd1 0 0'

UTP: sending Busy

UTP: executing "flash_erase /dev/mtd1 0 0"

Erasing 256 Kibyte @ 3d440000 -- 99 % completutp_poll: pass returned.

Erasing 256 Kibyte @ 3d7c0000 -- 100 % complete

UTP: sending Success

UTP: received command 'send'

UTP: sending Success

UTP: received command '$ kobs-ng init $FILE'

UTP: sending Busy

UTP: executing "kobs-ng init $FILE"

UTP: sending Success

utp_poll: pass returned.

UTP: received command '$ ubiattach /dev/ubi_ctrl -m 1 -d 0'

UTP: sending Busy

UTP: executing "ubiattach /dev/ubi_ctrl -m 1 -d 0"

UBI: attaching mtd1 to ubi0

UBI: physical eraseblock size:   262144 bytes (256 KiB)

UBI: logical eraseblock size:    258048 bytes

UBI: smallest flash I/O unit:    2048

UBI: VID header offset:          2048 (aligned 2048)

UBI: data offset:                4096

UBI: empty MTD device detected

UBI: create volume table (copy #1)

UBI: create volume table (copy #2)

UBI: attached mtd1 to ubi0

UBI: MTD device name:            "gpmi-nfc-general-use"

UBI: MTD device size:            984 MiB

UBI: number of good PEBs:        3936

UBI: number of bad PEBs:         0

UBI: max. allowed volumes:       128

UBI: wear-leveling threshold:    4096

UBI: number of internal volumes: 1

UBI: number of user volumes:     0

UBI: available PEBs:             3893

UBI: total number of reserved PEBs: 43

UBI: number of PEBs reserved for bad PEB handling: 39

UBI: max/mean erase counter: 0/0

UBI: image sequence number: 0

UBI: background thread "ubi_bgt0d" started, PID 641

UTP: sending Success

utp_poll: pass returned.

UTP: received command 'mknod class/ubi,ubi0,/dev/ubi0'

class = 'class/ubi'

item = 'ubi0'

node = /dev/ubi0

type = (null)

UTP: running utp_mk_devnode(class/ubi,ubi0,/dev/ubi0,0x2000)

utp_mk_devnode: creating node '/dev/ubi0' with 253+0

UTP: sending Success

UTP: received command '$ ubimkvol /dev/ubi0 -n 0 -N rootfs0 -s 256000000'

UTP: sending Busy

UTP: executing "ubimkvol /dev/ubi0 -n 0 -N rootfs0 -s 256000000"

UTP: sending Success

utp_poll: pass returned.

UTP: received command '$ ubimkvol /dev/ubi0 -n 1 -N data -s 128000000'

UTP: sending Busy

UTP: executing "ubimkvol /dev/ubi0 -n 1 -N data -s 128000000"

UTP: sending Success

utp_poll: pass returned.

UTP: received command '$ ubinfo -a'

UTP: sending Busy

UTP: executing "ubinfo -a"

UBI version:                    1

Count of UBI devices:           1

UBI control device major/minor: 10:61

Present UBI devices:            ubi0

ubi0

Volumes count:                           2

Logical eraseblock size:                 258048 bytes, 252.0 KiB

Total amount of logical eraseblocks:     3936 (1015676928 bytes, 968.6 MiB)

Amount of available logical eraseblocks: 2403 (620089344 bytes, 591.4 MiB)

Maximum count of volumes                 128

Count of bad physical eraseblocks:       0

Count of reserved physical eraseblocks:  39

Current maximum erase counter value:     3

Minimum input/output unit size:          2048 bytes

Character device major/minor:            253:0

Present volumes:                         0, 1

Volume ID:   0 (on ubi0)

Type:        dynamic

Alignment:   1

Size:        993 LEBs (256241664 bytes, 244.4 MiB)

State:       OK

Name:        rootfs0

Character device major/minor: 253:1

-----------------------------------

Volume ID:   1 (on ubi0)

Type:        dynamic

Alignment:   1

Size:        497 LEBs (128249856 bytes, 122.3 MiB)

State:       OK

Name:        data

Character device major/minor: 253:2

UTP: sending Success

utp_poll: pass returned.

UTP: received command '$ mount'

UTP: sending Busy

UTP: executing "mount"

none on /sys type sysfs (rw)

none on /proc type proc (rw)

UTP: sending Success

utp_poll: pass returned.

UTP: received command '$ mkdir -p /mnt/ubi; mount -t ubifs ubi0_0 /mnt/ubi'

UTP: sending Busy

UTP: executing "mkdir -p /mnt/ubi; mount -t ubifs ubi0_0 /mnt/ubi"

mount: ubi0_0 already mounted or /mnt/ubi busy

UTP: sending Non-success

utp_poll: exit with status 8192

[OtavioSalvador]

Hello whitewool,

I'd use Linux mainline (3.12 - or 3.10 if you prefer a LTS kernel) for i.MX233. It has support for its NAND controller and it is easy to use it with the Bootlets; the support for NAND is not yet included in U-Boot mainline but a friend is work on this and should soon be available too.

We use Linux mainline for imx23evk by default in meta-fsl-arm (for Yocto).

Regards,

[whitewool]

Hi Otavio,

I think your is a right suggestion, but as I said you our problem is people and time to changing to Yocto.

Think that for the next project this will be our choice but for the moment we are bound to ltib.

Anyway, there is something I still do not understand:

For sure I've strong limitations, but are we saying that 2.6.31 and 2.6.35 ltib are unusable without working for years?

At the moment in 2.6.31 for imx233:

     I2C completely broken (really, and no patch present, I found something on the web to make it work bettery. I2C is important in embedded)

     CPU Clock scale not working (I had to modify a lot of files and also some assembler based on grace's hints)

     USB host working bad (still problems with power)

     PXP driver incomplete (look at what the documentation says and look at the code). We had to strong modify framebuffer and other to simply rotate the screen.

     NO support for OCOTP

     GPIO Keys driver not adapted for mxs.

They are all basics, fundamental, when you choose for an embedded you trust on these.

I know, bugs are always present, everywhere, and an OS is a very complex thing, but I wonder why imx233 has been abandoned on ltib. Has it not been sold?

And, triyng to go 2.6.35 to have a more stable situation I can't understand where are these problems, and if patches are present that I can port simply by hand.

Could you help me about?

Thanks

Alberto

[OtavioSalvador]

Aberto, let's talk about each point individually:

Alberto Biancalana wrote:

I think your is a right suggestion, but as I said you our problem is people and time to changing to Yocto.

Think that for the next project this will be our choice but for the moment we are bound to ltib.

Yes; the learning curve is not easy for Yocto but at other side you have companies which offer consultancy and services on top of it (as O.S. Systems does) and the community which helps a lot.

Alberto Biancalana wrote:

Anyway, there is something I still do not understand:

For sure I've strong limitations, but are we saying that 2.6.31 and 2.6.35 ltib are unusable without working for years?

i.MX233 is not very active lately. It seems replaced by i.MX28 for new projects and cost is close (except easiness for assembly as i.MX233 has LQFP alternative and i.MX28 does not).

Last kernel (based on 2.6.35.3) that I had working for i.MX233 was http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=imx_2.6.35_10.12.01 but I've been not using it for a while and I don't recall what was the final status of it. But it may be worth a try.

Most people using i.MX233 been working on mainline as it offers much better support, code base and is active. Without having a good understanding about your project it is difficult to advise if it is the right choice or not. Maybe you can use Linux mainline at LTIB base (or build it externally) and give it a try.

Alberto Biancalana wrote:

Could you help me about?

For sure; I think the above give you enough hints where to look and research. In case you need more help please contact me in private so we can discuss how to help you.

Regards,

[whitewool]

Some other info on my project:

We need:

     NAND flash management (1GB / 2GB), no SD/MMC.

     full i2c support 400Kb/s for sensors

     lradc suport for external sensors

     usb gadget storage to connect to a PC by exporting a FAT partition placed on the internal NAND

     usb host mass storage to save log files to an usb stick

     static screen rotation: we use a 320x240 TFT and non one produces native horizontal screens the size we need.

     serial to connect to other devices, with cable or radio (custom)

     the device is li-ion battery powered

     app is developed on qt-4.7.4, it is not so light, some tenths of thousand c++ lines (not counting comments) and uses mobile graphics.

     aA you can see we don't need particular features, all base features for an embedded, so 2.6.35 as kernel should be enough, but the most of problem we had from fsl drivers / sw platform.

     When you talk of linux mainline (and I suppose that the preferred way to work there is yocto) do you mean that there I can find corrected drivers / platform sw for imx233, or that is more stable the kernel itself?

     Thanks

     Alberto

[whitewool]

Hi Otavio, thanks for your support.

Believe me, the reason we still didn't change to Yocto is a real problem of time and resources for this project, which not only is based on the development on imx233, but also on concurrent developments and experimentations in DSP, in fact the device is a mobile one which also act as a controller for a set of other devices. So as you can imagine no way to change now.

We didn't have idea of this situation when we choose imx233, we discovered late, after the first HW prototypes, and patch after patch in short there was no time to switch to another processor. We are just waiting for the final HW in these days. Nevertheless using imx28 is not really the same, due not only to costa but also to to power consumption, that is a bit less in imx233, and it is a real important point.

Coming back to the problem.

2.6.35 seems to me generally more stable and complete. As base kernel and also as freescale sw platform.

To make an example I2c has many corrections with respect to 2.6.31, NAND flash support is extended (and this is important now that Samsung has closed flash production, and Micron is already kikcing off production a lot of models) , OCOTP is supported, and so on.

Now with 2.6.35 i'm still stuck with updater and boot.

I looked at the 2.6.35_10.12.01 branch, and the 2.6.35 ltib i'm using already get all the patches for UBI and UBIFS. And most patches of that branch.

I understand the problem with power supply, they are a bit different with mx28, and imx233 probably has not been tested on that. But this can be repaired easily I think.

But these UBI/UBIFS problems are strange. Code is common for mx23 and mx28 and if for mx28 these problems don't exist it should be ok also for imx233, or the reverse. Or am I wrong?

It is possible that there is a problem in our device, but really don't think so, with 2.6.31 it is regularly updated with MFG, linux runs, and it works (with a lot of patches) even if optimizations are needed.

So a basic help I'd need is really to understand if someone in Freescale already met such a problem for updater and boot, and have some hints about that.

After that I can go verifying all the diffs between the functions i modified in 2.6.31 and apply them to 2.6.35, if needed of course.

Have you suggestions for that?

Thanks

Alberto

[OtavioSalvador]

Yocto takes care of the bootstream generation so you don't worry about it as it done during image generation.

For i.MX23 we currently have imx-bootlets support only but it will change very soon as 2013.04 has our i.MX23 support patches merged in and so U-Boot will be also supported (no imx-bootlets).

My biggest concern about LTIB is image reproducability which is quite important for a product life cycle and not easy to accomplish using LTIB. We do it more easily in Yocto as it cares a lot about host library contamination and support for new host distributions (newer Ubuntu or whatever else you may use).