This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM5708: SDK Upgrade from to 08.02.01.00 - Boot Stuck at "Starting Kernel"

Part Number: AM5708
Other Parts Discussed in Thread: CDCE913, AM5718, PMP

Tool/software:

We are in the process of upgrading our SDK from version 05.03.00.07 to 08.02.01.00 on the TI AM5708 IDK. However, the system hangs at the "Starting kernel..." message during the boot process.

Booting Log:

U-Boot SPL 2021.01-00003-g16d964ac27-dirty (May 02 2025 - 15:09:18 +0000)
DRA722-GP ES2.1
Trying to boot from MMC1
Loading Environment from FAT... *** Warning - bad CRC, using default environment

Loading Environment from MMC... *** Warning - bad CRC, using default environment

U-Boot 2021.01-00003-g16d964ac27-dirty (May 02 2025 - 15:09:18 +0000)

CPU : DRA722-GP ES2.1
Model: TI AM5708 IDK
Board: AM5708 IDK REV
DRAM: 1 GiB
MMC: OMAP SD/MMC: 0
Loading Environment from FAT... *** Warning - bad CRC, using default environment

Loading Environment from MMC... *** Warning - bad CRC, using default environment

invalid mmc device
i2c_write: error waiting for data ACK (status=0x116)
cdce9xx-clk cdce913@65: cdce9xx_reg_write: failed for addr:5, ret:-121
Net: Could not get PHY for ethernet@48484000: addr 0
eth2: ethernet@48484000
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
Failed to load 'boot.scr'
4468 bytes read in 12 ms (363.3 KiB/s)
Loaded env from uEnv.txt
Importing environment from mmc0 ...
Running uenvcmd ...
Failed to load 'newpart_attempt'
Failed to load 'newpart_request'
Failed to load 'PART_A'
Failed to load 'PART_B'
WARNING: Could not find either flag file (PART_A or PART_B). Will boot from PART_A by default
INFO: Booting from partition A (mmcblk0p2)
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
5251584 bytes read in 262 ms (19.1 MiB/s)
144370 bytes read in 21 ms (6.6 MiB/s)
## Flattened Device Tree blob at 88000000
Booting using the fdt blob at 0x88000000
Loading Device Tree to 8ffd9000, end 8ffff3f1 ... OK

Starting kernel ...


At this point, the system stops responding.

However, when we manually load the kernel and device tree from U-Boot using the following commands, the system begins booting partially:

Log:

U-Boot SPL 2021.01-00003-g16d964ac27-dirty (May 02 2025 - 15:09:18 +0000)
DRA722-GP ES2.1
Trying to boot from MMC1
Loading Environment from FAT... *** Warning - bad CRC, using default environment

Loading Environment from MMC... *** Warning - bad CRC, using default environment

U-Boot 2021.01-00003-g16d964ac27-dirty (May 02 2025 - 15:09:18 +0000)

CPU : DRA722-GP ES2.1
Model: TI AM5708 IDK
Board: AM5708 IDK REV
DRAM: 1 GiB
MMC: OMAP SD/MMC: 0
Loading Environment from FAT... *** Warning - bad CRC, using default environment

Loading Environment from MMC... *** Warning - bad CRC, using default environment

invalid mmc device
i2c_write: error waiting for data ACK (status=0x116)
cdce9xx-clk cdce913@65: cdce9xx_reg_write: failed for addr:5, ret:-121
Net: Could not get PHY for ethernet@48484000: addr 0
eth2: ethernet@48484000
Hit any key to stop autoboot: 0
=>
=>
=> ext4load mmc 0:2 0x82000000 /boot/zImage
5251584 bytes read in 227 ms (22.1 MiB/s)
=> ext4load mmc 0:2 0x88000000 /boot/am5708-idk.dtb
144370 bytes read in 15 ms (9.2 MiB/s)
=> bootz 0x82000000 - 0x88000000
## Flattened Device Tree blob at 88000000
Booting using the fdt blob at 0x88000000
Loading Device Tree to 8ffd9000, end 8ffff3f1 ... OK

Starting kernel ...

