[U-Boot] [PATCH 2/9] sunxi: Move SPL s_init() code to board_init_f()

[Simon Glass]

Hi Siarhei,

On 3 February 2015 at 20:23, Simon Glass <sjg at chromium.org> wrote:
> Hi Siarhei,
>
> On 3 February 2015 at 18:58, Siarhei Siamashka
> <siarhei.siamashka at gmail.com> wrote:
>> On Tue, 3 Feb 2015 17:55:52 -0700
>> Simon Glass <sjg at chromium.org> wrote:
>>
>>> Hi,
>>>
>>> On 2 February 2015 at 22:29, Simon Glass <sjg at chromium.org> wrote:
>>> > Hi,
>>> >
>>> > On 2 February 2015 at 01:07, Hans de Goede <hdegoede at redhat.com> wrote:
>>> >> Hi Simon, Siarhei,
>>> >>
>>> >> On 01-02-15 21:59, Simon Glass wrote:
>>> >>>
>>> >>> Hi Siarhei,
>>> >>>
>>> >>> On 1 February 2015 at 11:37, Siarhei Siamashka
>>> >>> <siarhei.siamashka at gmail.com>
>>> >>
>>> >>
>>> >> <snip>
>>> >>
>>> >>>> A comprehensive FEL usage guide is supposed to be in the linux-sunxi
>>> >>>> wiki. But it might be not very up to date with the mainline u-boot
>>> >>>> usage.
>>> >>>>
>>> >>>> Anyway, first just clone the https://github.com/linux-sunxi/sunxi-tools
>>> >>>> repository and build it. This will provide you with the x86 binary of
>>> >>>> the 'fel' tool, which is used on your desktop PC to talk with the
>>> >>>> device.
>>> >>>>
>>> >>>> Then connect the device to your PC using a "USB A to USB mini/micro B"
>>> >>>> cable. And reset the board while keeping the "FEL" button pressed. The
>>> >>>> button might be labelled as "UPGRADE" on your pcduino3 board:
>>> >>>> http://linux-sunxi.org/LinkSprite_pcDuino_V3#FEL_mode
>>> >>>>
>>> >>>> Then just run "fel ver" command:
>>> >>>> http://linux-sunxi.org/FEL#Running_the_fel_tool
>>> >>>>
>>> >>>> If everything is fine, it should respond with something like this:
>>> >>>> AWUSBFEX soc=00162500(A13) 00000001 ver=0001 44 08 scratchpad=00007e00
>>> >>>> 00000000 00000000
>>> >>>>
>>> >>>> Now you can use "write" commands to upload data to SRAM. And "exe"
>>> >>>> command to execute functions on the device (works as some kind of RPC):
>>> >>>> http://linux-sunxi.org/FEL/USBBoot#Manual_loading
>>> >>>>
>>> >>>> As a simple test, you can upload just a single "bx lr" instruction
>>> >>>> (compiled in ARM mode) to the address 0x2000 and try to execute it.
>>> >>>> In the case if your code screws up something and does not return
>>> >>>> control to the BROM correctly, then the "fel" tool can't communicate
>>> >>>> over USB anymore and just timeouts. Regarding the address space, you
>>> >>>> can use SRAM addresses starting from 0x2000 up to something like 0x5E00
>>> >>>> (that's where the stack pointer is set). This was a description of a
>>> >>>> "bare metal" FEL usage.
>>> >>>>
>>> >>>> Now as for the u-boot support. You can compile and run u-boot in the FEL
>>> >>>> mode configuration on pcduino3 in the following way:
>>> >>>>
>>> >>>> make CROSS_COMPILE=arm-none-gnueabi- Linksprite_pcDuino3_felconfig
>>> >>>> make CROSS_COMPILE=arm-none-gnueabi- -j2
>>> >>>>
>>> >>>> fel write 0x2000 spl/u-boot-spl.bin
>>> >>>> fel exe 0x2000
>>> >>>>
>>> >>>> sleep 1 # Wait for DRAM initialization to complete
>>> >>>
>>> >>>
>>> >>> i.e. wait for U-Boot SPL to return to the BROM?
>>> >>>
>>> >>>>
>>> >>>> fel write 0x4a000000 u-boot.bin
>>> >>>> fel exe 0x4a000000
>>> >>>>
>>> >>>> Please note the use of '*_felconfig' instead of '*_defconfig'.
>>> >>>> And also right now the FEL mode support is broken. That's why the
>>> >>>> http://lists.denx.de/pipermail/u-boot/2015-January/203282.html
>>> >>>> patchset tried to address this problem.
>>> >>>>
>>> >>>
>>> >>> OK that looks like an excellent guide, thank you. I will make some time to
>>> >>> take a more detailed look at this as soon as I can, but definitely in the
>>> >>> next few days.
>>> >>
>>> >>
>>> >> I've been reading all threads on this, thank you both for looking into this,
>>> >> since you're on it I'm going to leave this be (and not review / apply
>>> >> Siarhei's patches for this), and we can revisit this later, with hopefully a
>>> >> better fix.
>>> >
>>> > Thanks to Siarhei's instructions I have a working setup with pcduino3.
>>> > One less board where I have to swap SD cards. Can I suggest that it
>>> > would be really nice to have a README.sunxi that covers all of this?
>>> >
>>> > Anyway I will fiddle around and see what I can come up with.
>>>
>>> The problem seems to be the start.S code 'Setup vector' and
>>> cpu_init_cp15. If I remove these then FEL boots OK without all the
>>> gdata/r9 stuff and with the rest of the boot flow normal.
>>
>> I don't quite follow this brief explanation. Could you perhaps
>> attach/paste a patch or provide a link to some test branch with
>> the code?
>
> If you look at code in start.S it fiddles with cp15 and this seems to
> stuff up FEL. I'm not exactly sure what is breaking it, but we seem to
> need to skip that code.
>
> I will push what I have to a branch - I am just trying to tidy it up a bit.
>
>>
>>> I would quite like FEL to be an option you enable, but we can detect
>>> whether it is actually being used (as with Tegra and Exynos).
>>
>> FEL is already a Kconfig option, which can be enabled/disabled
>> in menuconfig. Currently it also disables certain parts of code
>> (MMC support) in order to reduce the SPL size. If these parts are
>> all included (but deactivated via a runtime check), then the SPL
>> binary becomes too large.
>
> OK. My point is that FEL support should not be such a pervasive
> option, changing everything about how it boots. We should just change
> the minimum to make FEL work. The only thing that really is a problem
> is the size, so with FEL we must disable MMC. That is fine.
>
>>
>>> Perhaps checking the value of lr will allow this to work.
>>
>> Or by peeking into some of the MUSB hardware registers after the
>> start of SPL. MUSB must be already initialized for FEL to work.
>
> That sounds good, we should use whatever is a cast-iron way of knowing
> the boot mode. On Exynos there is a register.
>
>>
>> However I'm still curious about how the SPL size problem is going
>> to be addressed.
>
> Well it probably cannot be addressed. Does the boot ROM have an MMC
> stack? Surely it must if it supports booting from MMC?
>
>>
>>> I'm not sure of the best way to skip the vector/cp15 setup. For now I
>>> can do an #ifdef but I'm wondering if we should allow
>>> save_boot_params() to return some flags indicating what should be
>>> skipped?

I will send a series separately for you to try. It needs work but I
hope it illustrates the idea.

Regards,
Simon