Debian Bug report logs - #839595
flash-kernel: Please add support for SolidRun Clearfog

Package: flash-kernel; Maintainer for flash-kernel is Debian Install System Team <debian-boot@lists.debian.org>; Source for flash-kernel is src:flash-kernel (PTS, buildd, popcon).

Reported by: Christoph Egger <christoph@debian.org>

Date: Sun, 2 Oct 2016 14:57:01 UTC

Severity: wishlist

Found in version flash-kernel/3.69

Fixed in version flash-kernel/3.91

Done: Christian Perrier <bubulle@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox

Report forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#839595; Package flash-kernel. (Sun, 02 Oct 2016 14:57:04 GMT) (full text, mbox, link).

Acknowledgement sent to Christoph Egger <christoph@debian.org>:
New Bug report received and forwarded. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Sun, 02 Oct 2016 14:57:04 GMT) (full text, mbox, link).

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

Package: flash-kernel
Version: 3.69
Severity: wishlist

Hi!

Please consider adding clearfog support. The system works fine with
mainline u-boot + kernel. Hopefully I have added all necessary
information below:

| Machine: SolidRun Clearfog A1
| Kernel-Flavors: armmp armmp-lpae
| DTB-Id: armada-388-clearfog.dtb
| Required-Packages: u-boot-tools

| # fw_printenv
| baudrate=115200
| bootargs=console=ttyS0,115200n8 rootdelay=10 bootwait=10 rootwait=10 root=/dev/mmcblk0p1
| bootcmd=ext4load mmc 0:2 0x100000 dtb ; ext4load mmc 0:2 0x800000 vmlinuz-4.7.0-1-armmp ; ext4load mmc 0:2 0x1800000 initrd.img-4.7.0-1-armmp.uimage ; bootz 0x800000 0x1800000 0x100000
| dnsip=10.100.3.2
| eth1addr=48:5b:39:c9:ec:74
| eth2addr=48:5b:39:c9:ec:75
| eth3addr=48:5b:39:c9:ec:76
| ethact=ethernet@30000
| ethprime=egiga1
| fdt_high=0x10000000
| fdtcontroladdr=3fb51e58
| fileaddr=100000
| filesize=4961
| gatewayip=10.100.3.1
| initrd_high=0x10000000
| ipaddr=10.100.3.3
| netmask=255.255.255.224
| serverip=10.100.3.2
| stderr=serial@12000
| stdin=serial@12000
| stdout=serial@12000
| bootdelay=5

| # cat /etc/fw_env.config
| /dev/mmcblk0 0xf0000 0x10000 0x1000

Regards

  Christoph

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: armhf (armv7l)

Kernel: Linux 4.7.0-1-armmp (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages flash-kernel depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  devio                  1.2-1.2
ii  initramfs-tools        0.125
ii  linux-base             4.5
ii  mtd-utils              1:1.5.2-1
ii  ucf                    3.0036

Versions of packages flash-kernel recommends:
ii  u-boot-tools  2016.03+dfsg1-6

flash-kernel suggests no packages.

-- debconf information excluded

-- 
9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#839595; Package flash-kernel. (Mon, 03 Oct 2016 07:51:03 GMT) (full text, mbox, link).

Acknowledgement sent to Karsten Merker <merker@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Mon, 03 Oct 2016 07:51:03 GMT) (full text, mbox, link).

Message #10 received at 839595@bugs.debian.org (full text, mbox, reply):

On Sun, Oct 02, 2016 at 04:53:58PM +0200, Christoph Egger wrote:

> Package: flash-kernel
> Version: 3.69
> Severity: wishlist
> 
> Hi!
> 
> Please consider adding clearfog support. The system works fine with
> mainline u-boot + kernel. Hopefully I have added all necessary
> information below:
> 
> | Machine: SolidRun Clearfog A1
> | Kernel-Flavors: armmp armmp-lpae
> | DTB-Id: armada-388-clearfog.dtb
> | Required-Packages: u-boot-tools
> 
> | # fw_printenv
> | baudrate=115200
> | bootargs=console=ttyS0,115200n8 rootdelay=10 bootwait=10 rootwait=10 root=/dev/mmcblk0p1
> | bootcmd=ext4load mmc 0:2 0x100000 dtb ; ext4load mmc 0:2 0x800000 vmlinuz-4.7.0-1-armmp ; ext4load mmc 0:2 0x1800000 initrd.img-4.7.0-1-armmp.uimage ; bootz 0x800000 0x1800000 0x100000

Hello Christoph,

is this the environment from mainline u-boot or the environment
from the original Marvell u-boot?  I ask because there are a few
things that look a bit uncommon to me:

- This environment doesn't seem to be based on the common boot
  environment that mainline u-boot uses on most (although not
  all) modern platforms since v2014.10.  I am not familiar with
  the armada-388 platform, so I currently don't know whether it
  has moved to the common boot environment or not.

- The bootcmd loads the kernel as a zImage but the initrd as a
  uImage, which is a very unusual combination and I am unsure
  whether that could even work properly.  The normal case is
  either loading the kernel as a zImage and the initrd as a plain
  initrd image and booting them with bootz, or loading both the
  kernel and the initrd as uImages and booting them with bootm.

Is mmc0 an SD card or an EMMC chip? Have you upgraded the system
from a marvell u-boot to a mainline u-boot or has it been set up
from scratch with a mainline u-boot?  I ask because mainline
u-boot by default keeps the existing environment on upgrade, so
if you have upgraded the system from a marvell u-boot to a
mainline u-boot, you might still have an old non-mainline
environment.

You could try running "env default -f -a" at the u-boot prompt,
which would reset your active environment to the default
environment of the u-boot version you are currently running.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Acknowledgement sent to Christoph Egger <christoph@christoph-egger.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Mon, 03 Oct 2016 09:33:05 GMT) (full text, mbox, link).

Message #15 received at 839595@bugs.debian.org (full text, mbox, reply):

Hi!

