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

Re: Support for sunxi-based ARM systems in d-i



On Sun, Apr 27, 2014 at 07:35:35AM +0100, Ian Campbell wrote:
> On Sat, 2014-04-26 at 23:25 +0200, Karsten Merker wrote:

> > +setenv fdt_high ffffffff
> > +setenv initrd_high 0xffffffff
> 
> These shouldn't be needed with the latest sunxi u-boot.

Hello,

I have tried booting a zImage with bootz and without setting
fdt_high and initrd_high on a fairly recent u-boot (U-Boot
2014.04-01491-g303abf5i from Hans de Goede's sunxi-devel branch,
freshly built two days ago), but in this setup the system
freezes after "Starting kernel...":

  Jumping to boot.scr
  ## Executing script at 44000000
  3455880 bytes read in 1077 ms (3.1 MiB/s)
  22691 bytes read in 781 ms (28.3 KiB/s)
  2594398 bytes read in 1035 ms (2.4 MiB/s)
  ** File not found /vmlinuz **
  ** File not found /dtb **
  ** File not found /initrd.gz **
  Kernel image @ 0x46000000 [ 0x000000 - 0x34bb88 ]
  ## Flattened Device Tree blob at 47000000
     Booting using the fdt blob at 0x47000000
     Loading Ramdisk to bf8eb000, end bfb6465e ... OK
     Loading Device Tree to bf8e2000, end bf8ea8a2 ... OK

  Starting kernel ...

After running "setenv fdt_high ffffffff; setenv initrd_high
0xffffffff; saveenv", the kernel boots up without problems:

  Jumping to boot.scr
  ## Executing script at 44000000
  3455880 bytes read in 1076 ms (3.1 MiB/s)
  22691 bytes read in 781 ms (28.3 KiB/s)
  2594398 bytes read in 1035 ms (2.4 MiB/s)
  ** File not found /vmlinuz **
  ** File not found /dtb **
  ** File not found /initrd.gz **
  Kernel image @ 0x46000000 [ 0x000000 - 0x34bb88 ]
  ## Flattened Device Tree blob at 47000000
     Booting using the fdt blob at 0x47000000
     Using Device Tree in place at 47000000, end 470088a2

  Starting kernel ...

  [    0.000000] Booting Linux on physical CPU 0x0
  [...]

So it looks like there is still something going wrong when the
ramdisk and the dtb get relocated.  The only workaround I know of
is setting fdt_high and initrd_high to suppress the relocation.

Ian, can you perhaps shed some light on the issue?

Are there any negative consequences of suppressing the
relocation?  If not, I would propose to set fdt_high and
initrd_high in the boot script until we have a better solution.


While reworking the bootscript I found that probably nobody has
ever used flash-kernel's "generic" method to install a plain,
umodified zImage (in contrast to having flash-kernel build
uImages).  The code path for installing unmodified zImages and
initrds to a location specified by Boot-Kernel-Path and
Boot-Initrd-Path curently consists only of a "TODO" remark :).

Here is a new patch against flash-kernel based on the review
comments to my first version:

diff --git a/bootscript/bootscr.sunxi b/bootscript/bootscr.sunxi
new file mode 100644
index 0000000..3ec7ab7
--- /dev/null
+++ b/bootscript/bootscr.sunxi
@@ -0,0 +1,20 @@
+# boot script for Allwinner SunXi-based devices
+
+# u-boot-sunxi does - in contrast to u-boot on other platforms - not
+# predefine kernel_addr_r, fdt_addr_r and ramdisk_addr_r, therefore we
+# define them locally in the boot script.
+
+setenv kernel_addr_r 0x46000000
+setenv fdt_addr_r 0x47000000
+setenv ramdisk_addr_r 0x48000000
+
+image_locations='/boot/ /'
+
+for pathprefix in ${image_locations}
+do
+  load ${device} ${partition} ${kernel_addr_r} ${pathprefix}vmlinuz
+  load ${device} ${partition} ${fdt_addr_r} ${pathprefix}dtb
+  load ${device} ${partition} ${ramdisk_addr_r} ${pathprefix}initrd.gz
+done
+
+bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}
diff --git a/db/all.db b/db/all.db
index 93fa714..76abc2d 100644
--- a/db/all.db
+++ b/db/all.db
@@ -64,6 +64,16 @@ Boot-Initrd-Path: /boot/initrd.buffalo
 Required-Packages: u-boot-tools
 Bootloader-Sets-Incorrect-Root: yes
 
+Machine: Cubietech Cubietruck
+Kernel-Flavors: armmp
+Boot-Kernel-Path: /boot/vmlinuz
+Boot-Initrd-Path: /boot/initrd.gz
+Boot-Script-Path: /boot/boot.scr
+Boot-DTB-Path: /boot/dtb
+DTB-Id: sun7i-a20-cubietruck.dtb
+U-Boot-Script-Name: bootscr.sunxi
+Bootloader-Sets-Incorrect-Root: no
+
 Machine: D-Link DNS-323
 Kernel-Flavors: orion5x
 Machine-Id: 1542
diff --git a/functions b/functions
index 02f7381..3322eb0 100644
--- a/functions
+++ b/functions
@@ -582,13 +582,17 @@ case "$method" in
 		fi
 		if [ -n "$boot_kernel_path" ]; then
 			boot_kernel_path="$boot_mnt_dir/$boot_kernel_path"
-			# don't mv the original kernel
+			# If we have built a modified version of the kernel
+			# (uImage, machine-id prepended, etc.), then move
+			# this modified version to its destination and make
+			# a backup copy of the previous modified version.
+			# Otherwise just copy the original kernel to its
+			# destination.
 			if [ "$kernel" != "$kfile" ]; then
 				backup_and_install "$kernel" \
 					"$boot_kernel_path"
 			else
-				# TODO add support for kernel symlink
-				:
+				cp -f "$kernel" "$boot_kernel_path"
 			fi
 		elif [ -n "$kmtd" ]; then
 			flash_kernel "$tmpdir/uImage" "$kmtd" ""
@@ -604,13 +608,17 @@ case "$method" in
 		fi
 		if [ -n "$boot_initrd_path" ]; then
 			boot_initrd_path="$boot_mnt_dir/$boot_initrd_path"
-			# don't mv the original initrd
+			# If we have built a modified version of the initrd
+			# (e.g. uInitrd), then move this modified version to
+			# its destination and make a backup copy of the
+			# previous modified version.
+			# Otherwise just copy the original initrd to its
+			# destination.
 			if [ "$initrd" != "$ifile" ]; then
 				backup_and_install "$initrd" \
 					"$boot_initrd_path"
 			else
-				# TODO add support for initrd symlink
-				:
+				cp -f "$initrd" "$boot_initrd_path" 
 			fi
 		elif [ -n "$imtd" ]; then
 			ipad=0

The original TODO remarks speak of symlinking, but this would
only work if the destination of the link is on the same
filesystem as the link itself, as the bootloader could not resolve
a cross-filesystem symlink.  This would in particular fail when
using a Boot-Device entry to mount a seperate firmware boot
partition, so I simply copy the kernel to its target position.

Is this ok to commit?

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.


Reply to: