What I can remember is that u-boot changes the VBAR register and you need to invalidate the unified TLB on MMU init.
I am still mystified at 3 things:jspeccy wrote: ↑Sun Nov 12, 2017 11:57 amWhat I can remember is that u-boot changes the VBAR register and you need to invalidate the unified TLB on MMU init.
As specified in ARM Cortex-A Series Programmer's Guide (DEN0013D), section 8.8, after disable MMU is needed to invalidate L1-Cache, TLB and branch predictor (point 2 from sample code). U-boot disables the MMU, but don't do any additional action.
Code: Select all
mw.l 0x3f200000 0x04a020 mw.l 0x3f200008 0x65b6c0
regarding your proposal (thanks by the way), i have since moved away from jlink. And given my busy schedule, i hardly get any time for these hobby pursuits.henry10210 wrote:Hope you will be interested in my proposal.
As I reported yesterday, dwelch's armjtag has exactly the SAME PROBLEM with my openocd through J-Link trying to connect to U-Boot. I ordered the FT2232H eval board that is described in the bare-metal README (actually a Chinese knockoff on eBay) so I'll see how that goes. I suspect the problem is on the target end, so FT2232H should exhibit the same problem. Re: U-Boot: My end goal is to enable an AMP (asymmetric multi-processing) on RPi2/3, with the bare-metal FW kicked off as soon as possible after PoR. This means I need a boot loader that can boot multiple cores (I might even run different bare metal on each cores) before booting Linux. U-Boot was the first boot loader I could think of that meets the requirement.
Sorry for my confusion. But isn't raspberry pi's firmware kicking uboot, then uboot kicking your firmware, an unwanted indirection (you can cut that uboot thing) ? Can't you directly use pi's fw (start.elf etc.) to directly run your fw ? (and do whatever amp stuff you want in your fw).henry10210 wrote: My end goal is to enable an AMP (asymmetric multi-processing) on RPi2/3, with the bare-metal FW kicked off as soon as possible after PoR.
Users browsing this forum: bzt and 2 guests