Karsten Merker <merker@debian.org> writes:
> is this the environment from mainline u-boot or the environment
> from the original Marvell u-boot?  I ask because there are a few
> things that look a bit uncommon to me:

This is a mainline 2016.9 u-boot (clearfog_defconfig)

> - The bootcmd loads the kernel as a zImage but the initrd as a
>   uImage, which is a very unusual combination and I am unsure
>   whether that could even work properly.  The normal case is
>   either loading the kernel as a zImage and the initrd as a plain
>   initrd image and booting them with bootz, or loading both the
>   kernel and the initrd as uImages and booting them with bootm.

Works fine:

| => ext4load mmc 0:2 0x100000 armada-388-clearfog.dtb ; ext4load mmc 0:2 0x800000 vmlinuz-4.7.0-1-armmp ; ext4load mmc 0:2 0x1800000 initrd.img-4.7.0-1-armmp.uimage ; bootz 0x800000 0x1800000 0x100000
| 18060 bytes read in 79 ms (222.7 KiB/s)
| 3699848 bytes read in 237 ms (14.9 MiB/s)
| 15982059 bytes read in 787 ms (19.4 MiB/s)
| ## Loading init Ramdisk from Legacy Image at 01800000 ...
|    Image Name:   initrd.img-4.7.0-1-armmp
|    Image Type:   ARM Linux RAMDisk Image (uncompressed)
|    Data Size:    15981995 Bytes = 15.2 MiB
|    Load Address: 00000000
|    Entry Point:  00000000
|    Verifying Checksum ... OK
| ## Flattened Device Tree blob at 00100000
|    Booting using the fdt blob at 0x100000
|    Loading Ramdisk to 0f0c2000, end 0ffffdab ... OK
|    Loading Device Tree to 0f0ba000, end 0f0c168b ... OK
| 
| Starting kernel ...

With plain initrd:

| => ext4load mmc 0:2 0x100000 armada-388-clearfog.dtb ; ext4load mmc 0:2 0x800000 vmlinuz-4.7.0-1-armmp ; ext4load mmc 0:2 0x1800000 initrd.img-4.7.0-1-armmp ; bootz 0x800000 0x1800000 0x100000
| 18060 bytes read in 79 ms (222.7 KiB/s)
| 3699848 bytes read in 237 ms (14.9 MiB/s)
| 15981995 bytes read in 796 ms (19.1 MiB/s)
| Wrong Ramdisk Image Format
| Ramdisk image is corrupt or invalid

> Is mmc0 an SD card or an EMMC chip? Have you upgraded the system
> from a marvell u-boot to a mainline u-boot or has it been set up
> from scratch with a mainline u-boot?  I ask because mainline
> u-boot by default keeps the existing environment on upgrade, so
> if you have upgraded the system from a marvell u-boot to a
> mainline u-boot, you might still have an old non-mainline
> environment.

eMMC chip. as far as I know there was no u-boot shipped on the eMMC
(booting via UART works quite well)

> You could try running "env default -f -a" at the u-boot prompt,
> which would reset your active environment to the default
> environment of the u-boot version you are currently running.

| => env default -f -a
| ## Resetting to default environment
| => printenv
| baudrate=115200
| bootdelay=3
| fdt_high=0x10000000
| initrd_high=0x10000000
| 
| Environment size: 80/65532 bytes

  Christoph

-- 
9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer

Message #20 received at 839595@bugs.debian.org (full text, mbox, reply):

On Mon, Oct 03, 2016 at 11:32:15AM +0200, Christoph Egger wrote:
> Karsten Merker <merker@debian.org> writes:
> > is this the environment from mainline u-boot or the environment
> > from the original Marvell u-boot?  I ask because there are a few
> > things that look a bit uncommon to me:
> 
> This is a mainline 2016.9 u-boot (clearfog_defconfig)
> 
> > - The bootcmd loads the kernel as a zImage but the initrd as a
> >   uImage, which is a very unusual combination and I am unsure
> >   whether that could even work properly.  The normal case is
> >   either loading the kernel as a zImage and the initrd as a plain
> >   initrd image and booting them with bootz, or loading both the
> >   kernel and the initrd as uImages and booting them with bootm.
> 
> Works fine:
> 
> | => ext4load mmc 0:2 0x100000 armada-388-clearfog.dtb ; ext4load mmc 0:2 0x800000 vmlinuz-4.7.0-1-armmp ; ext4load mmc 0:2 0x1800000 initrd.img-4.7.0-1-armmp.uimage ; bootz 0x800000 0x1800000 0x100000
> | 18060 bytes read in 79 ms (222.7 KiB/s)
> | 3699848 bytes read in 237 ms (14.9 MiB/s)
> | 15982059 bytes read in 787 ms (19.4 MiB/s)
> | ## Loading init Ramdisk from Legacy Image at 01800000 ...
> |    Image Name:   initrd.img-4.7.0-1-armmp
> |    Image Type:   ARM Linux RAMDisk Image (uncompressed)
> |    Data Size:    15981995 Bytes = 15.2 MiB
> |    Load Address: 00000000
> |    Entry Point:  00000000
> |    Verifying Checksum ... OK
> | ## Flattened Device Tree blob at 00100000
> |    Booting using the fdt blob at 0x100000
> |    Loading Ramdisk to 0f0c2000, end 0ffffdab ... OK
> |    Loading Device Tree to 0f0ba000, end 0f0c168b ... OK
> | 
> | Starting kernel ...
> 
> With plain initrd:
> 
> | => ext4load mmc 0:2 0x100000 armada-388-clearfog.dtb ; ext4load mmc 0:2 0x800000 vmlinuz-4.7.0-1-armmp ; ext4load mmc 0:2 0x1800000 initrd.img-4.7.0-1-armmp ; bootz 0x800000 0x1800000 0x100000
> | 18060 bytes read in 79 ms (222.7 KiB/s)
> | 3699848 bytes read in 237 ms (14.9 MiB/s)
> | 15981995 bytes read in 796 ms (19.1 MiB/s)
> | Wrong Ramdisk Image Format
> | Ramdisk image is corrupt or invalid

When using bootz with a standard format initrd, one must pass the
initrd size to bootz.  Could you try the following command to
boot with a plain initrd?

ext4load mmc 0:2 0x100000 armada-388-clearfog.dtb ; ext4load mmc 0:2 0x800000 vmlinuz-4.7.0-1-armmp ; ext4load mmc 0:2 0x1800000 initrd.img-4.7.0-1-armmp ; bootz 0x800000 0x1800000:${filesize} 0x100000

> > You could try running "env default -f -a" at the u-boot prompt,
> > which would reset your active environment to the default
> > environment of the u-boot version you are currently running.
> 
> | => env default -f -a
> | ## Resetting to default environment
> | => printenv
> | baudrate=115200
> | bootdelay=3
> | fdt_high=0x10000000
> | initrd_high=0x10000000
> | 
> | Environment size: 80/65532 bytes

Well, that is a _very_ minimalistic default environment ;-).
So there isn't any boot command handling at all in the default
environment of mainline u-boot for this system, which poses a
problem for supporting this setup in flash-kernel.

The proper solution would be to setup the default environment for
this board in mainline u-boot by including distro_bootcmd.h:

http://git.denx.de/?p=u-boot.git;a=blob;f=include/config_distro_bootcmd.h;h=9ecaf38a3300c3efd68e3f00f353b91c4dbe14f2;hb=HEAD

This provides a cross-platform boot environment with standardized
interfaces as documented in

http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.distro;h=77d5c6d4d56f90f6ba1ed237ca3927901f47d936;hb=HEAD

Once this standard environment is present, flash-kernel can
make use of the infrastructure provided by it.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Message #25 received at 839595@bugs.debian.org (full text, mbox, reply):

Hi!

Karsten Merker <merker@debian.org> writes:
> Well, that is a _very_ minimalistic default environment ;-).
> So there isn't any boot command handling at all in the default
> environment of mainline u-boot for this system, which poses a
> problem for supporting this setup in flash-kernel.

I supposed this is CONFIG_DISTRO_DEFAULTS? I'll rebuild u-boot and see
(also for the plain initrd)

  Christoph

-- 
9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer

Message #30 received at 839595@bugs.debian.org (full text, mbox, reply):

Hi!

Karsten Merker <merker@debian.org> writes:
> ext4load mmc 0:2 0x100000 armada-388-clearfog.dtb ; ext4load mmc 0:2
> 0x800000 vmlinuz-4.7.0-1-armmp ; ext4load mmc 0:2 0x1800000
> initrd.img-4.7.0-1-armmp ; bootz 0x800000 0x1800000:${filesize}
> 0x100000

=> ext4load mmc 0:2 0x100000 armada-388-clearfog.dtb ; ext4load mmc 0:2 0x800000 vmlinuz-4.7.0-1-armmp ; ext4load mmc 0:2 0x1800000 initrd.img-4.7.0-1-armmp ; bootz 0x800000 0x1800000:${filesize} 0x100000
18060 bytes read in 79 ms (222.7 KiB/s)
3699848 bytes read in 237 ms (14.9 MiB/s)
15981995 bytes read in 796 ms (19.1 MiB/s)
Wrong Ramdisk Image Format
Ramdisk image is corrupt or invalid


-- 
9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer

Message #35 received at 839595@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Mon, Oct 03, 2016 at 01:32:22PM +0200, Christoph Egger wrote:
> Karsten Merker <merker@debian.org> writes:
> > Well, that is a _very_ minimalistic default environment ;-).
> > So there isn't any boot command handling at all in the default
> > environment of mainline u-boot for this system, which poses a
> > problem for supporting this setup in flash-kernel.
> 
> I supposed this is CONFIG_DISTRO_DEFAULTS? I'll rebuild u-boot and see
> (also for the plain initrd)

Yes and no :-).

Setting CONFIG_DISTRO_DEFAULTS is required to enable the commands
that are used by the common boot environment, but it doesn't
automatically include the actual environment.

The attached patch enables CONFIG_DISTRO_DEFAULTS and includes
the necessary headers to define the common environment (only
build-tested due to lack of appropriate hardware).  One thing
that is still missing in the patch is the definition of various
default load addresses (fdt_addr_r, ramdisk_addr_r,
kernel_addr_r, pxefile_addr_r, scriptaddr).  Is there an
"official" list of the standard load addresses for this platform
so that I could add them to the patch?

Could you please build u-boot with the attached patch and
send the output of "env default -f -a; printenv"?

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

[0001-Enable-the-common-distro-boot-environment-for-the-cl.patch (text/x-diff, attachment)]

Message #40 received at 839595@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Mon, Oct 03, 2016 at 02:44:10PM +0200, Karsten Merker wrote:

> The attached patch enables CONFIG_DISTRO_DEFAULTS and includes
> the necessary headers to define the common environment (only
> build-tested due to lack of appropriate hardware).  One thing
> that is still missing in the patch is the definition of various
> default load addresses (fdt_addr_r, ramdisk_addr_r,
> kernel_addr_r, pxefile_addr_r, scriptaddr).  Is there an
> "official" list of the standard load addresses for this platform
> so that I could add them to the patch?
> 
> Could you please build u-boot with the attached patch and
> send the output of "env default -f -a; printenv"?

Hello,

I've just found that I made a mistake in the patch - as a result
it builds, but probably won't work properly.  The additional
include statement in include/configs/clearfog.h must be moved
from the beginning of the file to the end of the file, otherwise
some definitions on which the header relies aren't defined
properly.

Attached is a new version of the patch (again build-tested only
due to lack of appropriate hardware).

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

[0001-Enable-the-common-distro-boot-environment-for-the-cl.patch (text/x-diff, attachment)]

Message #45 received at 839595@bugs.debian.org (full text, mbox, reply):

Hi!

