![]() The 32 bit/64 bit option is only available on the Pi3. I think all the Official Pi O/S are all 32bit mostly because they are supported on all Pi versions. Take my example I gave of using Raspbian with 3 cores that is a 32bit O/S and so you need core 3 running in 32 bit code you can't run it 64 bit. So what is your other core code 32 bit or 64 bit? I haven't looked specifically but I doubt there is very much either way on the speed of interrupt handling.Ī 64bit file is nominally called kernel8.img and the core starts at 0x80000 in 64 bit modeĪ 32 bit file is nominally called kernel8-32.img and the core start at 0x8000 in 32 bit mode There is no real difference for the interrupt most of the difference is starting up the core, the problem is your other cores code will probably either be 32bit or 64bit and as they will kick core3 you need to match it. I have no idea if that is the sort of thing you are doing but it crosses much of the sorts of problems your discussion brings up. Whichever approach you take you need to make sure the two systems do not clash over the same memory or I/O. The most complex alternative would be to share I/O with O/S (say Raspbian) by setting up a special driver on the shared I/O that communicates with your baremetal core3 program. The GPU owns memory and there are baremetal mailbox commands you can ask it to allocate you some of its memory so that is a possible way around the memory problem, the I/O is more problematic. That theoretically leaves core3 parked in the bootstub but then somehow you have to organize Raspbian to agree with a memory block to exclude to run your core3 code in and leave whatever I/O you intend to use alone. Sidebar: I have discussed this in another thread I know that in Raspbian you can control the number of cpu's it uses by editing /boot/cmdline.txt. ![]() Beyond that given the speed you want you just need to make sure you bring Core3 up to full speed (it starts at a slower default) and make sure you bring at least the Branch prediction and Data cache online (although the full level 2 cache would be better but complex). Assuming your O/S kicks thru the normal bootsub loader Core3 will be sleeping parked like normal in the bootstub. It sounds like your other 3 core will be running something like an O/S and so you will need to kick core3 from there and somehow have organization what memory and I/O stuff belongs to core3 so you don't conflict. The core3 starting is really the only bit you will have to work out with its bootstub. That is proof of principle that what you want is possible. My advice is just use one of the samples in baremetal first and get it doing what you want (the samples will all be core0). Given your speed you might as well use any of the FIQ examples which will be a little faster in response time. Take any of the samples set the frequency of operation up to what you want and replace the LED flashing code with what you want it to do. Your question is puzzling the only reason they blink the LED slow is so you can physically see it's blinking if you did it at speeds you are talking it would look like the LED is solid on AKA "you wouldn't know the demo is working".Īs for the endless loop well you have to have the core doing something while you wait for the interrupt and as you have nothing else to do in the demo all you can do is loop it.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |