Can't boot DaVinci EVM with Green Hills' Integrity OS
I'm having problems booting my DaVinci board with Green-Hills' Integrity OS. My setup is:
Hardware: TI's DaVinci EVM:
http://www.spectrumdigital.com/product_info.php?products_id=192
u-boot: u-boot-2015.4-rc3. Configured for dvevm with elf support.
* If the board's flash is programmed with u-boot then the Integrity OS initialization process gets stuck.
* If the board's flash is erased (which means I get BOOTME BOOTME requests) then the Integrity OS initialization process, using Green Hills probe (something like JTAG), works fine.
This behavior is strange. It seems that something in the u-boot initialization process, messes up something for the Integrity OS to run smoothly.
To make things clearer:
The u-boot works fine before trying to boot the Integrity OS elf. I can read memory regions, write, tftp, etc.
The problem is that the init process of the Integrity OS gets stuck. So currently I can only boot the board using the Green Hills probe, when the flash has no boot loader.
Do you have any idea how to approach this problem? Any way to debug it?
Thanks
--
View this message in context: http://u-boot.10912.n7.nabble.com/Can-t-boot-DaVinci-EVM-with-Green-Hills-Integrity-OS-tp210010.html
Sent from the U-Boot mailing list archive at Nabble.com.
Hello noti1234,
Quoted 16 lines · On 30-03-15 20:44, noti1234 wrote:
I'm having problems booting my DaVinci board with Green-Hills' Integrity OS. My setup is:
Hardware: TI's DaVinci EVM:
http://www.spectrumdigital.com/product_info.php?products_id=192
u-boot: u-boot-2015.4-rc3. Configured for dvevm with elf support.* If the board's flash is programmed with u-boot then the Integrity OS initialization process gets stuck.
* If the board's flash is erased (which means I get BOOTME BOOTME requests) then the Integrity OS initialization process, using Green Hills probe (something like JTAG), works fine.This behavior is strange. It seems that something in the u-boot initialization process, messes up something for the Integrity OS to run smoothly.
Quoted 9 lines
To make things clearer:
The u-boot works fine before trying to boot the Integrity OS elf. I can read memory regions, write, tftp, etc.
The problem is that the init process of the Integrity OS gets stuck. So currently I can only boot the board using the Green Hills probe, when the flash has no boot loader.Do you have any idea how to approach this problem? Any way to debug it?
I have no knowledge of your actual setup, but it might be worth checking if disabling caches at compile time helps (in your boards config or perhaps menuconfig nowadays).
Regards,
Jeroen
Why do you think caches have something to do with the problem?
Also, how do I config the compilation to disable caches? The only configuration I'm aware about it modifying the header file:
$(uboot_folder)/include/configs/davinci_dvevm.h
Thanks
Quoted 43 lines · Jeroen Hofstee
Hello noti1234,
Quoted 27 lines · On 30-03-15 20:44, noti1234 wrote:
I'm having problems booting my DaVinci board with Green-Hills' Integrity OS.
My setup is:
Hardware: TI's DaVinci EVM:
http://www.spectrumdigital.com/product_info.php?products_id=192
u-boot: u-boot-2015.4-rc3. Configured for dvevm with elf support.* If the board's flash is programmed with u-boot then the Integrity OS initialization process gets stuck.
* If the board's flash is erased (which means I get BOOTME BOOTME requests)
then the Integrity OS initialization process, using Green Hills probe (something like JTAG), works fine.This behavior is strange. It seems that something in the u-boot initialization process, messes up something for the Integrity OS to run smoothly.
To make things clearer:
The u-boot works fine before trying to boot the Integrity OS elf. I can read
memory regions, write, tftp, etc.
The problem is that the init process of the Integrity OS gets stuck. So currently I can only boot the board using the Green Hills probe, when the
flash has no boot loader.Quoted 3 lines
Do you have any idea how to approach this problem? Any way to debug it?
I have no knowledge of your actual setup, but it might be worth checking if disabling caches at compile time helps (in your boards config or perhaps menuconfig nowadays).
Regards,
Jeroen
Hello Idan,
Quoted 1 line · Idan Noti
Why do you think caches have something to do with the problem?
By booting the image with the bootelf command you jump to it with some caches
still enabled / not flushed (which is likely not what your debug interface does and
your kernel might not really like that). A FreeBSD kernel doesn't / didn't at least and
wouldn't boot.
I never checked, but I guess Linux doesn't like it either, but since it is typically booted
by a bootm / bootz command it goes through e.g. arch/arm/lib/bootm.c, which callscleanup_before_linux in arch/arm/cpu/arm926ejs/cpu.c, all caches are disables and
flushes before jumping into it.
Of course I don't know if this is related to your problem, but it cannot do any harm to
keep caches off until you have the board properly booting.
Quoted 3 lines
Also, how do I config the compilation to disable caches? The only configuration I'm aware about it modifying the header file:
$(uboot_folder)/include/configs/davinci_dvevm.h
Yup, see README and doc/README.arm-caches. At least below knobs are documented.
You can simply define these in mentioned file.
CONFIG_SYS_ICACHE_OFF - Do not enable instruction cache in U-Boot CONFIG_SYS_DCACHE_OFF - Do not enable data cache in U-Boot CONFIG_SYS_L2CACHE_OFF- Do not enable L2 cache in U-Boot
Regards,
Jeroen
I'v tried this but it does not change anything.
Is there a way to have the u-boot run in a step-by-step mode? In order to try and eliminate the problematic initialization?
Thanks,
Quoted 43 lines · Jeroen Hofstee
Hello Idan,
Quoted 2 lines · Idan Noti
Why do you think caches have something to do with the problem?
By booting the image with the bootelf command you jump to it with some caches
still enabled / not flushed (which is likely not what your debug interface does and
your kernel might not really like that). A FreeBSD kernel doesn't / didn't at least and
wouldn't boot.I never checked, but I guess Linux doesn't like it either, but since it is typically booted
by a bootm / bootz command it goes through e.g.arch/arm/lib/bootm.c, which callscleanup_before_linuxinarch/arm/cpu/arm926ejs/cpu.c, all caches are disables and
flushes before jumping into it.Of course I don't know if this is related to your problem, but it cannot do any harm to
keep caches off until you have the board properly booting.Also, how do I config the compilation to disable caches? The only
Quoted 3 lines
configuration I'm aware about it modifying the header file:
$(uboot_folder)/include/configs/davinci_dvevm.hYup, see README and doc/README.arm-caches. At least below knobs are documented.
You can simply define these in mentioned file.
CONFIG_SYS_ICACHE_OFF- Do not enable instruction cache in U-BootCONFIG_SYS_DCACHE_OFF- Do not enable data cache in U-Boot CONFIG_SYS_L2CACHE_OFF- Do not enable L2 cache in U-BootRegards,
Jeroen