Karsten Merker <merker@debian.org> writes:
> The attached patch enables CONFIG_DISTRO_DEFAULTS and includes
> the necessary headers to define the common environment (only
> build-tested due to lack of appropriate hardware).  One thing
> that is still missing in the patch is the definition of various
> default load addresses (fdt_addr_r, ramdisk_addr_r,
> kernel_addr_r, pxefile_addr_r, scriptaddr).  Is there an
> "official" list of the standard load addresses for this platform
> so that I could add them to the patch?

I don't know any

> Could you please build u-boot with the attached patch and
> send the output of "env default -f -a; printenv"?

=> env default -f -a
## Resetting to default environment
=> printenv
arch=arm
baudrate=115200
board=clearfog
board_name=clearfog
bootcmd=run distro_bootcmd
bootdelay=3
cpu=armv7
fdt_high=0x10000000
initrd_high=0x10000000
soc=mvebu
vendor=solidrun

Environment size: 201/65532 bytes


-- 
9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer

Message #50 received at 839595@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Mon, Oct 03, 2016 at 05:53:14PM +0200, Christoph Egger wrote:
> Karsten Merker <merker@debian.org> writes:
> > The attached patch enables CONFIG_DISTRO_DEFAULTS and includes
> > the necessary headers to define the common environment (only
> > build-tested due to lack of appropriate hardware).  One thing
> > that is still missing in the patch is the definition of various
> > default load addresses (fdt_addr_r, ramdisk_addr_r,
> > kernel_addr_r, pxefile_addr_r, scriptaddr).  Is there an
> > "official" list of the standard load addresses for this platform
> > so that I could add them to the patch?
> 
> I don't know any
> 
> > Could you please build u-boot with the attached patch and
> > send the output of "env default -f -a; printenv"?
> 
> => env default -f -a
> ## Resetting to default environment
> => printenv
> arch=arm
> baudrate=115200
> board=clearfog
> board_name=clearfog
> bootcmd=run distro_bootcmd
> bootdelay=3
> cpu=armv7
> fdt_high=0x10000000
> initrd_high=0x10000000
> soc=mvebu
> vendor=solidrun
> 
> Environment size: 201/65532 bytes

Ok, that's only a part of what I had originally intended. 
Attached is a third version of the patch.  Could you try that as
well and send the output of "env default -f -a; printenv"?

I have used the values from your old environment for defining the
kernel, initrd and dtb load addresses.  For the pxelinux config
files and for the bootscripts I have no indication where they
might be usually placed on this platform, so I have (more or less
randomly) placed them behind the dtb and before the kernel.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

[0001-Enable-the-common-distro-boot-environment-for-the-cl.patch (text/x-diff, attachment)]

Acknowledgement sent to Christoph Egger <christoph@sieglitzhof.net>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Mon, 24 Oct 2016 13:27:02 GMT) (full text, mbox, link).

Message #55 received at 839595@bugs.debian.org (full text, mbox, reply):

Hi!

This seems to be the "new" default environment:

=> printenv
arch=arm
baudrate=115200
board=clearfog
board_name=clearfog
boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootarm.efi; if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}extlinux/extlinux.conf
boot_net_usb_start=usb start
boot_prefixes=/ /boot/
boot_script_dhcp=boot.scr.uimg
boot_scripts=boot.scr.uimg boot.scr
boot_targets=mmc0 usb0 pxe dhcp 
bootcmd=run distro_bootcmd
bootcmd_dhcp=run boot_net_usb_start; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile ${fdtfile}; if test -z "${fdtfile}" -a -n "${soc}"; then setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; fi; setenv efi_old_vci ${bootp_vci};setenv efi_old_arch ${bootp_arch};setenv bootp_vci PXEClient:Arch:00010:UNDI:003000;setenv bootp_arch 0xa;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r}; else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv bootp_vci ${efi_old_vci};setenv bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv efi_old_arch;setenv efi_old_vci;
bootcmd_mmc0=setenv devnum 0; run mmc_boot
bootcmd_pxe=run boot_net_usb_start; dhcp; if pxe get; then pxe boot; fi
bootcmd_usb0=setenv devnum 0; run usb_boot
bootdelay=3
console=ttyS0,115200
cpu=armv7
devnum=0
devplist=1
devtype=mmc
distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
efi_dtb_prefixes=/ /dtb/ /dtb/current/
fdt_addr_r=0x100000
fdt_high=0x10000000
fdtcontroladdr=3fb4ce58
fdtfile=armada-388-clearfog.dtb
initrd_high=0x10000000
kernel_addr_r=0x800000
load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile}
mmc_boot=if mmc dev ${devnum}; then setenv devtype mmc; run scan_dev_for_boot_part; fi
pxefile_addr_r=0x300000
ramdisk_addr_r=0x1800000
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi;
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done
scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; if test -z "${fdtfile}" -a -n "${soc}"; then setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; fi; for prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run load_efi_dtb; fi;done;if test -e ${devtype} ${devnum}:${distro_bootpart} efi/boot/bootarm.efi; then echo Found EFI removable media binary efi/boot/bootarm.efi; run boot_efi_binary; echo EFI LOAD FAILED: continuing...; fi; setenv efi_fdtfile
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}extlinux/extlinux.conf; then echo Found ${prefix}extlinux/extlinux.conf; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
scriptaddr=0x200000
soc=mvebu
stderr=serial@12000
stdin=serial@12000
stdout=serial@12000
usb_boot=usb start; if usb dev ${devnum}; then setenv devtype usb; run scan_dev_for_boot_part; fi
vendor=solidrun

Environment size: 3819/65532 bytes


-- 
9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#839595; Package flash-kernel. (Sat, 17 Dec 2016 22:33:02 GMT) (full text, mbox, link).

Acknowledgement sent to Martin Michlmayr <tbm@cyrius.com>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Sat, 17 Dec 2016 22:33:02 GMT) (full text, mbox, link).

