Samples fails when are loaded using u-boot

[jsanchezv]

Samples fails when are loaded using u-boot

[rsta2]

Circle relies on the initial state set by the firmware in some ways. If u-boot changes this state that's a problem. Because it is easy to reset VBAR on the RPi 1 I have done this in the recent commit so that u-boot can be used as you told (not tested by myself). I'm not sure if this will work on the RPi 2 and 3 in any case but at least it does not disturb normal operation (when loaded by the normal firmware) which I have tested on RPi 1-3.

The alignment configuration is set in lib/memory.cpp on the RPi 1 as required by Circle so it should not be a problem if u-boot modifies it.

Thanks for reporting this!

[jsanchezv]

I've tested the patch on my PI-2 and works flawlessly. When the image is 'mkimage'd with '-O linux -T kernel' or '-O linux -T standalone' and initiated by "bootm" command, the expected environment is found by the image (with the two described exceptions). But when the image is loaded from real binary (not mkimage'd) and started by 'go' command, the initial state is very different: L1 cache enabled, MMU enabled, etc.

ARM documentation for ARMv8 architecture states that VBAR is a register that needs to be correctly configured by an OS at startup. Is strange to me that u-boot restore all the initial configuration except VBAR register. A bug?

[rsta2]

According to the u-boot manual the bootm command should be the right one to start a Circle image. The go command is used to start so-called standalone applications which use service functions provided by u-boot. Circle doesn't do this.

I think there is some room for discussion if u-boot should reset VBAR on its own. I guess the operating systems which are normally loaded using u-boot are setting VBAR on their own and so there is no problem with it. Because Circle is doing the same now I hope there is no problem any more with Circle. According to your test with the RPi 2 I suppose it is working with u-boot now. Thanks for testing this!