[U-Boot] [PATCH 2/9] sunxi: Move SPL s_init() code to board_init_f()
Siarhei Siamashka
siarhei.siamashka at gmail.com
Sun Feb 1 19:37:38 CET 2015
On Sun, 1 Feb 2015 10:00:43 -0700
Simon Glass <sjg at chromium.org> wrote:
> 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 that the difference is a matter of who calls whom. In the
case of Exynos, the SPL can call iROM functions. But in the case of
Allwinner, the whole SPL works as a kind of plugin, which is called
from the BROM code.
I'm not sure if the Allwinner BROM can be used in the same way as
the Exynos iROM, because the Allwinner BROM is not documented at all
as far as I know. Exynos probably has a better documentation.
> 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.
Yes, I agree. At least in the long term.
But in the short term it would be very nice to get the FEL boot
mode working again in the v2015.04 release.
> 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?
The return address to the BROM code is in the 'lr' register. Just like
in the case of calling any normal function.
> 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.
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
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.
> >> > 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
--
Best regards,
Siarhei Siamashka
More information about the U-Boot
mailing list