Re: arm laptops and d-i

[Adam Borowski <kilobyte@angband.pl>]

On Wed, Aug 14, 2013 at 01:07:35AM +0200, Cyril Brulebois wrote:
> Adam Borowski <kilobyte@angband.pl> (2013-08-14):
> > I loathe laptops, and thus didn't own one.  Needing one for DebConf (and
> > this time no friend had a working one for me to borrow), instead of getting
> > an used x86 one, I bought a $150 13.3" android thing.  Because, you know,
> > installing a certain universal operating system should be easy, especially
> > if it's a popular SoC (Allwinner) and graphics chip (Mali 400), right?
> > Oh naive me.

[...]

> Also, thanks for the “why the hell isn't shiny new hardware working out
> of the box” attitude.

"It doesn't work.  This sucks.  It should!" is just the attitude we need,
because it's the first step to actually fixing things.


So, let's gather the results of discussions (plus some recap):

d-i is not popular on arm because most devices get installed a different way:
* N900 and others get flashed over USB
* raspi, hardkernel and others can have their "disk" plucked out and written
  to on another machine
* Omega Oan needs a bootable SD image: d-i, live CD, a recovery image of
  some kind.  You just plop the card in.
* Samsung Chromebook needs substantial effort to even boot from outside
  media, no idea if you can make it use the internal disk.

So I'm not sure how much interest there would be in getting d-i to work.
Perhaps Wookey or someone could tell us about upcoming devices.  It'd be
possible to make the Omega work just the same as on x86, the question is
whether it's worth the effort.  I for one am back, far from having to deal
with blasted laptops which greatly reduces the motivation, I have no skills
related to d-i either.  There are other users to think of, though, and
leaving a device not hacked enough goes against the principles.

So, here are the problems:
1. working kernel
2. booting d-i
3. partitioning the nand
4. making the nand bootable
5. misc device-specific setup

1.:
It looks like Allwinner support in 3.11 kernels is not that good yet, no
idea if it's enough.  If not, linux-sunxi kernels could be used in the
interim, but only for testing -- I don't see per-SoC kernel trees getting
into Debian, for good reasons.

2.:
Old kernels need a separate vfat partition for booting, and "fex" data with
a description of the device in question.  Not nice.  I heard that new uboot
can boot directly from ext4.

3.:
If that new uboot can cope with it, using nand as a yet another block device
in place of /dev/sda might be straightforward.  If not, creating the boot
partition is probably no rocket surgery, but well outside what I know about
d-i.

4.:
Making the final system bootable is another big piece.  Again, I know to
edit what I found on the android disk, but not to configure it for arbitrary
devices, because of fex.  Can new kernels just autodetect stuff?

5.:
Requiring specific steps for particular pieces of hardware (like enabling
a module named "led" here) is nothing new.


So... this is way too much for me to handle personally, so I'm afraid I
can't really volunteer here, other that minor parts, and, of course,
testing.  At least problem areas have been identified, though.  If you need
me, I'll be in the "UTF-8 everywhere" land for now :)

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