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

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



On Sat, 2014-04-26 at 23:25 +0200, Karsten Merker wrote:
> Hello,
> 
> I am currently working on better support for sunxi-based ARM systems
> in d-i and flash-kernel.  Thanks to Ian's backport of the sunxi AHCI
> support from kernel 3.15rc1 into the Debian 3.14 kernel package (as
> of linux-image-3.14-trunk-armmp_3.14.1-1~exp2_armhf.deb, currently
> only available as source in git) it is now possible to run d-i on
> Allwinner A10/A20-based systems like the Cubie{board,board2,truck}.
> 
> I have installed Jessie on a Cubietruck today with a local build
> of d-i and the installation works mostly ok. Open points are:
> 
> - A few missing kernel drivers (RTC, USB, MMC)
> 
>   I have filed a wishlist bug (#745972) against the linux package
>   to have the missing drivers enabled in future releases.
> 
> - Missing flash-kernel support for the Cubietruck to make the
>   system bootable.
> 
> - No bootable uImages suitable for sunxi devices are generated
>   by the d-i build scripts.

No uImage is required for sunxi, u-boot can boot the vmlinuz file
directly.

> I have been working on the last two points and would like to ask
> whether there are any objections against committing the following
> patches to the flash-kernel and installer repositories.
> 
> Flash-Kernel:
> =============
> 
> diff --git a/bootscript/bootscr.sunxi b/bootscript/bootscr.sunxi
> new file mode 100644
> index 0000000..8db24e1
> --- /dev/null
> +++ b/bootscript/bootscr.sunxi
> @@ -0,0 +1,6 @@
> +ext4load ${device} ${partition} 0x46000000 /boot/uImage || ext4load ${device} ${partition} 0x46000000 uImage || ext2load ${device} ${partition} 0x46000000 boot/uImage || ext2load ${device} ${partition} 0x46000000 uImage
> +ext4load ${device} ${partition} 0x47000000 /boot/dtb || ext4load ${device} ${partition} 0x47000000 dtb || ext2load ${device} ${partition} 0x47000000 /boot/dtb || ext2load ${device} ${partition} 0x47000000 dtb
> +ext4load ${device} ${partition} 0x48000000 /boot/uInitrd || ext4load ${device} ${partition} 0x48000000 uInitrd || ext2load ${device} ${partition} 0x48000000 /boot/uInitrd || ext2load ${device} ${partition} 0x48000000 uInitrd

I think u-boot has some sh-style control loops you can use? (for x in
fstype1 fstype2; do ...). People keep saying one can just use "fsload"
too, but I've not tried it myself (might need enabling in u-boot-sunxi?
If so please do).

I'm hoping the u-boot-sunxi will eventually use the common distro stuff
which u-boot is working on, which I think standardises the u-boot env.
for this stuff.

> +setenv fdt_high ffffffff
> +setenv initrd_high 0xffffffff

These shouldn't be needed with the latest sunxi u-boot.

> +bootm 0x46000000 0x48000000 0x47000000

These numbers should be kernel_addr_r etc and this should use bootz as
in:
	bootz 0x46000000 0x48000000:${filesize} 0x47000000

$filesize in the initrd size, which should be loaded last so it is
current.

> diff --git a/db/all.db b/db/all.db
> index 93fa714..afcc8fb 100644
> --- a/db/all.db
> +++ b/db/all.db
> @@ -64,6 +64,19 @@ Boot-Initrd-Path: /boot/initrd.buffalo
>  Required-Packages: u-boot-tools
>  Bootloader-Sets-Incorrect-Root: yes
>  
> +Machine: Cubietech Cubietruck
> +Kernel-Flavors: armmp
> +U-Boot-Kernel-Address: 0x40008000
> +U-Boot-Initrd-Address: 0x0

I think you can leave these two lines out.

> +Boot-Kernel-Path: /boot/uImage
> +Boot-Initrd-Path: /boot/uInitrd

Should be vmlinuz and initrd.gz I think.

> +Boot-Script-Path: /boot/boot.scr
> +Boot-DTB-Path: /boot/dtb
> +DTB-Id: sun7i-a20-cubietruck.dtb
> +U-Boot-Script-Name: bootscr.sunxi
> +Required-Packages: u-boot-tools

Not needed if no uImage?

> Installer:
> ==========
> 
> diff --git a/build/config/armhf/netboot.cfg b/build/config/armhf/netboot.cfg
> index e6886ba..10bb9e0 100644
> --- a/build/config/armhf/netboot.cfg
> +++ b/build/config/armhf/netboot.cfg
> [...]
> This generates uImage/uInitrd with a proper load address for booting
> on sunxi-based systems.

No need for any installer changes IMHO.

Ian.


Reply to: