tag:blogger.com,1999:blog-4032020337247582619.post4187515113627907938..comments2024-03-08T01:27:20.721-08:00Comments on Henry Choi: Zynq AMP: Linux on CPU0 and bare metal on CPU1Henry Choihttp://www.blogger.com/profile/02148182819821205330noreply@blogger.comBlogger45125tag:blogger.com,1999:blog-4032020337247582619.post-42502831178563254592018-04-07T12:22:21.378-07:002018-04-07T12:22:21.378-07:00I am a new user of this site so here i saw multipl...I am a new user of this site so here i saw multiple articles and posts posted by this site,I curious more interest in some of them hope you will give more information on this topics in your next articles. <a href="www.metalform.com.au/product-category/metal-forming-solutions/presses/" rel="nofollow">power presses </a><br />Faiza_Hackshttps://www.blogger.com/profile/16963072174179096926noreply@blogger.comtag:blogger.com,1999:blog-4032020337247582619.post-61013628032764600942015-12-09T06:48:45.829-08:002015-12-09T06:48:45.829-08:00Thanks for the update Diwakar,
I am trying to lear...Thanks for the update Diwakar,<br />I am trying to learn u-boot these days. Did you write up anything about how you loaded your own RTOS (and then Linux) in u-boot? It would be great if you can share it.Henry Choihttps://www.blogger.com/profile/02148182819821205330noreply@blogger.comtag:blogger.com,1999:blog-4032020337247582619.post-5198936168721312632015-12-09T01:19:19.983-08:002015-12-09T01:19:19.983-08:00Hello Henry,
Now I am able to load RTOS from u-boo...Hello Henry,<br />Now I am able to load RTOS from u-boot and able to send first CAN message within 370ms before linux bootsup. As you suggested I have modified remoteproc/rpmsg framework and able to exchange the CAN data between from RTOS to Linux. Thanks a lot for your help that I got from all your posts about zynq hardware. Without that it would have taken more time than expected. Now I will try message queues and other solutions as suggested by you to make it simple.<br />Best regards,<br />Diwakar ReddyAnonymoushttps://www.blogger.com/profile/09741578440009834128noreply@blogger.comtag:blogger.com,1999:blog-4032020337247582619.post-82101636750353739872015-11-03T20:01:34.786-08:002015-11-03T20:01:34.786-08:00I assume you are talking aThat's brilliant! P...I assume you are talking aThat's brilliant! Perhaps the bare metal app running in the FSBL can send some signal to the rest of the system that it is healthy.<br /><br />But when I thought about it again, I wondered if Diwakar's system could tolerate not hearing back from the ARM CPU for the at least few seconds it takes to boot Linux and then start the CPU1 bare metal app through the zynq_remoteproc.Henry Choihttps://www.blogger.com/profile/02148182819821205330noreply@blogger.comtag:blogger.com,1999:blog-4032020337247582619.post-43371220741872276332015-11-03T19:57:40.988-08:002015-11-03T19:57:40.988-08:00Should I assume that your blinker app works in a s...Should I assume that your blinker app works in a stand-alone configuration? If you read the comments of some of the people who had the same problem, getting the CPU1 load address consistently everywhere can be challenging.Henry Choihttps://www.blogger.com/profile/02148182819821205330noreply@blogger.comtag:blogger.com,1999:blog-4032020337247582619.post-59554147092717407252015-11-03T05:34:01.087-08:002015-11-03T05:34:01.087-08:00I have followed above instructions and I have the ...I have followed above instructions and I have the same environment (petalinux 2014.4 + zed-board). I changed zynq_cpun_start(0x1fe00000,1). When I modprobe, zynq_remoteproc, I get message saying CPU1 is now up. I don't know if to trust that, as I do not get LED blinked. I also added a bit of code from xapp1078, to increment a variable in OCM, but it's not changing either. In short, I don't think processor 2 is running.GKhttps://www.blogger.com/profile/05805382342280568648noreply@blogger.comtag:blogger.com,1999:blog-4032020337247582619.post-24322053359702287832015-11-02T06:58:33.259-08:002015-11-02T06:58:33.259-08:00If you want to stick with linux on cpu0, you can d...If you want to stick with linux on cpu0, you can do some processing in Zynq First stage bootloader, which loads uboot.<br />GKhttps://www.blogger.com/profile/07030434066743651880noreply@blogger.comtag:blogger.com,1999:blog-4032020337247582619.post-21983165733481664762015-11-02T06:57:50.429-08:002015-11-02T06:57:50.429-08:00This comment has been removed by the author.GKhttps://www.blogger.com/profile/07030434066743651880noreply@blogger.comtag:blogger.com,1999:blog-4032020337247582619.post-53207195506605624322015-10-17T20:17:42.037-07:002015-10-17T20:17:42.037-07:00Hi Henry,
Thanks a lot.
In fact, if the ECU(zynq c...Hi Henry,<br />Thanks a lot.<br />In fact, if the ECU(zynq controller) does not respond within 500 ms, vehicle network assumes that it is not available because it has to send some diag messages. I would like to try the solution suggested by you..booting rtos on cpu0 and then Linux on cpu1 and then using OCM for communication. I went through the uboot code and I felt it is possible to do it that way. I will post it here once it is done.<br />Best regards,<br />Diwakar reddyAnonymoushttps://www.blogger.com/profile/09741578440009834128noreply@blogger.comtag:blogger.com,1999:blog-4032020337247582619.post-23346422324661792902015-10-17T11:26:37.565-07:002015-10-17T11:26:37.565-07:00In that case, you should NOT use the remote proc f...In that case, you should NOT use the remote proc framework. You should instead figure out booting your own RTOS FIRST from U-Boot, and THEN proceeding to boot Linux. It might just be easier to run your RTOS on CPU0. RTOS <--> Linux comm over OCM doesn't have to be complicated; see my other post on that topic: http://henryomd.blogspot.com/2015/04/amp-state-machine-applications-on-zynq.html<br /><br />I haven't looked deeply into U-Boot, but figuring that out will be an entirely another challenge for you. I suppose you are really sure about the requirement of the RTOS having to control your car within a few ms, because if you could wait a few seconds, you could potentially just use my solution. Consider that a full blown Chromebook cold boots in < 10. Waking back up from sleep is like a second or two. Would a customer really want to drive a car within 2 second of pressing the power button?Henry Choihttps://www.blogger.com/profile/02148182819821205330noreply@blogger.comtag:blogger.com,1999:blog-4032020337247582619.post-32135897491771035632015-10-16T01:01:39.207-07:002015-10-16T01:01:39.207-07:00Hi Henry,
Many thanks for your reply..
I am worki...Hi Henry,<br /><br />Many thanks for your reply..<br />I am working on a solution where I am using Automotive RTOS that should communicate with the vehicle CAN network within few milliseconds. That is the reason I am starting RTOS fort on core1. Once linux boots up, it has to inform RTOS that it is up and based on the request from linux, RTOS can share vehicle data, then linux sends it to the reast of the world or even display it to the driver.<br /><br />I am new to this remoteproc framework. Based on my scenarion as explained above, if you can give some inputs on how and where do I need to update the rpmsg modules to remove the dependency on remoteproc. Is it in Zynq_remoteproc module where we setup interrupts? Or can I remove the remoteproc completely from loading it.?<br /><br />Best regards,<br />Diwakar ReddyDiwakarhttps://www.blogger.com/profile/17520541439174317946noreply@blogger.comtag:blogger.com,1999:blog-4032020337247582619.post-75390655277400314852015-10-15T21:46:11.213-07:002015-10-15T21:46:11.213-07:00If you will NEVER restart CPU1 app, then you don&#...If you will NEVER restart CPU1 app, then you don't need remoteproc--if you can avoid the dependency of rpmsg on remoteproc. I should think that you can design your own message format and just stay away from the whole remoteproc infrastructure.<br /><br />I am curious: why do you HAVE to start bare metal first?Henry Choihttps://www.blogger.com/profile/02148182819821205330noreply@blogger.comtag:blogger.com,1999:blog-4032020337247582619.post-69512415128125989772015-10-15T21:13:23.811-07:002015-10-15T21:13:23.811-07:00Hello Mr.Henry
Very nice post. Thank you very much...Hello Mr.Henry<br />Very nice post. Thank you very much. I am working on similar solution but I want to start cpu1 from uboot. So before Linux boots up my secondary core is already running. I want to use onlr rpmsg for communication between the cores. Do I still need remoteproc?Anonymoushttps://www.blogger.com/profile/09741578440009834128noreply@blogger.comtag:blogger.com,1999:blog-4032020337247582619.post-83038846630978892952015-06-19T11:39:59.093-07:002015-06-19T11:39:59.093-07:00Hi Henry,
Thanks a lot for all this extremely val...Hi Henry,<br /><br />Thanks a lot for all this extremely valuable information!<br /><br />I've adapted XAPP1078 and your instructions to Vivado 2015.1 and the Red Pitaya board:<br /><br />https://github.com/pavel-demin/red-pitaya-notes/tree/master/projects/bare_metal_test<br /><br />Cheers,<br /><br />Pavel<br />Anonymoushttps://www.blogger.com/profile/04556039139361499567noreply@blogger.comtag:blogger.com,1999:blog-4032020337247582619.post-77574979160989310792015-06-13T18:30:41.906-07:002015-06-13T18:30:41.906-07:00thanks for your quick reply!
why to the adi kerne...thanks for your quick reply!<br /><br />why to the adi kernel branch? <br />i refered to your own github repo... so that people can directly try out the code samples, what do you think?<br /><br />how much effort is it to adapt your vivado 2014 to 2015.1 changes...any experience? and later on remove the sdk dependency?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4032020337247582619.post-29286387738206197292015-06-13T11:59:12.508-07:002015-06-13T11:59:12.508-07:00Probably inadequate answer to your questions:
1. ...Probably inadequate answer to your questions:<br /><br />1. No github. I'd rather push my zynq_remoteproc mods to the ADI kernel branch, but they actually want to mainline their work, so I don't know how things will shake out. I don't think I have enough visibility with the ADI/Xilinx kernel developers (Lars, Michal, etc) to even send a pull request. In the past, when they convinced themselves about the argument I made, they would just make the change on their end. I don't see the benefit of making a github project for a blinking light bare metal code running at DRAM 0x1fd00000 (510 MB)--started by the zynq_remoteproc. My "up" file addition is such an easy change for anyone. I COULD put out my diff file, but then you would have to know how to apply the patch to YOUR kernel, OR know how to use something like Buildroot/Yocto. In short, I expect my project will be applicable to myself only, as everyone else will have his own setup, and can read my blog entries to quickly figure out what he needs to do.<br /><br />2. Vivado 2015.1: good luck; I am stuck on 2014.4 because my EE and SW colleagues are on 2014.4.<br /><br />3. No SDK route: probably possible, but not interested in figuring it out right now. I want to know if you get that working.Henry Choihttps://www.blogger.com/profile/02148182819821205330noreply@blogger.comtag:blogger.com,1999:blog-4032020337247582619.post-61380967879900059802015-06-13T11:47:24.666-07:002015-06-13T11:47:24.666-07:00Hi Eric, I think only someone like Linus Torvalds ...Hi Eric, I think only someone like Linus Torvalds can make credible appraisal about the quality of kernel modules. I learned from the freeelectron slides that the Linux community has invisible walls, and it takes time and effort to get into the community--which may be worth the effort if one will continue to engage with the Linux kernel/driver codes. A few people at Xilinx, ADI, and TI are probably already in that select group. To application people like us, all the bells and whistles that these talented people throw into the kernel and any module/driver may seem excessive at times. I think of the situation similar to how the AI community was dominated (hijacked?) by mathematicians for decades until fairly recently: it is unfortunate, but individuals like me can only hope to selectively derive whatever benefit I can, after (heavy) filtering of their work. Applied to the current zynq_remoteproc module, I don't think it will become much simpler unless TI and ADI wants to give up the idea of setting up their DSPs completely through this module. I tend to get into arguments with (high level) SW because I keep pushing them to abandon (what I consider) unnecessary features, but starting a few years ago, my new strategy is avoid the unproductive arguments and just to do the whole thing myself--the way I think it can be done (meaning: minimally). That is why I am not going to spend more time on this kernel module, because I am busy working on the lower level (FPGA and sensors) and the high level (image processing and UI) by myself.<br /><br />To answer your direct question, when you Google for the remoteproc, there isn't much hit. I actually corresponded with another engineer (I think the link is in this blog somewhere) who wrote YET another kernel module, to use this remoteproc module with his TI DSP. I would be interested in finding out how many people out there actually use this kernel module the way TI/ADI/Xilinx thought it would be used; I suspect not many.Henry Choihttps://www.blogger.com/profile/02148182819821205330noreply@blogger.comtag:blogger.com,1999:blog-4032020337247582619.post-4191057189633580842015-06-12T15:22:38.230-07:002015-06-12T15:22:38.230-07:00Hello Henry,
I would like to use Ubuntu Linux on ...Hello Henry,<br /><br />I would like to use Ubuntu Linux on Core0 and Bare Metal on Core1. Do you have your project files uploaded to github? I also would like to use vivado 2015.1 and build the SW without the SDK, just via make (+ Makefile). Is that possible?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4032020337247582619.post-33846461596113184812015-06-11T14:11:42.979-07:002015-06-11T14:11:42.979-07:00Henry, why do you suppose it is that the zynq_remo...Henry, why do you suppose it is that the zynq_remoteproc module doesn't work as provided by Xilinx? To actually start running the firmware, you had to add the work queue stuff and/or the "up" attribute. Is it just alpha quality software? It's been around for at least 3 years now, so it surely must be working for others as is.Ericnoreply@blogger.comtag:blogger.com,1999:blog-4032020337247582619.post-31349562787899982222015-06-08T09:40:53.701-07:002015-06-08T09:40:53.701-07:00So I finally got my cpu1app to work! It turns out...So I finally got my cpu1app to work! It turns out in the zynq_remoteproc module, zynq_rproc_start() calls zynq_cpun_start(0,1). I had to change that to zynq_cpun_start(0x1fe00000,1) so that CPU1 would start at the correct address. I suppose THAT'S why the memory remapping MMU code was in boot.S. But thank you Henry for this blog post and all your help in the comments.Ericnoreply@blogger.comtag:blogger.com,1999:blog-4032020337247582619.post-25365609061398067522015-06-07T06:56:24.273-07:002015-06-07T06:56:24.273-07:00It uses a trampoline mechanism too. I didn't ...It uses a trampoline mechanism too. I didn't look into all that much detail once I got my CPU1 application booted up. It may be helpful for you to take a look at my CPU1 startup.S and ldscript, but I hesitate because I only enable 1 interrupt (IRQ) besides the boot. Have a look at this if you just want to do what I did and move on: http://henryomd.blogspot.com/2015/03/porting-qpcpp-to-zynq-amp-cpu1.htmlHenry Choihttps://www.blogger.com/profile/02148182819821205330noreply@blogger.comtag:blogger.com,1999:blog-4032020337247582619.post-10387611653512071542015-06-07T02:26:21.297-07:002015-06-07T02:26:21.297-07:00Please don't apologize, I appreciate your pati...Please don't apologize, I appreciate your patience with me and having someone to bounce ideas off of. Your GoToMeeting offer is incredibly kind, but I'm not at the end of my rope yet, though I hope I can reserve it for when I am! =) To help your understandable confusion, I am not really debugging anything with the debugger, just looking at the CPU states and the general vicinity of the PC when I halt it. That's how I discovered CPU1 gets suspended whenever I did a modprobe zynq_remoteproc. <br /><br />I tend to think the MMU translation errors are not the cause of my problem anymore because I studied XAPP1079 and XAPP1078 a lot more in-depth and found some discrepancies in my boot.S. The boot.S in those app notes modified not only the MMU settings, but also the very start of boot.S, adding some cpu0_catch/cpu1_catch mechanism to determine where to jump to based on which CPU is running. I didn't have that in my boot.S and that led me to find some issues related to that. I don't know how this can happen because it is using a BSP for ps_1, but it looks like my cpu1app was somehow compiled with XPAR_CPU_ID = 0, so when it runs the boot code, it will only let CPU0 continue, but since it's running on CPU1, it gets branched to an endless WFE loop. I think this may be the cause of the CPU1 suspension I'm seeing. I figured this out debugging the XAPP1079 bare-metal/bare-metal configuration though and fixed it (by getting rid of that CPU check code). I was so sure this would also fix my Linux/bare-metal AMP problems, but CPU1 is still getting suspended once I do modprobe zynq_remoteproc on the Linux/bare-metal AMP configuration. I ran out of time before the weekend to verify the fixed boot code was used, but I'm pretty sure it was. I hope to figure this out or find out more on Monday.<br /><br />Do you know exactly how zynq_remoteproc gets CPU1 to start execution at the cpu1app elf start address? When Linux releases CPU1, what does CPU1 then do? I imagine Linux has to somehow tell it an address at which to start execution. I know on entire system reset, CPU1 looks for non-zero address at 0xFFFF_FFF0 to jump to. I wonder if the same happens if only CPU1 is reset and zynq_remoteproc just resets CPU1 and writes the cpu1app elf address to 0xFFFF_FFF0, but then again, I don't think it can because that whole process on entire system reset puts a bit of boot code in the upper reaches of OCM for CPU1 to use (put there by the boot ROM), so there's no guarantee OCM is not in use by the time Linux is up and running.Ericnoreply@blogger.comtag:blogger.com,1999:blog-4032020337247582619.post-43133637171675059522015-06-06T20:05:07.178-07:002015-06-06T20:05:07.178-07:00Hi Eric, sorry I was pounding away on my own proje...Hi Eric, sorry I was pounding away on my own project, trying to beat Vivado and QtCreator into submission.<br /><br />I think got the same error you did, but I think it's expected: if you followed my (originally John McDougall's code) CPU1 bootup code turns off L2 cache for the CPU1's portion of the DRAM, and the OCM cacheing is turned off altogether. I guess I don't understand what you are trying to debug here. The JTAG debugger is finnicky (but even that is better than the gdb software debugger); when I was bringing up my system, I found that I had to HALT CPU1 before I could set HW breakpoint that actually break--most of the time. Often, xsdk on Ubuntu would just hang, and I have to restart it. As a last resort, I will move around an infinite loop in an startup.S, or my C program, and try to bisect the problematic code. I ASSUME you've seen my other blog entry on low level JTAG debugging: http://henryomd.blogspot.com/2014/10/ways-to-study-linux-kernel-and-driver.html<br /><br />Restrictlying debugger scope to only CPU1 may help, as well as deleting the symbol file and attaching it to a HALTED CPU1. I don't know how else to help you other than sitting down together over a GoToMeeting. But have hope; I found the low level difficult at first, but after I settled on a repetitive process, it has been pretty stable for me.Henry Choihttps://www.blogger.com/profile/02148182819821205330noreply@blogger.comtag:blogger.com,1999:blog-4032020337247582619.post-82147628057238705202015-06-05T00:16:15.969-07:002015-06-05T00:16:15.969-07:00I'm still pounding away at this. I was able t...I'm still pounding away at this. I was able to get the Xilinx debugger attached. Found out as soon as I do modprobe zynq_remoteproc, CPU1 gets suspended, with a stack trace at addresses 0xffff0010 and 0xffff000c. I also found when I try to view memory at 0x1fe00000 or 0xffff000c, I get "MMU section translation fault". Sometimes I get "Data read abort, Fault status 0x5, domain 0xE" for 0x1fe00000. Assuming the fault status is from the Data Fault Status Register, 0x5 means First Level Translation MMU Fault. I take this to mean something is wrong with my MMU configuration. Maybe Linux is still protecting memory at 0x1fe00000? I do have your changes in boot.S. And I don't know why cpu1app goes to OCM at those 0xffffxxxx addresses, but maybe that's moot because of the MMU config. <br /><br />Anyway, I think CPU1 isn't able to read the cpu1app elf because of some MMU misconfiguration or protection still in place. Would appreciate any thoughts you might have on where to go with this.Ericnoreply@blogger.comtag:blogger.com,1999:blog-4032020337247582619.post-21718553518898744212015-05-26T13:08:01.854-07:002015-05-26T13:08:01.854-07:00As far as I can tell, the code is executing. From...As far as I can tell, the code is executing. From the Linux CPU0 side, remoteproc is reporting success in loading firmware and booting CPU1, and the rproc state is RUNNING. I don't have any direct insights into the CPU1 side though so far. I was thinking of getting the debugger attached to the running CPUs and see what CPU1 is doing, which is probably a whole exercise in of itself. <br /><br />On the custom zynq board I'm using, there is one lone PS GPIO not connected to anything that I might be able to get at though and I am considering doing exactly as you said at this point. All of the other PS MIO pins are used for USB, ethernet, etc. But my cpu1app is also driving PS UART0 now, and no activity there either (I set ps7_uart_0 as compatible="invalid" in the device tree. Does that make Linux ignore it so it's free for CPU1 to use?). Ericnoreply@blogger.com