[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.10.100-g7a7a3af903 (root@useadevbtcvm001) (arm-linux-gnueabihf-gcc (Linaro GCC 7.2-2017.11) 7.2.1 20171011, GNU ld (Linaro_Binutils-2017.11) 2.28.2.20170706) #1 SMP PREEMPT Fri May 2 15:21:49 UTC 2025
[ 0.000000] CPU: ARMv7 Processor [412fc0f2] revision 2 (ARMv7), cr=30c5387d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[ 0.000000] OF: fdt: Machine model: TI AM5718 IDK
[ 0.000000] earlycon: omap8250 at MMIO 0x000000004806a000 (options '')
[ 0.000000] printk: bootconsole [omap8250] enabled
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] efi: UEFI not found.
[ 0.000000] Reserved memory: created CMA memory pool at 0x0000000095800000, size 56 MiB
[ 0.000000] OF: reserved mem: initialized node ipu2-memory@95800000, compatible id shared-dma-pool
[ 0.000000] Reserved memory: created CMA memory pool at 0x0000000099000000, size 64 MiB
[ 0.000000] OF: reserved mem: initialized node dsp1-memory@99000000, compatible id shared-dma-pool
[ 0.000000] Reserved memory: created CMA memory pool at 0x000000009d000000, size 32 MiB
[ 0.000000] OF: reserved mem: initialized node ipu1-memory@9d000000, compatible id shared-dma-pool
[ 0.000000] cma: Reserved 24 MiB at 0x00000000be800000
[ 0.000000] OMAP4: Map 0x00000000afd00000 to (ptrval) for dram barrier
[ 0.000000] Hit pending asynchronous external abort (FSR=0x00001211) during first unmask, this is most likely caused by a firmware/bootloader bug.
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000080000000-0x00000000afcfffff]
[ 0.000000] Normal empty
[ 0.000000] HighMem [mem 0x00000000afd00000-0x00000000bfffffff]

The previous SDK booted automatically without any issues. Could you please advise on possible causes for the current behavior, and how we can configure U-Boot to automatically locate and load the zImage from the root filesystem on partition 2 or 3?

We are using a custom board based on the AM5708 and booting from an SD card. The uEnv.txt file has been attached.

Thank you in advance.

 

#########################################################################################################################################
#
# File: uEnv.txt
# Description: Controls which partition Linux will boot from
# Instructions: Place this file in the root of the boot paritition. It will automatically be processed by the standard Beaglebone uBoot startup
#
# ---------------------------- flag files used  ----------------------------------
# 
# NOTE: Content is arbitrary, but flag files MUST have non-zero length! (from Linux do not use "touch <filename>"; suggested mechanism is "echo 1 > <filename>")
#
# Exactly one of the following two flag files should always present:
# "PART_A" : requested boot is from partion A
# "PART_B" : requested boot is from partion B

# Software upgrade related flag files (these are not "normally" present):
# "newpart_request"  : created by Linux to tell uboot that its next boot is the first attempt of booting into "new" partition
# "newpart_attempt"  : created by uboot after seeing "newpart_request" and just prior to actually attempting booting into the "new" partition
#
# NOTE: except for the creation of "newpart_attempt" noted above, all flag file deleteions and creations are handled by Linux. See doc for details
#
# ---------------------------------------------------------------------------------
#
# ---------------------------- uBoot logic implemented by these commands ---------------------------- 
#
# 1. Check for file "newpart_attempt". If it exists, prev boot attempt must have failed, so boot to the "opposite" partition (using "setpart_reversed")
# **ELSE**
# 2 a. Check for file "newpart_request". If it exists, create file "newpart_attempt" indicating a new "first attempt" about to be tried
#   b. Regardless of result in 2a, boot normally using "setpart_normal"
#
# ---------------------------------------------------------------------------------------------------------


#########################################################################################################################################
#
# code:
#
# strings for various messages appear below
msg_booting_from_a="INFO: Booting from partition A (mmcblk0p2)"
msg_booting_from_b="INFO: Booting from partition B (mmcblk0p3)"
msg_newpart_attempt="INFO: Booting into new partition (first time attempt)"
msg_newpart_fail="WARNING: Previous boot failed, reverting to alternate partition"
msg_file_missing="WARNING: Could not find either flag file (PART_A or PART_B). Will boot from PART_A by default"

