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 On Mar 31, 2015 2:39 AM, "Jeroen Hofstee" jeroen@myspectrum.nl wrote:

Hello noti1234,

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.

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

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,

On Tue, Mar 31, 2015 at 10:03 AM, Jeroen Hofstee jeroen@myspectrum.nl wrote:

Hello Idan,

On 31-03-15 06:02, Idan Noti wrote:

...

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 calls cleanup_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.

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