Message #60 received at 839595@bugs.debian.org (full text, mbox, reply):

I was just looking at this bug report and it seems Karsten was never
copied on Christoph's last email (see below).

* Christoph Egger <christoph@sieglitzhof.net> [2016-10-24 15:22]:
> Hi!
> 
> This seems to be the "new" default environment:
> 
> => printenv
> arch=arm
> baudrate=115200
> board=clearfog
> board_name=clearfog
> boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
> boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootarm.efi; if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi
> boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}extlinux/extlinux.conf
> boot_net_usb_start=usb start
> boot_prefixes=/ /boot/
> boot_script_dhcp=boot.scr.uimg
> boot_scripts=boot.scr.uimg boot.scr
> boot_targets=mmc0 usb0 pxe dhcp 
> bootcmd=run distro_bootcmd
> bootcmd_dhcp=run boot_net_usb_start; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile ${fdtfile}; if test -z "${fdtfile}" -a -n "${soc}"; then setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; fi; setenv efi_old_vci ${bootp_vci};setenv efi_old_arch ${bootp_arch};setenv bootp_vci PXEClient:Arch:00010:UNDI:003000;setenv bootp_arch 0xa;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r}; else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv bootp_vci ${efi_old_vci};setenv bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv efi_old_arch;setenv efi_old_vci;
> bootcmd_mmc0=setenv devnum 0; run mmc_boot
> bootcmd_pxe=run boot_net_usb_start; dhcp; if pxe get; then pxe boot; fi
> bootcmd_usb0=setenv devnum 0; run usb_boot
> bootdelay=3
> console=ttyS0,115200
> cpu=armv7
> devnum=0
> devplist=1
> devtype=mmc
> distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
> efi_dtb_prefixes=/ /dtb/ /dtb/current/
> fdt_addr_r=0x100000
> fdt_high=0x10000000
> fdtcontroladdr=3fb4ce58
> fdtfile=armada-388-clearfog.dtb
> initrd_high=0x10000000
> kernel_addr_r=0x800000
> load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile}
> mmc_boot=if mmc dev ${devnum}; then setenv devtype mmc; run scan_dev_for_boot_part; fi
> pxefile_addr_r=0x300000
> ramdisk_addr_r=0x1800000
> scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi;
> scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done
> scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; if test -z "${fdtfile}" -a -n "${soc}"; then setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; fi; for prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run load_efi_dtb; fi;done;if test -e ${devtype} ${devnum}:${distro_bootpart} efi/boot/bootarm.efi; then echo Found EFI removable media binary efi/boot/bootarm.efi; run boot_efi_binary; echo EFI LOAD FAILED: continuing...; fi; setenv efi_fdtfile
> scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}extlinux/extlinux.conf; then echo Found ${prefix}extlinux/extlinux.conf; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
> scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
> scriptaddr=0x200000
> soc=mvebu
> stderr=serial@12000
> stdin=serial@12000
> stdout=serial@12000
> usb_boot=usb start; if usb dev ${devnum}; then setenv devtype usb; run scan_dev_for_boot_part; fi
> vendor=solidrun
> 
> Environment size: 3819/65532 bytes
> 
> 
> -- 
> 9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
> Debian Developer | Lisp Hacker | CaCert Assurer

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

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#839595; Package flash-kernel. (Sun, 18 Dec 2016 17:09:02 GMT) (full text, mbox, link).

Acknowledgement sent to Karsten Merker <merker@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Sun, 18 Dec 2016 17:09:02 GMT) (full text, mbox, link).

Message #65 received at 839595@bugs.debian.org (full text, mbox, reply):

On Sat, Dec 17, 2016 at 02:29:09PM -0800, Martin Michlmayr wrote:
> I was just looking at this bug report and it seems Karsten was never
> copied on Christoph's last email (see below).
> 
> * Christoph Egger <christoph@sieglitzhof.net> [2016-10-24 15:22]:
> > Hi!
> > 
> > This seems to be the "new" default environment:
> > 
> > => printenv
> > arch=arm
> > baudrate=115200
> > board=clearfog
> > board_name=clearfog
> > boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
> > boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootarm.efi; if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi
> > boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}extlinux/extlinux.conf
> > boot_net_usb_start=usb start
> > boot_prefixes=/ /boot/
> > boot_script_dhcp=boot.scr.uimg
> > boot_scripts=boot.scr.uimg boot.scr
> > boot_targets=mmc0 usb0 pxe dhcp 
> > bootcmd=run distro_bootcmd
> > bootcmd_dhcp=run boot_net_usb_start; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile ${fdtfile}; if test -z "${fdtfile}" -a -n "${soc}"; then setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; fi; setenv efi_old_vci ${bootp_vci};setenv efi_old_arch ${bootp_arch};setenv bootp_vci PXEClient:Arch:00010:UNDI:003000;setenv bootp_arch 0xa;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r}; else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv bootp_vci ${efi_old_vci};setenv bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv efi_old_arch;setenv efi_old_vci;
> > bootcmd_mmc0=setenv devnum 0; run mmc_boot
> > bootcmd_pxe=run boot_net_usb_start; dhcp; if pxe get; then pxe boot; fi
> > bootcmd_usb0=setenv devnum 0; run usb_boot
> > bootdelay=3
> > console=ttyS0,115200
> > cpu=armv7
> > devnum=0
> > devplist=1
> > devtype=mmc
> > distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
> > efi_dtb_prefixes=/ /dtb/ /dtb/current/
> > fdt_addr_r=0x100000
> > fdt_high=0x10000000
> > fdtcontroladdr=3fb4ce58
> > fdtfile=armada-388-clearfog.dtb
> > initrd_high=0x10000000
> > kernel_addr_r=0x800000
> > load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile}
> > mmc_boot=if mmc dev ${devnum}; then setenv devtype mmc; run scan_dev_for_boot_part; fi
> > pxefile_addr_r=0x300000
> > ramdisk_addr_r=0x1800000
> > scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi;
> > scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done
> > scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; if test -z "${fdtfile}" -a -n "${soc}"; then setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; fi; for prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run load_efi_dtb; fi;done;if test -e ${devtype} ${devnum}:${distro_bootpart} efi/boot/bootarm.efi; then echo Found EFI removable media binary efi/boot/bootarm.efi; run boot_efi_binary; echo EFI LOAD FAILED: continuing...; fi; setenv efi_fdtfile
> > scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}extlinux/extlinux.conf; then echo Found ${prefix}extlinux/extlinux.conf; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
> > scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
> > scriptaddr=0x200000
> > soc=mvebu
> > stderr=serial@12000
> > stdin=serial@12000
> > stdout=serial@12000
> > usb_boot=usb start; if usb dev ${devnum}; then setenv devtype usb; run scan_dev_for_boot_part; fi
> > vendor=solidrun
> > 
> > Environment size: 3819/65532 bytes

