On Thu, Dec 5, 2013 at 7:20 AM, Antony Pavlov <antonynpav...@gmail.com> wrote: > On Wed, 4 Dec 2013 20:29:05 +0000 > Peter Maydell <peter.mayd...@linaro.org> wrote: > >> On 4 December 2013 20:22, Antony Pavlov <antonynpav...@gmail.com> wrote: >> > Here is my proposition: >> > >> > 1. qemu board code setup CPU to start from 0xFFFF0000. (0xffff0000 is a >> > ROM address >> > on DIGIC chips) >> >> Sort of. What we need is: >> 1a. Add a "hivecs" property to the ARM CPU object (which >> just sets env->cp15.c1_sys bit 13) >> >> (this is about half a dozen lines of code max) >> >> 1b DIGIC board init code creates the CPU and sets the hivecs property on it >> >> (another handful of lines of code) > > Ok, I'll try to make the work at the weekend. > >> > 2. we need somehow put a 'jump-to-beginning-of-ROM' instruction to >> > 0xffff0000. >> > (We can't put barebox to 0xffff0000 as barebox image is bigger that 64K.) >> > >> > There is at least two possibilities to do so: >> > * we can use specially prepared ROM image; >> > * qemu board code can insert by itself a 'jump-to-beginning-of-ROM' >> > instruction >> > after loading ROM image (as qemu MIPS Malta board code does). >> >> The board code should definitely not be writing random instructions into >> memory. You need to provide a ROM image which will do the work. >>
But the bootloader does this already. We have support for board configurable secondary bootloops. Is this as simple as supporting board configurable primary boot fragments? arm_boot needs to be patched to do its bootstrap magic with no -kernel arg I guess. I have something of that nature in my own tree, where I have a command line argument that forces arm-boot to use the linux bootstrap stuff (primary and secondary bootloops and all that) regardless of image type. Regards, Peter >> > 3. CPU starts as usual. Branching to barebox code in ROM happends in a >> > natural way! >> >> This bit's OK :-) >> >> thanks >> -- PMM > > > -- > -- > Best regards, > Antony Pavlov >
