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

[Simon Glass]

Hi Siarhei,

On 1 February 2015 at 09:45, Siarhei Siamashka
<siarhei.siamashka at gmail.com> wrote:
> On Sun, 1 Feb 2015 09:29:53 -0700
> Simon Glass <sjg at chromium.org> wrote:
>
>> Hi,
>>
>> On 30 January 2015 at 10:53, Siarhei Siamashka
>> <siarhei.siamashka at gmail.com> wrote:
>> > On Mon, 29 Dec 2014 09:15:36 -0700
>> > Simon Glass <sjg at chromium.org> wrote:
>> >
>> >> Hi Ian,
>> >>
>> >> On 28 December 2014 at 02:19, Ian Campbell <ijc at hellion.org.uk> wrote:
>> >> > On Tue, 2014-12-23 at 12:04 -0700, Simon Glass wrote:
>> >> >
>> >> >> +void board_init_f(ulong dummy)
>> >> >> +{
>> >> > [...]
>> >> >> +     /* Clear the BSS. */
>> >> >> +     memset(__bss_start, 0, __bss_end - __bss_start);
>> >> >> +
>> >> >> +     board_init_r(NULL, 0);
>> >> >
>> >> > The previous (__weak) version of board_init_f also sets gd, which you've
>> >> > also removed from s_init here and not added back anywhere (indeed, this
>> >> > is the point...). But where is gd initialised now?
>> >>
>> >> It's still in start.S, I've just removed this duplicate.
>> >>
>> >> >
>> >> > The patch generally looks good, two quick questions: has it been tested
>> >> > in both FEL and regular mode, and has it been tested with a "legacy" as
>> >> > well as a driver model system? (I might be able to find time in a day or
>> >> > two to answer these myself, but for now I'll just ask).
>> >>
>> >> I haven't tried FEL, I only just heard of it in your email. I'll see
>> >> if I can figure out how to test that.
>> >
>> > Just like Ian suspected, this patch has messed up the FEL boot mode
>> > support.
>> >
>> > In a nutshell, FEL is a special USB protocol (accessible on a USB OTG
>> > connector), which is implemented by the boot ROM and activated by
>> > holding a special hardware button pressed and rebooting the device.
>> > FEL supports commands to read/write device RAM and execute code on
>> > the device. It is designed for device unbricking and firmware recovery.
>>
>> If I understand it correctly, this is the same function that is
>> available on Exynos5, Tegra, MX6 and probably others.
>>
>> >
>> > In particular, the FEL boot mode support is very useful for debugging
>> > u-boot and kernel problems on tablets (the SD card slot can be used
>> > for the UART console, while the system is booted over a micro-USB cable
>> > with the help of FEL):
>> >     http://linux-sunxi.org/File:MSI_Primo81_and_MicroSD_breakout.jpg
>> >
>> > In u-boot it is used in the following way:
>> >  1. The SPL code is uploaded from the linux PC to the device SRAM via
>> >     a FEL command (using the 'fel' program from sunxi-tools).
>> >  2. The SPL code is executed via a FEL command and expected to
>> >     initialize the DRAM controller. The code is executed as a
>> >     normal C or assembly function, which needs to return control
>> >     back to the BROM code when it is done. Right now this
>> >     function is s_init().
>>
>> Isn't this just another way of loading SPL then? What is so special /
>> different about FEL?
>
> I'm not very familiar with the other platforms, but the special part
> here is "needs to return control back to the BROM code when it is done".
>
> We are relying on the FEL USB protocol implementation, which is
> hardcoded in BROM. FEL is used to upload data over USB to the device
> memory. And FEL needs to be used twice. Once for uploading data to SRAM
> and running the SPL. And one more time for uploading the rest of the
> data to DRAM.
>
> As we naturally can't modify the Allwinner code in BROM, here u-boot
> needs to play according to the FEL rules and not the other way around.
>
> As I see it, an alternative solution would be to implement USB OTG
> support and the FEL protocol (or some other protocol) in the u-boot
> SPL and stop relying on BROM code for uploading data to DRAM. Until
> this is done, the sunxi FEL variant of SPL needs to return control to
> the BROM code nicely after it has initialized DRAM and abstain from
> doing anything else.
>
> I hope that this clarifies the situation.

Exynos calls back into its IROM also from SPL, when it sees that it is
in USB A-A mode. See arch/arm/cpu/armv7/exynos/spl_boot.c where you
will find a table of IROM entry points.

I think it is fine to use the BROM and FEL, I am just concerned that
we need to stop using gdata and make FEL fit within the existing SPL
sequence. We need to avoid an SOC-specific hack, and if such a hack is
needed, it should be localised to sunxi and not rely on gdata, etc.

When you say 'return back to BROM', what exactly is a 'return'? Does
it mean that you need to jump to a return address in one of the
registers, or something else? Can you point me to the code that does
this and instructions on how to use it? Then I could try it out and
try to understand it better.

>
>> >  3. As the DRAM is initialized and available now, the main u-boot
>> >     binary is now uploaded to DRAM via FEL. Together with boot.scr,
>> >     the kernel, the dtb file and optionally initramfs as needed.
>> >  4. The main u-boot binary is executed via a FEL command, but never
>> >     returns back to BROM anymore.
>> >
>> > More details are available in the linux-sunxi wiki:
>> >     http://linux-sunxi.org/FEL
>> >     http://linux-sunxi.org/FEL/Protocol
>> >     http://linux-sunxi.org/FEL/USBBoot
>> >
>> > I have submitted a patch to fix this regression:
>> >     https://patchwork.ozlabs.org/patch/434826/
>> >
>> > If you encounter problems and/or need help when testing FEL, please
>> > let me know.
>>
>> OK I commented on that patch.
>
> Thanks.

Regards,
Simon