Hello,

that looks good. With this environment, using the "generic"
boot script should work.

Christoph, could you perform a test with a current u-boot by
applying my environment patch on top of u-boot v2016.11 and
putting the follwing stanza into /etc/flash-kernel/db ?

Machine: SolidRun Clearfog A1
Kernel-Flavors: armmp armmp-lpae
Boot-Script-Path: /boot/boot.scr
DTB-Id: armada-388-clearfog.dtb
U-Boot-Script-Name: bootscr.uboot-generic
Required-Packages: u-boot-tools

(This stanza is based on the assumption that booting plain
initrds works when bootz is passed the corresponding filesize. I
still don't understand why you got a "Wrong Ramdisk Image Format"
when manually booting a plain initrd with u-boot v2016.09.)

With the aforementioned stanza, running flash-kernel on the
commandline should generate a proper boot script in
/boot/boot.scr that should be automatically loaded by u-boot on
reboot.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#839595; Package flash-kernel. (Tue, 20 Dec 2016 18:03:02 GMT) (full text, mbox, link).

Acknowledgement sent to Christoph Egger <christoph@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Tue, 20 Dec 2016 18:03:02 GMT) (full text, mbox, link).

Message #70 received at 839595@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi!

Martin Michlmayr <tbm@cyrius.com> writes:
> I was just looking at this bug report and it seems Karsten was never
> copied on Christoph's last email (see below).

Sorry for that. And I just didn't want to nag if people are busy.

Karsten Merker <merker@debian.org> writes:
> that looks good. With this environment, using the "generic"
> boot script should work.
>
> Christoph, could you perform a test with a current u-boot by
> applying my environment patch on top of u-boot v2016.11 and
> putting the follwing stanza into /etc/flash-kernel/db ?
>
> Machine: SolidRun Clearfog A1
> Kernel-Flavors: armmp armmp-lpae
> Boot-Script-Path: /boot/boot.scr
> DTB-Id: armada-388-clearfog.dtb
> U-Boot-Script-Name: bootscr.uboot-generic
> Required-Packages: u-boot-tools
>
> (This stanza is based on the assumption that booting plain
> initrds works when bootz is passed the corresponding filesize. I
> still don't understand why you got a "Wrong Ramdisk Image Format"
> when manually booting a plain initrd with u-boot v2016.09.)
>
> With the aforementioned stanza, running flash-kernel on the
> commandline should generate a proper boot script in
> /boot/boot.scr that should be automatically loaded by u-boot on
> reboot.

I'll try to get the results today/tomorrow night .. if I don't reply
it'll be mid-january unfortunately

  Christoph

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#839595; Package flash-kernel. (Tue, 27 Dec 2016 14:09:05 GMT) (full text, mbox, link).

Message #75 received at 839595@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi all!

Christoph Egger <christoph@debian.org> writes:
> I'll try to get the results today/tomorrow night .. if I don't reply
> it'll be mid-january unfortunately

I added the snippet to /etc/flash-kernel/db now. I had to do the
following further steps (but I guess that's expected):

 - put the adapted dtb at the kernel location (where flash-kernel copies
   it from)
 - fw_setenv distro_bootpart 2
 - actually configure flash-kernel to include root=/dev/mmcblk0p1 in the
   kernel comandline

Indeed it seems to boot with the initrd now just fine!

I haven't updated u-boot yet, though it's still on my todo .. only have
my kfreebsd notebook with me so I might only get one try unless kwboot
uart recovery is made to work on this platform.

  Christoph

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#839595; Package flash-kernel. (Tue, 27 Dec 2016 16:57:05 GMT) (full text, mbox, link).

Message #80 received at 839595@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi!

Christoph Egger <christoph@debian.org> writes:
> I haven't updated u-boot yet, though it's still on my todo

Seems to have worked. I have now u-boot 2016-11 SPL and "normal"
u-boot and everything works so far \o/

  Christoph

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#839595; Package flash-kernel. (Fri, 17 Mar 2017 23:33:02 GMT) (full text, mbox, link).

Acknowledgement sent to Martin Michlmayr <tbm@cyrius.com>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Fri, 17 Mar 2017 23:33:02 GMT) (full text, mbox, link).

Message #85 received at 839595@bugs.debian.org (full text, mbox, reply):

* Christoph Egger <christoph@debian.org> [2016-12-27 17:55]:
> Christoph Egger <christoph@debian.org> writes:
> > I haven't updated u-boot yet, though it's still on my todo
> 
> Seems to have worked. I have now u-boot 2016-11 SPL and "normal"
> u-boot and everything works so far \o/

Karsten, I think this one is waiting for you.  Can you take a look?

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

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#839595; Package flash-kernel. (Sun, 23 Jul 2017 14:51:05 GMT) (full text, mbox, link).

Acknowledgement sent to Josua Mayer <josua.mayer97@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Sun, 23 Jul 2017 14:51:05 GMT) (full text, mbox, link).

Message #90 received at 839595@bugs.debian.org (full text, mbox, reply):

Hi there,