# setpart_a: run this to set up booting from partition A by setting "mmcroot" to "/dev/mmcblk0p2" and to setting "bootpart" to "0:2"
setpart_a=echo ${msg_booting_from_a}; setenv mmcroot /dev/mmcblk0p2 ro; setenv bootpart 0:2;

# setpart_b: run this to set up booting from partition B by setting "mmcroot" to "/dev/mmcblk0p3" and to setting "bootpart" to "0:3"
setpart_b=echo ${msg_booting_from_b}; setenv mmcroot /dev/mmcblk0p3 ro; setenv bootpart 0:3;

# setpart_normal: run this to check for existence of non-empty file "PART_A" or "PART_B" and set up to boot from corresponding partition
setpart_normal=if fatload mmc 0:1 ${loadaddr} PART_A; then run setpart_a; elif fatload mmc 0:1 ${loadaddr} PART_B; then run setpart_b; else echo ${msg_file_missing}; run setpart_a; fi;

# setpart_reverse: run this to check for existence of non-empty file "PART_A" or "PART_B" and set up to boot from OPPOSITE partition
setpart_reversed=if fatload mmc 0:1 ${loadaddr} PART_A; then run setpart_b; elif fatload mmc 0:1 ${loadaddr} PART_B; then run setpart_a; else echo ${msg_file_missing}; run setpart_a; fi;

# newcheck: run this to check for the existing flag file "newpart_request". If it is, create a new flagfile named "newpart_attempt".
newcheck=if fatload mmc 0:1 ${loadaddr} newpart_request; then echo ${msg_newpart_attempt}; fatwrite mmc 0:1 ${loadaddr} newpart_attempt 2; fi

# uenvcmd: uenvcmd is a special variable that is automatically run by beaglebone's bootcmd just prior to actually booting
# - running this command implements the entirety or the required partition boot logic by using the various other commands above
uenvcmd=if fatload mmc 0:1 ${loadaddr} newpart_attempt; then echo ${msg_newpart_fail}; run setpart_reversed; else run newcheck; run setpart_normal; fi
#
#########################################################################################################################################

# end-of-file

Thanks,

