Mity CPU Platforms » MitySOM-335x (ARM Cortex-A8 Based Products)

Timothy Entinger wrote:

Hello,

We were using the 3352-HX-X38-RC part and we have that booting the 4.1 kernel with device tree. We got a batch of 3352-HX-X4A-RC parts in to test on which I am hoping to get booting our 4.1 kernel. I was able to get add support for the larger NAND and DDR parts added to our build of u-boot (2013.01).

Did you get the 1GB DDR timings from our 2013.10 u-boot? Is there some reason you can't use our 2013.10 u-boot?

From what I can see, everything is working great in u-boot. From u-boot I can read the kernel and dtb images into memory and have validated that they are same images that were written to the NAND. When we go to boot the kernel, however, the kernel never even starts to boot. I should say that for the device tree image I did update our NAND mtd partition table to accommodate the larger block sizes, as well as bumping up the size in the memory definition.

Are you loading the kernel image from nand? Could it be getting corrupted? You can try to load the image from tftp and load it from nand and use the 'cmp' command

[...]

We are suspecting the device tree file right now. Especially after adding in the early printk kernel option which didn't give us any logging messages. Can you suggest or do you have a device tree file we can test the 3352-HX-X4A-RC part with?

Have you tried the original device tree with these modules, The memory reg setting should just control what regions of memory the kernel is allowed to access. So the 512MB settings will work on a 1GB module, however you will only have access to the first 512MB. This will atleast prove if you broke the dtb somehow.

It would be helpful to see the full bootlog.

Regards,
Tim Entinger

Did you get the 1GB DDR timings from our 2013.10 u-boot?

Guilty!

Is there some reason you can't use our 2013.10 u-boot?

A long time ago (2013) we were having trouble with ubi and moved to the TI fork of u-boot. We haven't ported back.

You can try to load the image from tftp and load it from nand and use the 'cmp' command

I did this when I was skeptical that I didn't have the larger block size figured out yet. Everything looks good doing the compare in memory.

So the 512MB settings will work on a 1GB module, however you will only have access to the first 512MB. This will atleast prove if you broke the dtb somehow.

I hadn't tried the previous dtb. It behaves the same as the dtb with the memory and nand modifications.

Booting with the 1GB NAND and 1GB RAM dtb

NEW DEVICE TREE
U-Boot# bootm 0x80200000 - 0x80700000
## Booting kernel from Legacy Image at 80200000 ...
   Image Name:   Linux-4.1.18-g6b41ca0b94
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    4390136 Bytes = 4.2 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 80700000
   Booting using the fdt blob at 0x80700000
   Loading Kernel Image ... OK
OK
   Loading Device Tree to bfb45000, end bfb50f04 ... OK

Starting kernel ...

Here's with our previous device tree, setup for 512MB of NAND and 512MB of RAM.

U-Boot# bootm 0x80283000 - 0x8077a000
## Booting kernel from Legacy Image at 80283000 ...
   Image Name:   Linux-4.1.18-g6b41ca0b94
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    4390136 Bytes = 4.2 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 8077a000
   Booting using the fdt blob at 0x8077a000
   Loading Kernel Image ... OK
OK
   Loading Device Tree to bfb45000, end bfb50f04 ... OK

Starting kernel ...

Have you tried the original device tree with these modules?

No. Where can I get this? I poked around the git repositories you have available, but only saw the ones for the 3.2 kernel.

Cheers.

Timothy Entinger wrote:

Did you get the 1GB DDR timings from our 2013.10 u-boot?

Guilty!

Good. Just making sure.

Is there some reason you can't use our 2013.10 u-boot?

A long time ago (2013) we were having trouble with ubi and moved to the TI fork of u-boot. We haven't ported back.

You can try to load the image from tftp and load it from nand and use the 'cmp' command

I did this when I was skeptical that I didn't have the larger block size figured out yet. Everything looks good doing the compare in memory.

Good

So the 512MB settings will work on a 1GB module, however you will only have access to the first 512MB. This will atleast prove if you broke the dtb somehow.

I hadn't tried the previous dtb. It behaves the same as the dtb with the memory and nand modifications.

Booting with the 1GB NAND and 1GB RAM dtb
[...]
That's all we get.

