Difference between revisions of "Novena/Debian History"

From Studio Kousagi Wiki
Jump to: navigation, search
(Notes: armel)
m (moved Novena/Debian to Novena/Debian History: This page is more for historical interest, since we are now much further along.)
 
(14 intermediate revisions by 3 users not shown)
Line 3: Line 3:
 
Debian would be a great linux distro to port to the Novena because of the large number of derivative distros (Ubuntu, gNewSense, TAILS, etc). The [https://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines DFSG] also set a high bar for "libre-ness".
 
Debian would be a great linux distro to port to the Novena because of the large number of derivative distros (Ubuntu, gNewSense, TAILS, etc). The [https://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines DFSG] also set a high bar for "libre-ness".
  
As of January 2013 this may be pre-mature as there is no finalized application-specific Novena hardware. Nonetheless, it would be nice to get the ball rolling and clear any blockers to having debian run on generic Freescale i.mx6-based devices.
+
As of January 2013 this may be premature as there is no finalized application-specific Novena hardware. Nonetheless, it would be nice to get the ball rolling and clear any blockers to having debian run on generic Freescale i.mx6-based devices.
  
bnewbold will try to hand-hold this process. He will target the wheezy release, which is currently testing but will hopefully be released as stable in the next few months.
+
bnewbold will try to hand-hold this process. He was targetting the Debian 7 'wheezy' release (current stable).
  
 
Device-specific debian support for Novena would be similar to the
 
Device-specific debian support for Novena would be similar to the
Line 31: Line 31:
 
  http://git.kernel.org/?p=linux/kernel/git/arm/arm-soc.git;a=commit;h=759a45185ac0e4dfaf8bbfcb390ec73aca4b7a34
 
  http://git.kernel.org/?p=linux/kernel/git/arm/arm-soc.git;a=commit;h=759a45185ac0e4dfaf8bbfcb390ec73aca4b7a34
  
What does it mean to "run vanilla debian on the Novena hardware"?
+
'''What does it mean to "run vanilla debian on the Novena hardware"?'''
  
 
* All of the software, files, and drivers for the board to boot and run come from .deb packages which are accepted into the debian.org repositories.
 
* All of the software, files, and drivers for the board to boot and run come from .deb packages which are accepted into the debian.org repositories.
Line 39: Line 39:
 
* Being able to upgrade the kernel and bootloader using the apt-get mechanism would be nice and is a long term goal, but probably isn't worth biting off in the first whack at porting.
 
* Being able to upgrade the kernel and bootloader using the apt-get mechanism would be nice and is a long term goal, but probably isn't worth biting off in the first whack at porting.
  
So what needs to be done to "run vanilla debian on the Novena hardware"?
+
'''What needs to be done to "run vanilla debian on the Novena hardware"?'''
  
For basic (headless?) functionality the vanilla/mainline linux 3.7 kernel works fine because of patches already applied for the Sabre Lite i.mx6 development board. A Novena-specific device tree file needs to be applied to the kernel image to boot properly; this step happens at kernel installation/upgrade time (the flash-kernel package in debian?).
+
For basic ("headless") functionality the vanilla/mainline linux 3.7 kernel works fine because of patches already applied for the Sabre Lite i.mx6 development board. A Novena-specific device tree file needs to be applied to the kernel image to boot properly; this step happens at kernel installation/upgrade time (automated by the flash-kernel package in debian).
  
''I need to clarify here what exactly device tree files are, where they live (kernel sources? linux-image package? flash-kernel package? u-boot?), and where Novena-specific ones might need to be upstream-ed to.''
+
A new device tree file is necessary. The compiled binary device tree can either be inserted into the kernel uImage file at kernel install time (as was the method for the DreamPlug) or left as a separate file and loaded to the appropriate memory location by u-boot (the current method used with Novena). The necessary device tree files (novena.dts, imx6q.dtsi) are traditionally added to the linux kernel sources at ./arch/arm/boot/dts, but the combined .dtb file can be compiled separately using the device-tree-compiler tool. The debian linux-image package (eg, for -kirkwood) can contain separate .dtb files for each supported hardware device, which end up at /usr/lib/linux-image-<version>-<flavor>/<flavor>-<device>.dtb.
  
 
Customizations to the u-boot booatloader are more extensive and (at the moment) volatile. The way u-boot is installed (written to an offset on the SD card) is fairly unique and there is no "debian way" to do this at the moment. This operation is a bit risky and maybe should only be done by an image build script and not by an automatic u-boot-tools apt-get command? As of January 2013 the debian version of the u-boot package is also out of date; the Novena customizations are on top of the more recent 2012.10 version.
 
Customizations to the u-boot booatloader are more extensive and (at the moment) volatile. The way u-boot is installed (written to an offset on the SD card) is fairly unique and there is no "debian way" to do this at the moment. This operation is a bit risky and maybe should only be done by an image build script and not by an automatic u-boot-tools apt-get command? As of January 2013 the debian version of the u-boot package is also out of date; the Novena customizations are on top of the more recent 2012.10 version.
Line 49: Line 49:
 
====Kosagi.com====
 
====Kosagi.com====
  
* build a Novena binary SD card image from scratch using debian tools
+
* <strike>build a Novena binary SD card image from scratch using debian tools</strike>
* export device tree file (./arch/arm/boot/dts/imx6q-novena.dts?)
+
* <strike>document image building process</strike> [[Novena/DebianBuildProcess]]
 +
* test merging novena kernel defconfig with debian armhf defconfig to identify any conflicts
 
* stabilize Novena-specific u-boot tweaks
 
* stabilize Novena-specific u-boot tweaks
* write an image building script/process
 
 
* (potentially) extend ``flash-kernel`` package to apply device tree file, allowing apt-get kernel updates
 
* (potentially) extend ``flash-kernel`` package to apply device tree file, allowing apt-get kernel updates
 +
* add/merge kernel support for: SATA, PCIe
 +
* kernel and u-boot build/install instructions that use optional modules and initrd
 +
* test building linux-image .deb package that includes uImage, device tree, and builds initrd
 +
* kernel module to configure PMIC (currently enabled with manual i2cset command; enables USB hub)
 +
 +
'''Later "full featured" laptop support might entail:'''
 +
 +
* libre unaccelerated video output (framebuffer?) OR reverse engineered GPU acceleration drivers OR non-free GPU acceleration drivers
 +
* battery board firmware, kernel support (?), and utilities
 +
* kernel module for audio output codec chip
 +
* debian-installer support for installing from an SD card, USB stick, or other media
 +
* extensions to u-boot or a second-stage bootloader to modify settings at boot time using keyboard and monitor (not serial console)
  
 
====Debian.org====
 
====Debian.org====
Line 59: Line 71:
 
* update u-boot and u-boot-tools packages to 2012.10 or newer
 
* update u-boot and u-boot-tools packages to 2012.10 or newer
 
* merge custom Novena-specific u-boot tweaks
 
* merge custom Novena-specific u-boot tweaks
 +
* enable required config options in the "armmp" armhf kernel flavor
  
 
====Kernel.org====
 
====Kernel.org====
  
* merge device tree (sabre lite one might be acceptable?)
+
* merge device tree (sabre lite one might be acceptable?) (after Kosagi finishes)
 +
* merge fixes for SATA, PCI express (after Kosagi finishes)
  
 
==Toolchain==
 
==Toolchain==
  
There are many ways to set up cross-compiling on an x86 linux host targeting ARM devices like Novena. These directions for a debian host are pretty simple and up to date as of January 2013; note that you will need to add squeeze apt repositories to your host's /etc/apt/sources.list if you run wheezy or sid: [http://romanrm.ru/en/a10/cross-compile-kernel Cross-compiling an Allwinner A10 ARM Linux kernel on Debian AMD64]
+
There are many ways to set up cross-compiling on an x86 linux host targeting ARM devices like Novena. The following directions for a debian host are pretty simple and up to date as of January 2013; note that you will need to add squeeze apt repositories to your host's /etc/apt/sources.list if you run wheezy or sid: [http://romanrm.ru/en/a10/cross-compile-kernel Cross-compiling an Allwinner A10 ARM Linux kernel on Debian AMD64]
 +
 
 +
Eventually, of course, the Novena will be self-hosting and new kernels and packages could be built locally.
 +
 
 +
==Advice==
 +
 
 +
Thanks to Ben Hutchings, Loïc Minier, Clint Adams, and Ian Campbell for advice.
 +
 
 +
Ian Campbell said in email that:
  
Ultimately, of course, the Novena will be self-hosting and new kernels and packages could be built locally.
+
...
 +
But actually in general Debian tries to prefer to work with the u-boot         
 +
which ships with the hardware rather than requiring Debian's particular       
 +
version unless there is something terribly wrong with the factory u-boot       
 +
(i.e. on Dreamplug there was a bug which prevented it booting a modern         
 +
kernel at all)                                                                                                                                               
 +
I'd be very wary of any automatic installation of u-boot. You u-boot is       
 +
on an sdcard so maybe its not that risky, but obviously on some systems       
 +
there is a risk of creating a brick. Best avoid the update if possible         
 +
IMHO.                                                                         
 +
...       
 +
 
 +
Debian u-boot package maintainer (not upstream maintainer) said that he might package a new version of u-boot after wheezy is released as stable (no firm date for this, probably spring/summer 2013), but that anybody could pitch in to get it packaged sooner.
  
 
==Notes==
 
==Notes==
  
There is an 'mx5' flavor of the Debian armhf kernel (eg, [http://packages.debian.org/wheezy/linux-image-mx5 wheezy/linux-image-mx5]). A '-mx6' flavor might be created, or a '-mx' flavor might combine the two.
+
Debian armhf now only has 'multiplatform' kernel flavours, 'armmp' and 'armmp-lpae' that must cover all supported ARMv7 systems.
  
 
The Freescale i.mx6 would use the '''armhf''' architecture. armel binaries will run just fine, even with armhf kernel (confirmed).
 
The Freescale i.mx6 would use the '''armhf''' architecture. armel binaries will run just fine, even with armhf kernel (confirmed).
Line 83: Line 117:
  
 
  hwaddress ether 00:1f:16:33:aa:aa
 
  hwaddress ether 00:1f:16:33:aa:aa
 +
 +
==Status==
 +
* All devices have the same, fake MAC address.  We have 1024 addresses from 00-1F-11-02-15-00 through 01-1F-11-02-18-FF.  We'll need to burn the two-digit ID into the EEPROM and have U-Boot read it out during boot.
 +
* The screen will lock up if it goes into sleep.  This needs to be fixed.
 +
* cpufreq doesn't work anymore.
 +
* No HDMI yet
 +
 +
==Other i.MX6 Devices==
 +
 +
* Boundry Device's [http://boundarydevices.com/products/nitrogen6x-board-imx6-arm-cortex-a9-sbc/ Nitrogen6] and [http://boundarydevices.com/products/sabre-lite-imx6-sbc/ Sabre Lite] development boards: recommended by Freescale and the basis for existing mainline Kernel work
 +
* [http://wandboard.org/ Wandboard]: i.MX6 Solo or Duallite, may eventually be open hardware
 +
* [http://www.w2comp.com/detail.asp?catid=76546&Pdtid=649947 Ampe A10 tablet]: i.MX6 quad. [http://liliputing.com/2012/11/ampe-a10-quad-core-freescale-i-mx6-tablet-review.html review with benchmarks]
 +
* Zealz GK802 Android "TV stick" device: i.MX6 quad

Latest revision as of 06:41, 12 October 2014

Porting

Debian would be a great linux distro to port to the Novena because of the large number of derivative distros (Ubuntu, gNewSense, TAILS, etc). The DFSG also set a high bar for "libre-ness".

As of January 2013 this may be premature as there is no finalized application-specific Novena hardware. Nonetheless, it would be nice to get the ball rolling and clear any blockers to having debian run on generic Freescale i.mx6-based devices.

bnewbold will try to hand-hold this process. He was targetting the Debian 7 'wheezy' release (current stable).

Device-specific debian support for Novena would be similar to the device-specific support for the Marvell Dreamplug device used by the FreedomBox project. Ian Campbell seems to have led upstreaming efforts for that device, here are some of the patches and emails from that process:

Subj: include DTB in linux-image files on armel
http://osdir.com/ml/debian-kernel/2012-04/msg00475.html
Subj: ARM: backporting dreamplug patches for Wheezy
Date: Thu, 01 Mar 2012
From: Ian Campbell <ijc@hellion.org.uk>
https://lists.debian.org/debian-kernel/2012/03/msg00006.html
Subj: flash-kernel: Please add support for Dreamplug / Marvell Kirkwood FDT
Date: April 05th, 2012
From: Ian Campbell
http://us.generation-nt.com/answer/bug-667681-flash-kernel-please-add-support-dreamplug-marvell-kirkwood-fdt-help-207026612.html#r
Mainline linux patches:
ARM: kirkwood: add dreamplug (fdt) support.
http://git.kernel.org/?p=linux/kernel/git/arm/arm-soc.git;a=commit;h=3d468b6d6052293ad3b8538b8277077981c28286
ARM: kirkwood: convert uart0 to devicetree.
http://git.kernel.org/?p=linux/kernel/git/arm/arm-soc.git;a=commit;h=759a45185ac0e4dfaf8bbfcb390ec73aca4b7a34

What does it mean to "run vanilla debian on the Novena hardware"?

  • All of the software, files, and drivers for the board to boot and run come from .deb packages which are accepted into the debian.org repositories.
  • Being able to build a binary image using debian tools would be nice, but not necessary.
  • Being able to upgrade the kernel and bootloader using the apt-get mechanism would be nice and is a long term goal, but probably isn't worth biting off in the first whack at porting.

What needs to be done to "run vanilla debian on the Novena hardware"?

For basic ("headless") functionality the vanilla/mainline linux 3.7 kernel works fine because of patches already applied for the Sabre Lite i.mx6 development board. A Novena-specific device tree file needs to be applied to the kernel image to boot properly; this step happens at kernel installation/upgrade time (automated by the flash-kernel package in debian).

A new device tree file is necessary. The compiled binary device tree can either be inserted into the kernel uImage file at kernel install time (as was the method for the DreamPlug) or left as a separate file and loaded to the appropriate memory location by u-boot (the current method used with Novena). The necessary device tree files (novena.dts, imx6q.dtsi) are traditionally added to the linux kernel sources at ./arch/arm/boot/dts, but the combined .dtb file can be compiled separately using the device-tree-compiler tool. The debian linux-image package (eg, for -kirkwood) can contain separate .dtb files for each supported hardware device, which end up at /usr/lib/linux-image-<version>-<flavor>/<flavor>-<device>.dtb.

Customizations to the u-boot booatloader are more extensive and (at the moment) volatile. The way u-boot is installed (written to an offset on the SD card) is fairly unique and there is no "debian way" to do this at the moment. This operation is a bit risky and maybe should only be done by an image build script and not by an automatic u-boot-tools apt-get command? As of January 2013 the debian version of the u-boot package is also out of date; the Novena customizations are on top of the more recent 2012.10 version.

Kosagi.com

  • build a Novena binary SD card image from scratch using debian tools
  • document image building process Novena/DebianBuildProcess
  • test merging novena kernel defconfig with debian armhf defconfig to identify any conflicts
  • stabilize Novena-specific u-boot tweaks
  • (potentially) extend ``flash-kernel`` package to apply device tree file, allowing apt-get kernel updates
  • add/merge kernel support for: SATA, PCIe
  • kernel and u-boot build/install instructions that use optional modules and initrd
  • test building linux-image .deb package that includes uImage, device tree, and builds initrd
  • kernel module to configure PMIC (currently enabled with manual i2cset command; enables USB hub)

Later "full featured" laptop support might entail:

  • libre unaccelerated video output (framebuffer?) OR reverse engineered GPU acceleration drivers OR non-free GPU acceleration drivers
  • battery board firmware, kernel support (?), and utilities
  • kernel module for audio output codec chip
  • debian-installer support for installing from an SD card, USB stick, or other media
  • extensions to u-boot or a second-stage bootloader to modify settings at boot time using keyboard and monitor (not serial console)

Debian.org

  • update u-boot and u-boot-tools packages to 2012.10 or newer
  • merge custom Novena-specific u-boot tweaks
  • enable required config options in the "armmp" armhf kernel flavor

Kernel.org

  • merge device tree (sabre lite one might be acceptable?) (after Kosagi finishes)
  • merge fixes for SATA, PCI express (after Kosagi finishes)

Toolchain

There are many ways to set up cross-compiling on an x86 linux host targeting ARM devices like Novena. The following directions for a debian host are pretty simple and up to date as of January 2013; note that you will need to add squeeze apt repositories to your host's /etc/apt/sources.list if you run wheezy or sid: Cross-compiling an Allwinner A10 ARM Linux kernel on Debian AMD64

Eventually, of course, the Novena will be self-hosting and new kernels and packages could be built locally.

Advice

Thanks to Ben Hutchings, Loïc Minier, Clint Adams, and Ian Campbell for advice.

Ian Campbell said in email that:

...
But actually in general Debian tries to prefer to work with the u-boot          
which ships with the hardware rather than requiring Debian's particular         
version unless there is something terribly wrong with the factory u-boot        
(i.e. on Dreamplug there was a bug which prevented it booting a modern          
kernel at all)                                                                                                                                                 
I'd be very wary of any automatic installation of u-boot. You u-boot is         
on an sdcard so maybe its not that risky, but obviously on some systems         
there is a risk of creating a brick. Best avoid the update if possible          
IMHO.                                                                           
...        

Debian u-boot package maintainer (not upstream maintainer) said that he might package a new version of u-boot after wheezy is released as stable (no firm date for this, probably spring/summer 2013), but that anybody could pitch in to get it packaged sooner.

Notes

Debian armhf now only has 'multiplatform' kernel flavours, 'armmp' and 'armmp-lpae' that must cover all supported ARMv7 systems.

The Freescale i.mx6 would use the armhf architecture. armel binaries will run just fine, even with armhf kernel (confirmed).

Set serial login on ttymxc1; append to /etc/inittab:

3:23:respawn:/sbin/getty 115200 ttymxc1

Set mac address; insert in /etc/network/interfaces:

hwaddress ether 00:1f:16:33:aa:aa

Status

  • All devices have the same, fake MAC address. We have 1024 addresses from 00-1F-11-02-15-00 through 01-1F-11-02-18-FF. We'll need to burn the two-digit ID into the EEPROM and have U-Boot read it out during boot.
  • The screen will lock up if it goes into sleep. This needs to be fixed.
  • cpufreq doesn't work anymore.
  • No HDMI yet

Other i.MX6 Devices