I made some "archeological diggings" with U-boot source code. If I understand correctly, U-boot/PowerPC normal style boot sequence is that MMU/virtual memory system is switched on by bootstrapping code after uncompressing kernel. That means, Image/uInitrd/fdt-blob file loading is made in "real" mode.

On ARM/Kirkwood environment BootPron is executed and it already sets SoC to MMU/virtual mode. Bootstrapping code re-initializes MMU after image-load/kernel -uncompressing with new kernel compatible setup.

DDR-ram init and MMU BootRom/bootstrapping code is made by Marvell, and becouse this 88F6281 is quite old chip Marwell-people might not update U-boot Kirkwood code anymore. At BootRom MMU-setup there is some limitations
with image relocation which must be noticed by Kirkwood U-boot port.

Anyway, PowerPC style fdt-load should be done with armel/armh -ports, too.


Kari Tanninen kirjoitti 5.3.2018 10:27:
I think GuruPlug doesn't have SPI-flash -> BootRom is executed before
U-boot -> virtual memory is set-up for MMU for U-boot.

88F6281 SoC is probably using Kirkwood series 12KB BootRom ver. 1.21
or later, but I cannot find prom source code (propietary/NDA stuff?).

88F6281 prom MMU memory setup is documented and there is some
limitations for virtual memory address space (for physical/PCI memory
address space mapping tables) after MMU setup and image needs special
header -> special uImage format needed (?).

In my case, I guess when loading fdt separatelly U-boots can set
memory paging correctly for  uInitrd. Loading to wrong place (=too
high?) it overlaps virtul memory swithing tables. It depends ARM based
SoC manufacturers BootRom MMU setups, if separete fdt loading is
usable for general linux kernel/bootloder API.

What will be d-i debian-armel policy?


Kari Tanninen kirjoitti 4.3.2018 20:08:
To be exact, I have Guruplug Server plus -version, and this device SoC
is 88F6281.


Kari Tanninen kirjoitti 4.3.2018 15:11:
Ben wrote:

"This behaviour is configurable.  For armel and armhf we enable
variables override the DTB"

That is obvious cause of these uInitrd relocation problems.

I don't exactly know how U-boot passes ATAG-values to kernel but in
multiprocessing environment it is very difficult task anyway
(and there is even BareBox forked from U-boot for non-flexible
attitude of U-boot for these kernel/bootloader API issues).

ARM MMU/multiprocessing environment is straightforward, but very
complex. I found GuruPlug PXA168 SoC specifications, but there is
thousands of
pages of information and it is very difficult to guess how
kernel/U-boot uses it. Linux kernel is expecting very complete setup
on boot,
and most difficult part (MMU init) must be done on bootloader.

I think that BareBox approach is not very healthy either, there is
some odd features to use FDT, too. Keeping up two versions of FDT, for

Best way to do it with Linux -kernel is to use one FDT-blob generated
by kconfig at kernel compile and load it by bootloader. At Kernel API
point of view
that should be same situation as PC and command line parameters and
other boot-time variables is supplied by bootloader by modifying
(for example "choosen") nodes.


Ben Hutchings kirjoitti 3.3.2018 16:13:
On Fri, 2018-03-02 at 14:48 +0200, Kari Tanninen wrote:
"In Debian installer, for the various plug devices, we append to
the DTB at the end of the kernel rather than loading it separately."

Is that possible/reasonable?

U-boot have to link all files on boot and it is impossibe to append
command line parametres to fdt-blob
without resize fdt-blob at U-boot. U-boot is using physical addressing
only(?) and I think kernel cannot
resize itself before boot without relocation problems -> bootm_size
variable issue.

If fdt is used, kernel should discard ATAG-variables by default, I

This behaviour is configurable.  For armel and armhf we enable
variables override the DTB.


Reply via email to