Here's with our previous device tree, setup for 512MB of NAND and 512MB of RAM.
[...]
The BUCK stops here as well.

Have you tried the original device tree with these modules?

No. Where can I get this? I poked around the git repositories you have available, but only saw the ones for the 3.2 kernel.

I was referring to the dtb with the 512MB settings.

Cheers.

I remember a while back I was having a hard time getting the 4.1 and 4.4 kernel booting from our u-boot. I believe I figured out what was going on. Going to quote myself here. Note this problem wasn't related to the 1GB memory part and so may not be relevant but it could be.

Build 4.4 kernel with linaro 5.3.1 toolchain. Kernel also hangs at "Starting kernel".

Enabling earlycon by adding the following to the cmdline.

earlycon=omap8250,0x44e09000,115200n8

Got the following kernel panic

Kernel image @ 0x82000000 [ 0x000000 - 0x84d378 ]
## Flattened Device Tree blob at 80f80000
   Booting using the fdt blob at 0x80f80000
   Loading Device Tree to 9fe0d000, end 9fe1906e ... OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 4.4.27 (jcormier@jcormier-desktop) (gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) ) #3 SMP PREEMPT RT Fri Nov 4 10:44:40 EDT 2016
[    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine model: Critical Link MitySOM-335x Devkit
[    0.000000] earlycon: omap8250 at MMIO 0x44e09000 (options '115200n8')
[    0.000000] bootconsole [omap8250] enabled
[    0.000000] cma: Reserved 48 MiB at 0x9c800000
[    0.000000] Memory policy: Data cache writeback
[    0.000000] On node 0 totalpages: 130560
[    0.000000] free_area_init_node: node 0, pgdat c1084e00, node_mem_map df961000
[    0.000000]   Normal zone: 1152 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 130560 pages, LIFO batch:31
[    0.000000] Unable to handle kernel paging request at virtual address dfe0d000
[    0.000000] pgd = c0004000
[    0.000000] [dfe0d000] *pgd=00000000
[    0.000000] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[    0.000000] Modules linked in:
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.4.27 #3
[    0.000000] Hardware name: Generic AM33XX (Flattened Device Tree)
[    0.000000] task: c0fbf7a8 ti: c0fb4000 task.ti: c0fb4000
[    0.000000] PC is at fdt_check_header+0xc/0x80
[    0.000000] LR is at __unflatten_device_tree+0x88/0x2c8
[    0.000000] pc : [<c0a77964>]    lr : [<c08d5c68>]    psr: 60000093
[    0.000000] sp : c0fb5eb0  ip : c0fb5ec0  fp : c0fb5ebc
[    0.000000] r10: c116d4a0  r9 : c0f56b14  r8 : 80000000
[    0.000000] r7 : dfe0d000  r6 : c0fbafc8  r5 : c0f68450  r4 : c109d7a8
[    0.000000] r3 : 00000000  r2 : c0f56b14  r1 : c116d4a0  r0 : dfe0d000
[    0.000000] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
[    0.000000] Control: 10c5387d  Table: 80004019  DAC: 00000051
[    0.000000] Process swapper (pid: 0, stack limit = 0xc0fb4218)
[    0.000000] Stack: (0xc0fb5eb0 to 0xc0fb6000)
[    0.000000] 5ea0:                                     c0fb5f04 c0fb5ec0 c08d5c68 c0a77964
[    0.000000] 5ec0: c0a7ed78 c0a7f110 c0fb7200 00000000 c0fb5eec dc8ba61b c0a7f110 c0f56b14
[    0.000000] 5ee0: c0f68450 9fdfffff c0fc0cc0 80000000 c1150510 dfdfff00 c0fb5f1c c0fb5f08
[    0.000000] 5f00: c0f57ae4 c08d5bec c0fbafcc c0f68450 c0fb5fa4 c0fb5f20 c0f07c74 c0f57ac0
[    0.000000] 5f20: ffffffff 10c5387d c0f1da08 c00a94dc c0fbafc8 c0cf7f60 c0fbafc8 80000200
[    0.000000] 5f40: c10a2360 c0ff2b70 c0fb5f6c c0fb5f58 c00a951c c00a8d28 c0cf6630 c0fb5f9c
[    0.000000] 5f60: c0fb5f94 c0fb5f70 c01699d8 c00a94e8 c0fb5f9c dc8ba61b c0f27428 00000000
[    0.000000] 5f80: 00002000 c0fbafc8 c0fbafc0 ffffffff 00000000 00000000 c0fb5ff4 c0fb5fa8
[    0.000000] 5fa0: c0f04aa4 c0f07488 00000000 00000000 00000000 00000000 00000000 00000000
[    0.000000] 5fc0: c0f73a28 00000000 00000000 c10a2214 c0fbb044 c0f73a24 c0fc0de4 80004059
[    0.000000] 5fe0: 413fc082 00000000 00000000 c0fb5ff8 8000807c c0f049cc 00000000 00000000
[    0.000000] [<c0a77964>] (fdt_check_header) from [<c08d5c68>] (__unflatten_device_tree+0x88/0x2c8)
[    0.000000] [<c08d5c68>] (__unflatten_device_tree) from [<c0f57ae4>] (unflatten_device_tree+0x30/0x3c)
[    0.000000] [<c0f57ae4>] (unflatten_device_tree) from [<c0f07c74>] (setup_arch+0x7f8/0xc38)
[    0.000000] [<c0f07c74>] (setup_arch) from [<c0f04aa4>] (start_kernel+0xe4/0x454)
[    0.000000] [<c0f04aa4>] (start_kernel) from [<8000807c>] (0x8000807c)
[    0.000000] Code: e89da810 e1a0c00d e92dd800 e24cb004 (e5903000) 
[    0.000000] ---[ end trace 0000000000000001 ]---
[    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!

Playing with beaglebone was able to get our 4.4 kernel to boot with the beaglebone device tree.
Note: Don't try to use a dtb built for a older version of kernel...
Moving back to our maker board, the following in u-boot was needed to get it to boot

run loadbootenv ; run importbootenv
run mmc_args;
setenv autoload no;
setenv fdtaddr 0x88000000
setenv fdt_high 0xFFFFFFFF
dhcp; tftp $fdtaddr am335x-boneblack.dtb; tftp $kloadaddr zImage; bootz $kloadaddr - $fdtaddr;

Setting fdt_high causes u-boot to not move the device tree when bootz is called. And loading the fdt to 0x88000000 worked where 0x80F80000 didn't.

Attached the bootlog for this successful boot I got a while back. maker_44_bootlog.txt

Environment variables for this boot appear to be

setenv kloadaddr 0x80007fc0
setenv fdtaddr 0x88000000
setenv fdt_high 0xFFFFFFFF

I've attached my dts which I created when I was playing around with the 4.1 kernel. Note that we really haven't tested the 4.1 kernel much.

Though I branched it off of TI's processor-sdk-linux-02.00.00 branch when i was testing.
git://git.ti.com/processor-sdk/processor-sdk-linux.git

Booted on a 3352 X4A using the attached files and the following commands:

setenv fdtaddr 0x88000000; setenv fdt_high 0xFFFFFFFF; setenv kloadaddr 0x80007fc0
setenv serverip xx.xx.xx.xxx
dhcp; tftp $fdtaddr am335x-mitysom.dtb; tftp $kloadaddr zImage; bootz $kloadaddr - $fdtaddr

attached bootlog. 4.1_X4A_bootlog.txt

Pushed the 4.1testing branch to the support git repo. https://support.criticallink.com/redmine/projects/armc8-platforms/wiki/41testing_

Note in the above uboot commands. We need to make sure that the bootargs variable is set correctly. In the previous bootlog, the bootargs was empty so it was using the default which was configuring the console to be ttyO2 instead of ttyO0. attached updated boot log with kernel boot output.

setenv bootargs "console=ttyO0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait ip=none" 

Hi Timothy, Did you figure this out?

Hi Jon,

I did try the suggestions made, but I wasn't able to make it any further on the issue. We need to evaluate if u-boot is using the correct jump address to boot the kernel, since we never see any kernel output on the serial line. I have a Lauterbach tool I can setup and use for advanced debugging. This has been postponed due to higher priority tasks coming up since my original posting. If I discover anything on this issue I will post it here.

Thanks for checking up on the status of this issue.

Regards,
Tim Entinger

Did you try using the earlycon I posted above?

earlycon=omap8250,0x44e09000,115200n8