Can anyone state the status here? If there is somethign missing, I'd be 
perfectly willing to conduct some tests on my board if necessary.

br
Josua Mayer

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#839595; Package flash-kernel. (Sun, 23 Jul 2017 17:00:02 GMT) (full text, mbox, link).

Acknowledgement sent to Vagrant Cascadian <vagrant@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Sun, 23 Jul 2017 17:00:02 GMT) (full text, mbox, link).

Message #95 received at 839595@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On 2017-07-23, Josua Mayer wrote:
> Can anyone state the status here? If there is somethign missing, I'd be 
> perfectly willing to conduct some tests on my board if necessary.

It looks like clearfog supports distro_bootcmd in mainline u-boot
2017.07 shipped in buster, including CONFIG_SUPPORT_RAW_INITRD, which is
required to boot an initrd without u-boot headers.

On a related note, nobody has requested the clearfog target be enabled
in the u-boot packages in Debian:

  https://wiki.debian.org/U-boot/

If someone can offer to regularly test that, I'd be happy to enable it
in u-boot.

I don't think that should be a blocker for including it into
flash-kernel, though.

live well,
  vagrant

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#839595; Package flash-kernel. (Sun, 06 Aug 2017 12:03:03 GMT) (full text, mbox, link).

Message #100 received at 839595@bugs.debian.org (full text, mbox, reply):

Hi Vagrant, thanks for the reply.

On Sun, 23 Jul 2017 12:56:35 -0400 Vagrant Cascadian
<vagrant@debian.org> wrote:
> On a related note, nobody has requested the clearfog target be enabled
> in the u-boot packages in Debian:
>
> https://wiki.debian.org/U-boot/
>
> If someone can offer to regularly test that, I'd be happy to enable it
> in u-boot.
I'd be happy to do that, what is the process?
>
>
> I don't think that should be a blocker for including it into
> flash-kernel, though.
>
>
> live well,
> vagrant

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#839595; Package flash-kernel. (Sat, 19 Aug 2017 14:48:13 GMT) (full text, mbox, link).

Acknowledgement sent to Josua Mayer <josua.mayer97@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Sat, 19 Aug 2017 14:48:13 GMT) (full text, mbox, link).

Message #105 received at 839595@bugs.debian.org (full text, mbox, reply):

Hi again everybody,

I finally got around to trying this out myself using a freshly
debootstrapped stretch, and 2017.07-rc3 u-boot and these are my findings
with the early posted db entry:

The device-tree gets copied as expected
boot.scr gets generated
root= argument is not added to cmdline: That is actually fine!

I still had some trouble with mounting the rootfs, because it turns out
I used /dev/root short-hand in my fstab.
This is a problem because flash-kernel picks that value up and stores it
as conf/conf.d/default_root.
Obviously passing root=/dev/root makes no sense to the kernel.
I might even go as far as suggesting to not populate default_root if it
is set to this magical value!
Anyway after putting a UUID=... line in my fstab its all good!

And now to question the Kernel-Flavors Line:
Does anybody know if the Armada 388 supports lpae? I did not manage
finding sufficient information.
However I can tell you that the current linux-image-4.9.0-3-armmp-lpae
does *not* boot!
That means the serial console stays quiet after "Starting kernel ..."

So I now have this database entry:
Machine: SolidRun Clearfog A1
Kernel-Flavors: armmp
Boot-Script-Path: /boot/boot.scr
DTB-Id: armada-388-clearfog.dtb
U-Boot-Script-Name: bootscr.uboot-generic
Required-Packages: u-boot-tools

br
Josua Mayer

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#839595; Package flash-kernel. (Sat, 19 Aug 2017 14:57:03 GMT) (full text, mbox, link).

Acknowledgement sent to Josua Mayer <josua.mayer97@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Sat, 19 Aug 2017 14:57:03 GMT) (full text, mbox, link).

Message #110 received at 839595@bugs.debian.org (full text, mbox, reply):

Hi there,

Now it is time to raise a different problem: Hardware Variants.
Right now we have the Clearfog Pro, and the Clearfog Base.
The future might bring also introduce other CPU variants different from
Armada-388 (but thats pure speculation).

The Device-Tree was actually renamed in mainline with
712032aa65ae19a613488f8ce956e575cc5e1486, to
armada-388-clearfog-pro.dts. That one sets the model field to "SolidRun
Clearfog Pro A1".

Then we have the "SolidRun Clearfog Base A1" in
armada-388-clearfog-base.dts.

How can these variants be mirrored in flash-kernel? And is there a way
to allow moving SD-Cards between device variants? That would be a
*really* useful feature!

Either way, what can we do about this?

br
Josua Mayer

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#839595; Package flash-kernel. (Wed, 18 Oct 2017 13:57:06 GMT) (full text, mbox, link).

Acknowledgement sent to Josua Mayer <josua.mayer97@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Wed, 18 Oct 2017 13:57:06 GMT) (full text, mbox, link).

Message #115 received at 839595@bugs.debian.org (full text, mbox, reply):

Hi everybody,

Pinging this issue in case it fell off the table.
If anything is preventing this from going forward that I can influence,
please let me know!

br
Josua Mayer

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#839595; Package flash-kernel. (Sat, 20 Jan 2018 02:09:03 GMT) (full text, mbox, link).

Acknowledgement sent to Vagrant Cascadian <vagrant@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Sat, 20 Jan 2018 02:09:03 GMT) (full text, mbox, link).

Message #120 received at 839595@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Control: tags 839595 pending

Pushed a commit to git:

  https://anonscm.debian.org/git/d-i/flash-kernel.git/commit/?id=175f11c79927fbc9527f5cce1bdfd2ad60d3ed50

Should be included in the next upload.


live well,
  vagrant

[signature.asc (application/pgp-signature, inline)]

Added tag(s) pending. Request was from Vagrant Cascadian <vagrant@debian.org> to 839595-submit@bugs.debian.org. (Sat, 20 Jan 2018 02:09:03 GMT) (full text, mbox, link).

Reply sent to Christian Perrier <bubulle@debian.org>:
You have taken responsibility. (Thu, 01 Feb 2018 06:54:07 GMT) (full text, mbox, link).

Notification sent to Christoph Egger <christoph@debian.org>:
Bug acknowledged by developer. (Thu, 01 Feb 2018 06:54:07 GMT) (full text, mbox, link).

Message #127 received at 839595-close@bugs.debian.org (full text, mbox, reply):

Source: flash-kernel
Source-Version: 3.91

We believe that the bug you reported is fixed in the latest version of
flash-kernel, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 839595@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Christian Perrier <bubulle@debian.org> (supplier of updated flash-kernel package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Thu, 01 Feb 2018 06:32:56 +0100
Source: flash-kernel
Binary: flash-kernel flash-kernel-installer
Architecture: source
Version: 3.91
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team <debian-boot@lists.debian.org>
Changed-By: Christian Perrier <bubulle@debian.org>
Description:
 flash-kernel - utility to make certain embedded devices bootable
 flash-kernel-installer - Make the system bootable (udeb)
Closes: 839595 860304 873390 876773 887803
Changes:
 flash-kernel (3.91) unstable; urgency=medium
 .
   [ Vagrant Cascadian ]
   * Make ubootenv.d work on CuBox-i. Thanks to Rainer Dorsch.
   * Do not install flash-kernel.in.
 .
   [ Heinrich Schuchardt ]
   * flash-kernel: Provide hook to start EFI application (Closes: #873390).
 .
   [ Vagrant Cascadian ]
   * Add support for SolidRun Clearfog Boards (Closes: #839595). Thanks to
     Christoph Egger and Joshua Mayer.
   * Add support for SolidRun CuBox (dove) (Closes: #876773). Thanks to
     Josua Mayer.
   * Fix when no Kernel-Flavors are defined (Closes: #887803).
   * Add Boot-Kernel-Path-Version and Boot-Initrd-Path-Version to be used
     to append the version to the generated kernel/initrd images.
   * debian/control: Set Rules-Requires-Root: no.
 .
   [ Heinrich Schuchardt ]
   * flash-kernel: support relative paths for DTB-Id (Closes: #860304).
 .
   [ Vagrant Cascadian ]
   * Add compatibility symlink to dtb in vendor sub-directory.
   * Add support for root device specified by PARTLABEL.
 .
   [ Andre Heider ]
   * Add support for multiple scripts sources
 .
   [ Vagrant Cascadian ]
   * Convert Wandboard and CuBox-i to use a shared imx-base plus
     uboot-generic boot script.
   * Adjust sunxi boot script to prefer prefix variable if defined to set
     the locations to search for boot files.
 .
   [ Updated translations ]
   * Tajik (tg.po) by Victor Ibragimov
Checksums-Sha1:
 4be42438dd306e0415ef3cf04fad9bbb68f48e5f 1854 flash-kernel_3.91.dsc
 6148176507ad6257a4732050f82686f4df0dbc46 71028 flash-kernel_3.91.tar.xz
Checksums-Sha256:
 4e2244a6307e720d27bd1ab7a8e553cce981d1e6e7d9162ef293af11ab605562 1854 flash-kernel_3.91.dsc
 8a3fa0b0b1476050e60b9cee5b4f4cf36b0d33dd80714e6cf9334ae290df6be1 71028 flash-kernel_3.91.tar.xz
Files:
 609ae88d3e66a981f4322bcd59862545 1854 utils optional flash-kernel_3.91.dsc
 cc46de9fdf9ad9ed787a4f07bbb59a79 71028 utils optional flash-kernel_3.91.tar.xz

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE1cL5v8oSi7oip3IYhy9wLE1uJagFAlpyqX8ACgkQhy9wLE1u
JahfZhAAg5EBp596FJjBJ/0Of4sMx8aN8on9VZu7Bw9EZEkWyWirYT+Z1a2vEKTX
ct54ARkC3RhZrfLywf69UJWHwlx8zBwsD0o3SQdu30I3cqdsRIix8JDiQH73rmX/
Yr1suDnE/KxywOzUyosXlYs4sbQNLrklRsrh8zA3zz1uWjDYr5NQVcpvxV/Q1l3H
uLv2E8HK/00WCCQWIn85uZk/0q6smBw/9YJKXJuXlEwv9YzMeA9fqAOjtAhgRTY2
waXM4zzRNCcYMqdPRkJ9M9vP2+hXu0ipjKHlw0SMcxi2vYYiaNt3sr2aBxI4QoKb
2Dy2uGDT6FJ2HarA0qkD0bJX8FCYDixj1jdKDi6tMTidIOzrKkwpfQ9j1hYuWpPq
ehM6A7HLoyhMekU4sqd9PqMHW/OJz1mZ3UiHES8TxWxVfQCwq2nQrgsNPBcZjkP9
CZilNtyLYVW7J8JMlGWTcTuJzRwy34hFUe4lv9MET2GYEtJJ0f7sw/qnhRhTolN5
BDdd96HU2SkZwWdktnEGDLPZaCTcHnNL1lQWyFbTr/cfTA+Oc9PGXmAdNNuBEQaO
SN4kwBQJAOxQxsIRQcJ5zwwGa/Gt1NygLPBH1pDOsfcZpuQKCW/DMTpa3R2JsTKm
dN9XC685Gut+5SJRin3beT4m7xXNmpSKTzMdYob3WE/I7iNBB0s=
=xYZo
-----END PGP SIGNATURE-----

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Tue, 06 Mar 2018 07:32:01 GMT) (full text, mbox, link).

Send a report that this bug log contains spam.

Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Mon Sep 25 13:45:12 2023; Machine Name: buxtehude

Debian Bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Debian Bug report logs - #839595 flash-kernel: Please add support for SolidRun Clearfog

Debian Bug report logs - #839595
flash-kernel: Please add support for SolidRun Clearfog