Re: Armel: Debian installer freeezes (GuruPlug Server plus)
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. KTA 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? 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.
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.
Re: Armel: Debian installer freeezes (GuruPlug Server plus)
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.
Re: Armel: Debian installer freeezes (GuruPlug Server plus)
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.
Re: Armel: Debian installer freeezes (GuruPlug Server plus)
"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. I suppose fdt-mechanism is meant to set HW-structure to both bootloader and kernel and U-boot is allowed to modify "choosen" field for appending command line parametres before kernel boot. Martin Michlmayr kirjoitti 1.3.2018 15:11: (Adding Ian Campbell.) Ok, I didn't notice the version of u-boot from the log you posted and went on what you wrote. However, looking at the log file again, I notice you're loading the DTB file separately. You say you follow my installation instructions but clearly you're not. In Debian installer, for the various plug devices, we append to the DTB at the end of the kernel rather than loading it separately. Can you please follow the instructions at https://www.cyrius.com/debian/kirkwood/sheevaplug/install/ and post the output of that? * Kari Tanninen <ot...@elisanet.fi> [2018-03-01 15:01]: I'm using Debian stretch U-boot version (U-boot version number is visible on the log-file). I have tried Debian "buster" U-boot version too, but it freezes at "Setting egiga0" point. There is warning on "Debian Armel installation guide", that U-boot does update kernel variables only on fresh installation, if first U-boot version is older than 2014, there will be problems becouse of "bootm_size" variable is missing and default value cannot be set. Flattened device tree -mechanism is not using those "ATAG" global kernel/U-boot -variables, but problem is missing U-boot "boot_args" -variable, too. Fdt-file includes that "Chosen" -field for command line parameters and U-boot has a commands to resize fdt -file and append command line parameters to it before actual boot. U-boot sets and can read correctly that fdt-file "chosen" part. U-boot kprint line for that "chosen" value is visible on log-file. Martin Michlmayr kirjoitti 1.3.2018 14:02: > * Kari Tanninen <ot...@elisanet.fi> [2018-03-01 11:26]: > > HW: Guruplug Server plus with JTAG-box (ARMv5-family) > > original U-boot pre-2014 > ... > > Is there any fix-up/work-aroud trick available or is new kernel > > compiling > > only option? > > I've never had a GuruPlug so I cannot really comment but why are you > using the pre-2014 u-boot version? I cannot remember all the > differences of the u-boot versions of the installation page says you > should upgrade your u-boot before installing Debian. Maybe you can > give this a try. > > Based on the logs you posted, it seems to me that the kernel and > ramdisk are loaded but the kernel doesn't see the ramdisk, leading to > the "no root" issue.
Re: Armel: Debian installer freeezes (GuruPlug Server plus)
NOTICE! Globalscale has bought at least two chunks of MAC-addresses, this unit MAC's starts as F0:AD:* Kari Tanninen ### Minicom terminal output => printenv baudrate=115200 bootargs=console=ttyS0, 115200n8 earlyprintk base-installer/initramfs-tools/driver-policy=most bootargs_console=console=ttyS0, 115200 root=/dev/sdb2 rootdelay=10 base-installer/initramfs-tools/driver-policy=most bootcmd=setenv bootargs ${bootargs_console}; run bootcmd_usb; run bootcmd_fdt; bootm 0x0080 0x0110 0x0c00; bootcmd_fdt=fdt addr 0x0c00; fdt resize; fdt chosen; fdt list /chosen; bootcmd_usb=usb start; usb start; ext2load usb 2:1 0x0080 /uImage; ext2load usb 2:1 0x0110 /uInitrd; ext2load usb 2:1 0x0c00 /guru bootdelay=6 eth1addr=F0:AD:4A:00:47:00 ethact=egiga0 ethaddr=F0:AD:4A:00:46:FF fdt_addr_r=0x0c00 fdt_high=0x fdtaddr=c00 fileaddr=110 filesize=b2c4af initrd_high=0x ipaddr=10.4.50.6 kernel_addr_r=0x0080 ramdisk_addr_r=0x0110 serverip=10.4.50.5 stderr=serial stdin=serial stdout=serial Environment size: 933/131068 bytes => tftp 0x0080 uImage Using egiga0 device TFTP from server 10.4.50.5; our IP address is 10.4.50.6 Filename 'uImage'. Load address: 0x80 Loading: # # ### 4.1 MiB/s done Bytes transferred = 2060842 (1f722a hex) => tftp 0x0110 uInitrd Using egiga0 device TFTP from server 10.4.50.5; our IP address is 10.4.50.6 Filename 'uInitrd'. Load address: 0x110 Loading: *# # # # # # # # # # # # ### 4 MiB/s done Bytes transferred = 11715759 (b2c4af hex) => bootm 0x0080 0x0110 ## Booting kernel from Legacy Image at 0080 ... Image Name: Debian kernel Created: 2017-12-05 16:25:07 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2060778 Bytes = 2 MiB Load Address: 8000 Entry Point: 8000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 0110 ... Image Name: debian-installer ramdisk Created: 2017-12-05 16:25:07 UTC Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size:11715695 Bytes = 11.2 MiB Load Address: Entry Point: Verifying Checksum ... OK Loading Kernel Image ... OK Starting kernel ... Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.9.0-4-marvell (debian-ker...@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 Debian 4.9.65-3 (2017-12-03) [0.00] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=0005397f [0.00] CPU: VIVT data cache, VIVT instruction cache [0.00] OF: fdt:Machine model: Globalscale Technologies Guruplug Server Plus [0.00] bootconsole [earlycon0] enabled [0.00] Memory policy: Data cache writeback [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 [0.00] Kernel command line: console=ttyS0, 115200n8 earlyprintk base-installer/initramfs-tools/driver-policy=most [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Memory: 502240K/524288K available (3778K kernel code, 395K rwdata, 1128K rodata, 296K init, 249K bss, 22048K reserved, 0K cma-reserved, 0K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB) [0.00] vmalloc : 0xe080 - 0xff80 ( 496 MB) [0.00] lowmem : 0xc000 - 0xe000 ( 512 MB) [0.00] pkmap : 0xbfe0 - 0xc00
Re: Armel: Debian installer freeezes (GuruPlug Server plus)
Minicom terminal log Armel strech d-i: bootm_size is currently not set, different values is tried when fdt_high/initrd_high not set: bootm_size=512M bootm_size=0x1fb0 etc. (U-boot docs are pretty unclear with exact syntax for "hex" format) -- Guruplug memories at fdt-blob - memory { device_type = "memory"; reg = <0x 0x2000>; }; { status = "okay"; partition@0 { label = "u-boot"; reg = <0x 0x0010>; read-only; }; partition@10 { label = "uImage"; reg = <0x0010 0x0040>; }; partition@50 { label = "data"; reg = <0x0050 0x1fb0>; }; }; KariTanninen Minicom Terminal log # Welcome to minicom 2.3 OPTIONS: [18n Compiled on Feb 26 2009, 00:28:35. Port /dev/ttyUSB0 Press CTRL-A Z for help on special keys => printenv baudrate=115200 bootargs=console=ttyS0, 115200n8 base-installer/initramfs-tools/driver-policy=most bootargs_console=console=ttyS0, 115200 root=/dev/sdb2 rootdelay=10 base-installer/initramfs-tools/driver-policy=most bootcmd=setenv bootargs ${bootargs_console}; run bootcmd_usb; run bootcmd_fdt; bootm 0x0080 0x0110 0x0c00; bootcmd_fdt=fdt addr 0x0c00; fdt resize; fdt chosen; fdt list /chosen; bootcmd_usb=usb start; usb start; ext2load usb 2:1 0x0080 /uImage; ext2load usb 2:1 0x0110 /uInitrd; ext2load usb 2:1 0x0c00 /guru bootdelay=6 eth1addr=F0:AD:4A:00:47:00 ethact=egiga0 ethaddr=F0:AD:4A:00:46:FF fdt_addr_r=0x0c00 fdt_high=0x fdtaddr=c00 fileaddr=110 filesize=b2c4af initrd_high=0x ipaddr=10.4.50.6 kernel_addr_r=0x0080 ramdisk_addr_r=0x0110 serverip=10.4.50.5 stderr=serial stdin=serial stdout=serial Environment size: 921/131068 bytes => tftpboot 0x0080 uImage Using egiga0 device TFTP from server 10.4.50.5; our IP address is 10.4.50.6 Filename 'uImage'. Load address: 0x80 Loading: # # ### 4 MiB/s done Bytes transferred = 2060842 (1f722a hex) => tftpboot 0x0110 uInitrd Using egiga0 device TFTP from server 10.4.50.5; our IP address is 10.4.50.6 Filename 'uInitrd'. Load address: 0x110 Loading: # # # # # # # # # # # # ### 3.9 MiB/s done Bytes transferred = 11715759 (b2c4af hex) bootm 0x0080 0x0110 ## Booting kernel from Legacy Image at 0080 ... Image Name: Debian kernel Created: 2017-12-05 16:25:07 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2060778 Bytes = 2 MiB Load Address: 8000 Entry Point: 8000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 0110 ... Image Name: debian-installer ramdisk Created: 2017-12-05 16:25:07 UTC Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size:11715695 Bytes = 11.2 MiB Load Address: Entry Point: Verifying Checksum ... OK Loading Kernel Image ... OK Starting kernel ... Uncompressing Linux... done, booting the kernel. Kari Tanninen kirjoitti 1.3.2018 20:01: I try tomorrow record Debian "Stretch" U-boot/uImage/uInitrd -terminal output with instructions "https://www.cyrius.com/debian/kirkwood/sheevaplug/install/; Sorry delay, I have to load new binaries to GuruPlug and I'm not very familiar with unix command line scripting, readable minicom -output needs little tee/sed processing. Kari Tanninen not very handy to make commad line scripting, terminal output Martin Michlmayr kirjoitti 1.3.2018 15:11: (Adding Ian Campbe
Re: Armel: Debian installer freeezes (GuruPlug Server plus)
I try tomorrow record Debian "Stretch" U-boot/uImage/uInitrd -terminal output with instructions "https://www.cyrius.com/debian/kirkwood/sheevaplug/install/; Sorry delay, I have to load new binaries to GuruPlug and I'm not very familiar with unix command line scripting, readable minicom -output needs little tee/sed processing. Kari Tanninen not very handy to make commad line scripting, terminal output Martin Michlmayr kirjoitti 1.3.2018 15:11: (Adding Ian Campbell.) Ok, I didn't notice the version of u-boot from the log you posted and went on what you wrote. However, looking at the log file again, I notice you're loading the DTB file separately. You say you follow my installation instructions but clearly you're not. In Debian installer, for the various plug devices, we append to the DTB at the end of the kernel rather than loading it separately. Can you please follow the instructions at https://www.cyrius.com/debian/kirkwood/sheevaplug/install/ and post the output of that? * Kari Tanninen <ot...@elisanet.fi> [2018-03-01 15:01]: I'm using Debian stretch U-boot version (U-boot version number is visible on the log-file). I have tried Debian "buster" U-boot version too, but it freezes at "Setting egiga0" point. There is warning on "Debian Armel installation guide", that U-boot does update kernel variables only on fresh installation, if first U-boot version is older than 2014, there will be problems becouse of "bootm_size" variable is missing and default value cannot be set. Flattened device tree -mechanism is not using those "ATAG" global kernel/U-boot -variables, but problem is missing U-boot "boot_args" -variable, too. Fdt-file includes that "Chosen" -field for command line parameters and U-boot has a commands to resize fdt -file and append command line parameters to it before actual boot. U-boot sets and can read correctly that fdt-file "chosen" part. U-boot kprint line for that "chosen" value is visible on log-file. Martin Michlmayr kirjoitti 1.3.2018 14:02: > * Kari Tanninen <ot...@elisanet.fi> [2018-03-01 11:26]: > > HW: Guruplug Server plus with JTAG-box (ARMv5-family) > > original U-boot pre-2014 > ... > > Is there any fix-up/work-aroud trick available or is new kernel > > compiling > > only option? > > I've never had a GuruPlug so I cannot really comment but why are you > using the pre-2014 u-boot version? I cannot remember all the > differences of the u-boot versions of the installation page says you > should upgrade your u-boot before installing Debian. Maybe you can > give this a try. > > Based on the logs you posted, it seems to me that the kernel and > ramdisk are loaded but the kernel doesn't see the ramdisk, leading to > the "no root" issue.
Re: Armel: Debian installer freeezes (GuruPlug Server plus)
Sorry, english is not my native language (I'm finnish), so I have been unclear on my previous posts. I have followed instructions literally, but installer freezes and text "Uncompressing Linux..." appears on terminal window. On "https://www.cyrius.com/debian/kirkwood/sheevaplug/install; separate ftd -blob file is indeed not loaded, but when I load fdt kernel finally boots but cannot find rootfile system. There is some information on "Debian armel installation" guide for uInitrd relocation problems and advice to se "bootm_size" to default value. Unfortunatelly that does not work if original U-boot version is pre-2014, becouse of bootm_size value is not set at all. I tried to se "bootm_size" value manually by U-boot without success, only way to get kernel to boot is load fdt separately. Martin Michlmayr kirjoitti 1.3.2018 15:11: (Adding Ian Campbell.) Ok, I didn't notice the version of u-boot from the log you posted and went on what you wrote. However, looking at the log file again, I notice you're loading the DTB file separately. You say you follow my installation instructions but clearly you're not. In Debian installer, for the various plug devices, we append to the DTB at the end of the kernel rather than loading it separately. Can you please follow the instructions at https://www.cyrius.com/debian/kirkwood/sheevaplug/install/ and post the output of that? * Kari Tanninen <ot...@elisanet.fi> [2018-03-01 15:01]: I'm using Debian stretch U-boot version (U-boot version number is visible on the log-file). I have tried Debian "buster" U-boot version too, but it freezes at "Setting egiga0" point. There is warning on "Debian Armel installation guide", that U-boot does update kernel variables only on fresh installation, if first U-boot version is older than 2014, there will be problems becouse of "bootm_size" variable is missing and default value cannot be set. Flattened device tree -mechanism is not using those "ATAG" global kernel/U-boot -variables, but problem is missing U-boot "boot_args" -variable, too. Fdt-file includes that "Chosen" -field for command line parameters and U-boot has a commands to resize fdt -file and append command line parameters to it before actual boot. U-boot sets and can read correctly that fdt-file "chosen" part. U-boot kprint line for that "chosen" value is visible on log-file. Martin Michlmayr kirjoitti 1.3.2018 14:02: > * Kari Tanninen <ot...@elisanet.fi> [2018-03-01 11:26]: > > HW: Guruplug Server plus with JTAG-box (ARMv5-family) > > original U-boot pre-2014 > ... > > Is there any fix-up/work-aroud trick available or is new kernel > > compiling > > only option? > > I've never had a GuruPlug so I cannot really comment but why are you > using the pre-2014 u-boot version? I cannot remember all the > differences of the u-boot versions of the installation page says you > should upgrade your u-boot before installing Debian. Maybe you can > give this a try. > > Based on the logs you posted, it seems to me that the kernel and > ramdisk are loaded but the kernel doesn't see the ramdisk, leading to > the "no root" issue.
Re: Armel: Debian installer freeezes (GuruPlug Server plus)
I'm using Debian stretch U-boot version (U-boot version number is visible on the log-file). I have tried Debian "buster" U-boot version too, but it freezes at "Setting egiga0" point. There is warning on "Debian Armel installation guide", that U-boot does update kernel variables only on fresh installation, if first U-boot version is older than 2014, there will be problems becouse of "bootm_size" variable is missing and default value cannot be set. Flattened device tree -mechanism is not using those "ATAG" global kernel/U-boot -variables, but problem is missing U-boot "boot_args" -variable, too. Fdt-file includes that "Chosen" -field for command line parameters and U-boot has a commands to resize fdt -file and append command line parameters to it before actual boot. U-boot sets and can read correctly that fdt-file "chosen" part. U-boot kprint line for that "chosen" value is visible on log-file. Martin Michlmayr kirjoitti 1.3.2018 14:02: * Kari Tanninen <ot...@elisanet.fi> [2018-03-01 11:26]: HW: Guruplug Server plus with JTAG-box (ARMv5-family) original U-boot pre-2014 ... Is there any fix-up/work-aroud trick available or is new kernel compiling only option? I've never had a GuruPlug so I cannot really comment but why are you using the pre-2014 u-boot version? I cannot remember all the differences of the u-boot versions of the installation page says you should upgrade your u-boot before installing Debian. Maybe you can give this a try. Based on the logs you posted, it seems to me that the kernel and ramdisk are loaded but the kernel doesn't see the ramdisk, leading to the "no root" issue.
Re: Armel: Debian installer freeezes (GuruPlug Server plus)
rt v0.3: not present [0.095487] clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 764504178510 ns [0.105405] futex hash table entries: 256 (order: -1, 3072 bytes) [0.112026] pinctrl core: initialized pinctrl subsystem [0.118318] NET: Registered protocol family 16 [0.123258] DMA: preallocated 256 KiB pool for atomic coherent allocations [0.131380] cpuidle: using governor ladder [0.135624] cpuidle: using governor menu [0.140052] Feroceon L2: Enabling L2 [0.143762] Feroceon L2: Cache support initialised. [0.149021] [Firmware Info]: /ocp@f100/ethernet-controller@72000/ethernet0-port@0: local-mac-address is not set [0.159689] [Firmware Info]: /ocp@f100/ethernet-controller@76000/ethernet1-port@0: local-mac-address is not set [0.173592] No ATAGs? [0.178361] clocksource: Switched to clocksource Orion_clocksource [0.209277] VFS: Disk quotas dquot_6.6.0 [0.213410] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [0.220878] AppArmor: AppArmor Filesystem Enabled [0.233204] NET: Registered protocol family 2 [0.238501] TCP established hash table entries: 4096 (order: 2, 16384 bytes) [0.245735] TCP bind hash table entries: 4096 (order: 2, 16384 bytes) [0.252353] TCP: Hash tables configured (established 4096 bind 4096) [0.258973] UDP hash table entries: 256 (order: 0, 4096 bytes) [0.264953] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) [0.271512] NET: Registered protocol family 1 [0.276732] audit: initializing netlink subsys (disabled) [17;1H[0.282711] audit: type=2000 audit(0.220:1): state=initialized audit_enabled=0 res=1 [17;1H[0.290625] workingset: timestamp_bits=30 max_order=17 bucket_order=0 [0.297279] zbud: loaded [1.106361] random: fast init done [4.459654] Key type asymmetric registered [4.463933] Asymmetric key parser 'x509' registered [4.468981] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251) [4.476599] io scheduler noop registered [4.480725] io scheduler cfq registered (default) [4.486707] kirkwood-pinctrl f101.pin-controller: registered pinctrl driver [4.495938] mv_xor f1060800.xor: Marvell shared XOR driver [4.531469] mv_xor f1060800.xor: Marvell XOR (Registers Mode): ( xor cpy sg intr ) [4.539350] mv_xor f1060900.xor: Marvell shared XOR driver [4.575471] mv_xor f1060900.xor: Marvell XOR (Registers Mode): ( xor cpy sg intr ) [4.583541] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled [4.590933] console [ttyS0] disabled [4.594690] f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 25, base_baud = 1250) is a 16550A [4.603813] console [ttyS0] enabled [4.603813] console [ttyS0] enabled [4.610914] bootconsole [earlycon0] disabled [4.610914] bootconsole [earlycon0] disabled [4.620442] libphy: Fixed MDIO Bus: probed [4.624899] rtc-mv f1010300.rtc: rtc core: registered f1010300.rtc as rtc0 [4.631881] i2c /dev entries driver [4.636170] ledtrig-cpu: registered to indicate activity on CPUs [4.643106] registered taskstats version 1 [4.647293] zswap: loaded using pool lzo/zbud [4.651787] AppArmor: AppArmor sha1 policy hashing enabled [4.658158] rtc-mv f1010300.rtc: setting system clock to 2000-01-01 00:00:00 UTC (946684800) [4.667088] List of all partitions: [4.670619] No filesystem could mount root, tried: [4.670623] [4.677034] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [4.685334] CPU: 0 PID: 1 Comm: swapper Not tainted 4.13.0-1-marvell #1 Debian 4.13.13-1 [4.693456] Hardware name: Marvell Kirkwood (Flattened Device Tree) [4.699776] [] (unwind_backtrace) from [] (show_stack+0x18/0x1c) [4.707563] [] (show_stack) from [] (panic+0xb8/0x254) [4.714478] [] (panic) from [] (mount_block_root+0x244/0x2e8) [4.721999] [] (mount_block_root) from [] (prepare_namespace+0x150/0x190) [4.730569] [] (prepare_namespace) from [] (kernel_init_freeable+0x160/0x1c0) [4.739480] [] (kernel_init_freeable) from [] (kernel_init+0x10/0xf4) [4.747694] [] (kernel_init) from [] (ret_from_fork+0x14/0x24) [4.755299] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [ 53.710404] random: crng init done Kari Tanninen kirjoitti 1.3.2018 11:26: HW: Guruplug Server plus with JTAG-box (ARMv5-family) Debian U-boot version: Armel stretch (buster u-boot version freezes when setting ethact IP-addresses), original U-boot pre-2014 Debain Installer version: stretch Problem: When trying to launch d-i (stretch, with instructions from Martin Michlmayr webpages) from USB-stick or memory (tftp-load), installer freezes with text "Uncompressing Linux". Original U-boot version pre-2014 has a documented bug with old u-boot versions variables (bootm_size value). Setting initrd_high/fdt_high
Armel: Debian installer freeezes (GuruPlug Server plus)
HW: Guruplug Server plus with JTAG-box (ARMv5-family) Debian U-boot version: Armel stretch (buster u-boot version freezes when setting ethact IP-addresses), original U-boot pre-2014 Debain Installer version: stretch Problem: When trying to launch d-i (stretch, with instructions from Martin Michlmayr webpages) from USB-stick or memory (tftp-load), installer freezes with text "Uncompressing Linux". Original U-boot version pre-2014 has a documented bug with old u-boot versions variables (bootm_size value). Setting initrd_high/fdt_high 0x to fix doesn't help. When FDT-blob loaded to fix problem(addres 0x0c00)kernel founds fdt and uInird and starts obviously normally but won't read command line parametres from fdt-memory area as should (using original default fdt instead), and cannot find root file system (on default fdt-file root filesystem is not defined). Seems that U-boot sets and finds command line parametres to/from fdt normally, but kernel doesn't use it. (maybe d-i kernel configured for statical fdt?) Reference: Globalscale Fedora 11 (+ OpenDC) development package works and installs (unfortunatelly very old) system without major problems (minor changes with MAC-address space defaults to perl script needed) -> HW probably OK Is there any fix-up/work-aroud trick available or is new kernel compiling only option? Kari Tanninen