On Thu, Dec 20, 2012 at 12:23:48PM +0000, Jon Medhurst (Tixy) wrote: > On Fri, 2012-12-14 at 15:54 +0000, Jon Medhurst (Tixy) wrote: > > On Fri, 2012-12-14 at 10:10 -0500, Christoffer Dall wrote: > > > On Fri, Dec 14, 2012 at 3:49 AM, Jon Medhurst (Tixy) <t...@linaro.org> > > > wrote: > > > > On Thu, 2012-12-13 at 13:52 -0800, Christoffer Dall wrote: > > > >> On Friday, December 7, 2012, Jon Medhurst (Tixy) wrote: > > > >> > > > >> > To enable CPU hotplug the need to provide some boot code at the > > > >> reset > > > >> > vector and which survives after the kernel has booted without being > > > >> > overwritten. We achieve this by the getting the linker script to > > > >> place > > > >> > the code in boot.S at address zero. This now means we can delete the > > > >> > code that relocates the secondary CPU pen code to "a location less > > > >> > likely to be overridden". > > > >> > > > > >> > > > >> not knowing these dev boards's memory maps I assume that the sysflags > > > >> are > > > >> initialized to 0 > > > > > > > > That's what the TRM says and what is observed in practice. > > > > > > > >> and that the first part of the physical memory space is > > > >> reserved for secure access? > > > > > > > > Wasn't quite sure what you meant my that, so looked at the RTSM manual > > > > for 'security' and spotted that if you enable the 'secure_memory' > > > > option, then the NOR flash at address 0 is "Secure RO, aborts on > > > > non-secure accesses". So if we need to support that option (do we?) then > > > > my patch is broken. > > > > > > > we probably don't need this for vexpress in any situation that uses > > > the boot-wrapper would be my guess, and we can always fix later then. > > > > > > What I was trying to figure out was why you can get rid of the "a > > > location less likely to be overridden" and why you're sure this memory > > > stays unmodified - I thought that was because you were loading the > > > code in the beginning of the physical memory space, which wouldn't be > > > touched by the linux kernel (i.e. reserved for the secure side), but > > > my guess may have been wrong and I was never a whiz with linker > > > scripts. > > > > In the RTSM manual, the first 64Mb of physical memory space is marked as > > "NOR FLASH0", as it is on real hardware. This is flash memory which is > > read-only under normal circumstances, and not anything Linux would go > > poking about in, unless you configured an MTD device and used it for a > > file system. > > > > DRAM is in the top 2GB and is what Linux uses for memory, and where most > > of the bootwrapper still lives. The only bit I've relocated to the > > bottom of the address space is everything in boot.S which includes all > > the bits we need to survive after Linux boots in order to handle a cpu > > startup again after being powered down then up again. > > > > Are you convinced, or do you still have concerns? > > > > I must admit, my patch is based on someone elses work, and I've not seen > > documentation which says that NOR flash can be written to simply by the > > application being loaded by the models having code located at the > > relevant address. I do know, that this code works on both A15 and A15xA7 > > models to boot Linux and Android, and that the new support it provides > > for power down and up cores works. > > > > I'll try and see if I can find out if locating code at address zero is > > officially supported... > > I have now spoken to someone in ARM's Fast Models team about this and > have been told that having an ELF section in the application which is > located at the NOR flash address is a legitimate and supported way of > setting the contents of flash. > > Does anyone have any further outstanding concerns or comments about my > proposed patch?
Since this doesn't seem to be merged yet, I'll just comment that this all looks sensible to me. For the bootwrapper to provide the reset vector code in (simulated) NOR flash feels like exactly the right thing to do here. (Minor point: you can merge the "b start" with the first entry of the vectors, because this slot is never used for any other purpose in any vector table. The code works anyway, though.) Cheers ---Dave _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
