[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Armel: Debian installer freeezes (GuruPlug Server plus)



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?

KTA




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

KariT

Kari Tanninen kirjoitti 4.3.2018 15:11:
Ben wrote:

"This behaviour is configurable.  For armel and armhf we enable
CONFIG_ARM_ATAG_DTB_COMPAT and
CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER so that ATAG
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
example.

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
FDT-blob
(for example "choosen") nodes.

KariT

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
think.
[...]

This behaviour is configurable.  For armel and armhf we enable
CONFIG_ARM_ATAG_DTB_COMPAT and
CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER so that ATAG
variables override the DTB.

Ben.


Reply to: