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

2018-03-06 Thread Ben Hutchings 
Please leave me out of this thread.

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained
by stupidity.



signature.asc
Description: This is a digitally signed message part

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

2018-03-06 Thread Kari Tanninen 
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)

2018-03-05 Thread Kari Tanninen 
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)

2018-03-04 Thread Kari Tanninen 
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)

2018-03-04 Thread Kari Tanninen 

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)

2018-03-03 Thread Ben Hutchings 
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.

-- 
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had
thought. ... I realized that a large part of my life from then on was
going to be spent in finding mistakes in my own programs. - Maurice
Wilkes, 1949


signature.asc
Description: This is a digitally signed message part

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

2018-03-02 Thread Kari Tanninen 

"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  [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  [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)

2018-03-02 Thread Kari Tanninen 
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 - 0xc000   (   2 MB)

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

2018-03-02 Thread Martin Michlmayr 
Can you try:

tftpboot 0x0080 uImage
tftpboot 0x0110 uInitrd
setenv bootargs console=ttyS0,115200n8 earlyprintk 
base-installer/initramfs-tools/driver-policy=most
bootm 0x0080 0x0110


* Kari Tanninen  [2018-03-02 11:42]:
> 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)
> 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

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

2018-03-02 Thread Kari Tanninen 

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 Campbell.)

Ok, I didn't notice the version of u-boot from the log you posted and
went on what you wrote.

However,

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

2018-03-01 Thread Kari Tanninen 
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  [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  [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)

2018-03-01 Thread Kari Tanninen 
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  [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  [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)

2018-03-01 Thread Martin Michlmayr 
(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  [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  [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.

-- 
Martin Michlmayr
http://www.cyrius.com/

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

2018-03-01 Thread Kari Tanninen 
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  [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)

2018-03-01 Thread Martin Michlmayr 
* Kari Tanninen  [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.

-- 
Martin Michlmayr
http://www.cyrius.com/

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

2018-03-01 Thread Kari Tanninen 

Log:

Initializing Modem
Welcome to minicom 2.3
Port /dev/ttyUSB0 Press CTRL-A Z for help on special keys

U-Boot 2016.11+dfsg1-4 (Mar 27 2017 - 18:39:51 +)
Marvell-GuruPlug

SoC:   Kirkwood 88F6281_A0
DRAM:  512 MiB
WARNING: Caches not enabled
NAND:  512 MiB
In:serial
Out:   serial
Err:   serial
Net:   egiga0, egiga1
88E1121 Initialized on egiga0
88E1121 Initialized on egiga1
IDE:   ide_preinit failed
Hit any key to stop autoboot:  6 5 4 3 2 1
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 4 USB Device(s) found
   scanning usb for storage devices... Device NOT ready
   Request Sense returned 02 3A 00
3 Storage Device(s) found
2055218 bytes read in 242 ms (8.1 MiB/s)
12015242 bytes read in 972 ms (11.8 MiB/s)
10522 bytes read in 76 ms (134.8 KiB/s)
chosen {
   bootargs = "console=ttyS0, 115200 root=/dev/sdb2 rootdelay=10 base-
   installer/initramfs-tools/driver-policy=most";
   stdout-path = "/ocp@f100/serial@12000";
}
## Booting kernel from Legacy Image at 0080 ...
   Image Name:   Debian kernel
   Created:  2017-12-04   7:25:55 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:2055154 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-04   7:25:55 UTC
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:12015178 Bytes = 11.5 MiB
   Load Address: 
   Entry Point:  
   Verifying Checksum ... OK
## Flattened Device Tree blob at 0c00
   Booting using the fdt blob at 0xc00
   Loading Kernel Image ... OK
   reserving fdt memory region: addr=c00 size=3000
   Using Device Tree in place at 0c00, end 0c005fff

Starting kernel ...
Uncompressing Linux... done, booting the kernel.
[0.00] Booting Linux on physical CPU 0x0
[0.00] random: get_random_bytes called from 
start_kernel+0x28/0x3ec with crng_init=0
[0.00] Linux version 4.13.0-1-marvell 
(debian-ker...@lists.debian.org) (gcc version 6.4.0 20171112 (Debian 
6.4.0-10)) #1 Debian 4.13.13-1 (2017-11-16)
[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
[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: 513692K/524288K available (3796K kernel code, 
325K rwdata, 1164K rodata, 308K init, 229K bss, 10596K 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 - 0xc000   (   2 MB)
[0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
[0.00]   .text : 0xc0008000 - 0xc03bd468   (3798 kB)
[0.00]   .init : 0xc0503000 - 0xc055   ( 308 kB)
[0.00]   .data : 0xc055 - 0xc05a1490   ( 326 kB)
[0.00].bss : 0xc05a4b14 - 0xc05de214   ( 230 kB)
[0.00] ftrace: allocating 17887 entries in 35 pages
[0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[0.00] clocksource: orion_clocksource: mask: 0x 
max_cycles: 0x, max_idle_ns: 9556302233 ns
[0.08] sched_clock: 32 bits at 200MHz, resolution 5ns, wraps 
every 10737418237ns

[0.007979] Switching to timer-based delay loop, resolution 5ns
[0.014481] Console: colour dummy device 80x30
[17;1H[0.019076] Calibrating delay loop (skipped), value calculated 
using timer frequency.. 400.00 BogoMIPS (lpj=80)

[0.029677] pid_max: default: 32768 minimum: 301
[0.034594] Security Framework initialized
[0.038832] Yama: disabled by default; enable with sysctl 
kernel.yama.*

[0.045674] AppArmor: AppArmor initialized
[0.050046] Mount-cache hash table entries: 1024 (order: 0, 4096 
bytes)
[0.056819] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 
bytes)

[0.064903] CPU: Testing write buffer coherency: ok
[0.070812] Setting up static identity map for 0x8200 - 0x823c
[0.077051] mvebu-soc-id: MVEBU SoC ID=0x6281, Rev=0x2
[0.084587] devtmpfs: initialized
[0.091148] VFP support v0.3: not present
[

Armel: Debian installer freeezes (GuruPlug Server plus)

2018-03-01 Thread Kari Tanninen 

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