[U-Boot] Xilinx Zed Board resets with Master

[Michal Simek <monstr@monstr.eu>]

Hi Tim,

On 03/28/2014 04:20 PM, Tim Sander wrote:
> Hi Michal
>> On 03/27/2014 05:32 PM, Tim Sander wrote:
>>> Hi Michal
>>>
>>> Am Donnerstag, 27. M?rz 2014, 14:17:41 schrieb Michal Simek:
>>>>>>>> Please check and may be you can try u-boot-dtb.elf.
>>>>>>>
>>>>>>> Mh,  don't know how to create this kind of file?
>>>>>>
>>>>>> Jagan maybe knows more but I don't think u-boot-dtb.elf is generated.
>>>>>> Just u-boot-dtb.bin is generated which should be copied as data file
>>>>>> in xmd and not sure if binary file can be directly used for bootgen.
>>>
>>> If adding the dtb file in the boot.bif file is not the right way and no
>>> elf file with dtb is generated: What is the right way to generate an
>>> image for use with the SD-Card?
>>
>> you can just use static u-boot configuration.
> I assume you mean static configuration a config with OF_CONTROL disabled.
> Ok, i have tried to boot that with bootgen. That does not work.
> Loading that into memory and booting it from within the debugger works
> though. In both cases with or without OF_CONTROL enabled.

ok. I am not using bootgen that's why good that you have
at least one config which is working. Feel free to use xilinx
u-boot from github which is synchronized with mainline code.

>> I have never tried to add dtb as partition to boot.bin.
>> If you want to use this dtb driver u-boot I would suggest you
>> to look at u-boot SPL which should be able to handle binary formats
>> with dtbs.
> So my main focus is to test CONFIG_ARMV7_NONSEC to boot linux in 
> normal mode. I wanted to test recent mainline with that. So focusing on 
> u-boot SPL is to far off my targets. So i am happy with hardware debugger 
> loadeing for the time beeing.

ok.

> Getting back to CONFIG_ARMV7_NONSEC. This is unfortunatly not working with the 
> Zynq.  Currently the board switches to monitor mode but when the u-boot 
> switches to normal mode it jumps to PC:0xc  (LR:0x10) which seems like a data 
> abort exeption or some other secure mode violation exception?
> Is there a good way to find out what happened? I am currently stuck with this 
> and my local FAE has also no idea. Attached is a patch which at least works 
> until the return from the monitor mode.

yes I know. I have got an email from you some days ago but haven't answered it yet.
I haven't played with it but at least I am aware about the code which is working
on zynq.
Look at this repo
https://github.com/serngawy/OpenVirtualization
it is secure monitor code which does exactly what you have described
switching from monitor mode to normal mode.

Albert could know more about proper u-boot behaviour how this should be handled.

Thanks,
Michal



-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140401/769deb2a/attachment.pgp>