Mahesh R

  • Hello Mahesh,

    This is a big jump in versions, you are probably going to need to more of a bring up than a migration.

    Have you tried booting our default image with your DTS? How does that one fare?

    If this works correctly it might be a good sanity check.

    Can you post a successful boot with the prior version? 

    Hit pending asynchronous external abort (FSR=0x00001211) during first unmask, this is most likely caused by a firmware/bootloader bug.

    This makes me think that you have an issue in u-boot.

    invalid mmc device
    i2c_write: error waiting for data ACK (status=0x116)
    cdce9xx-clk cdce913@65: cdce9xx_reg_write: failed for addr:5, ret:-121

    Is this present in your prior boot code? Have you checked that all your pmic pin-muxing and DTS assignments are correct?

    -Josue  

  • Hi Josue,

    Previous SDK boot log,

    U-Boot 2018.01-00569-gfd38f5afef-dirty (Oct 29 2019 - 13:17:46 -0700)

    CPU : DRA722-GP ES2.1
    Model: TI AM5708 IDK
    Board: AM5708 IDK REV
    DRAM: 1 GiB
    MMC: OMAP SD/MMC: 0
    *** Warning - bad CRC, using default environment

    SCSI: SATA link 0 timeout.
    AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
    flags: 64bit ncq stag pm led clo only pmp pio slum part ccc apst
    scanning bus for devices...
    Found 0 device(s).
    Net: Could not get PHY for ethernet@48484000: addr 0

    Warning: ethernet@48484000 using MAC address from ROM
    eth0: ethernet@48484000
    Hit any key to stop autoboot: 0
    switch to partitions #0, OK
    mmc0 is current device
    SD/MMC found on device 0
    ** Unable to read file boot.scr **
    4468 bytes read in 3 ms (1.4 MiB/s)
    Loaded env from uEnv.txt
    Importing environment from mmc0 ...
    Running uenvcmd ...
    ** Unable to read file newpart_attempt **
    ** Unable to read file newpart_request **
    ** Unable to read file PART_A **
    ** Unable to read file PART_B **
    WARNING: Could not find either flag file (PART_A or PART_B). Will boot from PART_A by default
    INFO: Booting from partition A (mmcblk0p2)
    switch to partitions #0, OK
    mmc0 is current device
    SD/MMC found on device 0
    4076032 bytes read in 196 ms (19.8 MiB/s)
    98179 bytes read in 31 ms (3 MiB/s)
    ## Flattened Device Tree blob at 88000000
    Booting using the fdt blob at 0x88000000
    Loading Device Tree to 8ffe5000, end 8fffff82 ... OK

    Starting kernel ...

    [ 0.000000] Booting Linux on physical CPU 0x0
    [ 0.000000] Linux version 4.14.79-ge669d52447 (root@useadevbtcvm002) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #1 SMP PREEMPT Thu Jun 23 19:02:24 UTC 2022
    [ 0.000000] CPU: ARMv7 Processor [412fc0f2] revision 2 (ARMv7), cr=30c5387d
    [ 0.000000] CPU: div instructions available: patching division code
    [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
    [ 0.000000] OF: fdt: Machine model: TI AM5718 IDK
    [ 0.000000] Memory policy: Data cache writealloc
    [ 0.000000] efi: Getting EFI parameters from FDT:

    .....

    ...

    the problem on the latest sdk, bootz successfully loads the kernel , but system automatically proceeds the boot. , I've added additional boot debug logs to help with further analysis.  Any suggestions or known fixes would be appreciated.

    8.02.01.00:

    => ls mmc 0:1
    162284 MLO
    1530776 u-boot.img
    4468 uEnv.txt
    131072 uboot.env

    4 file(s), 0 dir(s)

    => ls mmc 0:2
    <DIR> 4096 .
    <DIR> 4096 ..
    <DIR> 16384 lost+found
    <DIR> 4096 bin
    <DIR> 4096 data
    <DIR> 4096 home
    <DIR> 4096 media
    <DIR> 4096 var
    <DIR> 4096 tmp
    <DIR> 4096 lib
    <DIR> 4096 usr
    <DIR> 4096 dev
    <DIR> 4096 sys
    <DIR> 4096 sram
    <DIR> 4096 run
    <DIR> 4096 boot
    <DIR> 4096 proc
    <DIR> 4096 mnt
    <DIR> 4096 sbin
    <DIR> 4096 etc
    <DIR> 4096 flash
    => ext4load mmc 0:2 ${fdtaddr} /boot/am5708-idk.dtb
    144370 bytes read in 16 ms (8.6 MiB/s)
    => fatls mmc 0:2
    ** Unrecognized filesystem type **
    => ext4ls mmc 0:2
    <DIR> 4096 .
    <DIR> 4096 ..
    <DIR> 16384 lost+found
    <DIR> 4096 bin
    <DIR> 4096 data
    <DIR> 4096 home
    <DIR> 4096 media
    <DIR> 4096 var
    <DIR> 4096 tmp
    <DIR> 4096 lib
    <DIR> 4096 usr
    <DIR> 4096 dev
    <DIR> 4096 sys
    <DIR> 4096 sram
    <DIR> 4096 run
    <DIR> 4096 boot
    <DIR> 4096 proc
    <DIR> 4096 mnt
    <DIR> 4096 sbin
    <DIR> 4096 etc
    <DIR> 4096 flash
    => filesize
    Unknown command 'filesize' - try 'help'
    => fdt addr ${fdtaddr}
    => fdt header
    magic: 0xd00dfeed
    totalsize: 0x233f2 (144370)
    off_dt_struct: 0x38
    off_dt_strings: 0x223d0
    off_mem_rsvmap: 0x28
    version: 17
    last_comp_version: 16
    boot_cpuid_phys: 0x0
    size_dt_strings: 0x1022
    size_dt_struct: 0x22398
    number mem_rsv: 0x0

    =>

    Thanks,

    Mahesh R

  • Mahesh,

    I would deal with these issues first: 

    invalid mmc device
    i2c_write: error waiting for data ACK (status=0x116)
    cdce9xx-clk cdce913@65: cdce9xx_reg_write: failed for addr:5, ret:-121

    Is there any diff in your SD card  device-tree setup? are you by chance using a SD XC card (vs a SD HC)?

    Have you checked that all your pmic pin-muxing and DTS assignments are correct?

    -Josue

  • Hi Josue,

    Surprisingly, when I use my old DTB file with the new SDK environment, U-Boot is able to automatically load the DTB and zImage, and the system boots fine .

    However, when I use a new DTB file, it hangs at "Starting kernel" during auto boot. Interestingly, if I load the same kernel and DTB manually from U-Boot, it boots successfully.

    Both DTBs (old and new) seem to boot the kernel at least partially, so that might be a separate issue. But I'm wondering — what could be present or missing in a DTB that would prevent auto boot from working, even though manual boot works?

    Thanks,

    Mahesh R

  • What is the diff?

  • Hi Josue,

    we are having am5708 based custom bard, so our device tree source is derived form from am571x-idk.dts.  A lot of difference in the DTB files between old SDK and new SDK, particularly in,

    node names, sub region, Phandles, path references in /aliases. everything seems have changed significantly.

    for example, 

    New SDK dts:

    / {
    #address-cells = <0x2>;
    #size-cells = <0x2>;
    compatible = "ti,am5718-idk", "ti,am5718", "ti,dra7";
    interrupt-parent = <0x1>;
    model = "TI AM5718 IDK";

    chosen {
    stdout-path = "/ocp/interconnect@48000000/segment@0/target-module@6a000/serial@0";
    };

    aliases {
    i2c0 = "/ocp/interconnect@48000000/segment@0/target-module@70000/i2c@0";
    i2c1 = "/ocp/interconnect@48000000/segment@0/target-module@72000/i2c@0";
    i2c2 = "/ocp/interconnect@48000000/segment@0/target-module@60000/i2c@0";
    i2c3 = "/ocp/interconnect@48000000/segment@0/target-module@7a000/i2c@0";
    i2c4 = "/ocp/interconnect@48000000/segment@0/target-module@7c000/i2c@0";
    serial0 = "/ocp/interconnect@48000000/segment@0/target-module@6a000/serial@0";
    serial1 = "/ocp/interconnect@48000000/segment@0/target-module@6c000/serial@0";
    serial2 = "/ocp/interconnect@48000000/segment@0/target-module@20000/serial@0";
    serial3 = "/ocp/interconnect@48000000/segment@0/target-module@6e000/serial@0";
    serial4 = "/ocp/interconnect@48000000/segment@0/target-module@66000/serial@0";
    serial5 = "/ocp/interconnect@48000000/segment@0/target-module@68000/serial@0";
    serial6 = "/ocp/interconnect@48400000/segment@0/target-module@20000/serial@0";
    serial7 = "/ocp/interconnect@48400000/segment@0/target-module@22000/serial@0";
    serial8 = "/ocp/interconnect@48400000/segment@0/target-module@24000/serial@0";
    serial9 = "/ocp/interconnect@4ae00000/segment@20000/target-module@b000/serial@0";
    ethernet0 = "/ocp/interconnect@48400000/segment@0/target-module@84000/switch@0/ethernet-ports/port@1";
    d_can0 = "/ocp/interconnect@4ae00000/segment@30000/target-module@c000/can@0";
    d_can1 = "/ocp/interconnect@48400000/segment@0/target-module@80000/can@0";
    spi0 = "/ocp/spi@4b300000";
    rproc0 = "/ocp/ipu@58820000";
    rproc1 = "/ocp/ipu@55020000";
    rproc2 = "/ocp/dsp@40800000";
    pruss_iep1 = "/ocp/target-module@4b226000/pruss@0/iep@2e000";
    pruss_iep2 = "/ocp/target-module@4b2a6000/pruss@0/iep@2e000";
    rtc0 = "/ocp/interconnect@48000000/segment@0/target-module@70000/i2c@0/tps659038@58/tps659038_rtc";
    rtc1 = "/ocp/interconnect@48800000/segment@0/target-module@38000/rtc@0";
    display0 = "/connector@0";
    ethernet2 = "/pruss2_eth/ethernet-mii0";
    ethernet3 = "/pruss2_eth/ethernet-mii1";
    };

    Old SDK

    / {
    #address-cells = <0x2>;
    #size-cells = <0x2>;
    compatible = "ti,am5718-idk", "ti,am5718", "ti,dra7";
    interrupt-parent = <0x1>;
    model = "TI AM5718 IDK";

    chosen {
    stdout-path = "/ocp/serial@4806a000";
    };

    aliases {
    i2c0 = "/ocp/i2c@48070000";
    i2c1 = "/ocp/i2c@48072000";
    i2c2 = "/ocp/i2c@48060000";
    i2c3 = "/ocp/i2c@4807a000";
    i2c4 = "/ocp/i2c@4807c000";
    serial0 = "/ocp/serial@4806a000";
    serial1 = "/ocp/serial@4806c000";
    serial2 = "/ocp/serial@48020000";
    serial3 = "/ocp/serial@4806e000";
    serial4 = "/ocp/serial@48066000";
    serial5 = "/ocp/serial@48068000";
    serial6 = "/ocp/serial@48420000";
    serial7 = "/ocp/serial@48422000";
    serial8 = "/ocp/serial@48424000";
    serial9 = "/ocp/serial@4ae2b000";
    ethernet0 = "/ocp/ethernet@48484000/slave@48480200";
    d_can0 = "/ocp/can@4ae3c000";
    d_can1 = "/ocp/can@48480000";
    spi0 = "/ocp/qspi@4b300000";
    rproc0 = "/ocp/ipu@58820000";
    rproc1 = "/ocp/ipu@55020000";
    rproc2 = "/ocp/dsp@40800000";
    ethernet2 = "/pruss2_eth/ethernet-mii0";
    ethernet3 = "/pruss2_eth/ethernet-mii1";
    };

    the structure looks nearly identical, but internally the phandles and lower-level node details differ.

    Could such changes be a reason why auto boot fails with the new DTB, while manual boot still works?

    Any insights or suggestions will hep us 

    vmain, vtt , pmic verified. looks similar with old dts file

    Thanks,

    Mahesh R

  • Hello Mahesh,

    I will look into it this week and try to make suggestions. Based on your experimentation above, it seems like these changes are the cause.

    Is there perhaps a difference in the chosen node?

    -Josue 

  • hi Josue,

    dtb  vlaues in uboot. Yes between this two sdk, chosen nodes are changed. 

    => fdt list /
    / {
    #address-cells = <0x00000002>;
    #size-cells = <0x00000002>;
    compatible = "ti,am5718-idk", "ti,am5718", "ti,dra7";
    interrupt-parent = <0x00000001>;
    model = "TI AM5718 IDK";
    chosen {
    };
    aliases {
    };
    timer {
    };
    interrupt-controller@48211000 {
    };
    interrupt-controller@48281000 {
    };
    cpus {
    };
    opp-table {
    };
    soc {
    };
    ocp {
    };
    thermal-zones {
    };
    pmu {
    };
    fixedregulator-vmain {
    };
    fixedregulator-v3_3d {
    };
    fixedregulator-v1_2d {
    };
    fixedregulator-vtt {
    };
    leds-iio {
    };
    connector@0 {
    };
    encoder@0 {
    };
    src_clk_x1 {
    };
    pruss2_eth {
    };
    ptp_bc {
    };
    memory@80000000 {
    };
    reserved-memory {
    };
    leds {
    };
    idk-leds {
    };
    pruss1_eth {
    };
    };
    => fdt list /chosen
    chosen {
    stdout-path = "/ocp/interconnect@48000000/segment@0/target-module@6a000/serial@0";
    };

    Thanks,

    Mahesh R

  • Mahesh,

    Have you tried the new image in a different SD card?

    Is there any difference in your mmc nodes?

    -Josue

  • Hi Josue,

    After modifying the DTS file with changes related to RTC and Ethernet nodes, the system boots partially. However, it takes more than 2 minutes to load the kernel. Since it is booting, I am closing this thread and planning to open a new one for further discussion.

    Thanks,

    Mahesh R