Re: Debian-Installation on sunxi armhf hardware
Hello Hadmut Danisch.
On Mon, Jan 18, 2016 at 10:46:02PM +0100, Hadmut Danisch wrote:
> Hi,
>
> I tried to use the original debian installer as described on
>
> https://wiki.debian.org/InstallingDebianOn/Allwinner
> https://www.debian.org/releases/stable/armhf/ch05s01.html.en
>
>
> in order to install a genuine debian on a BananaPi (and to get rid of
> homebrewn images).
[...]
Unfortunately I don't think Banana Pi support made it into Jessie.
The devicetree for that board did not get merged upstream until
a later kernel release and I don't think the u-boot version in
Jessie got Banana Pi related patches backported in time either.
You should have much better success with using Stretch (d-i alpha)....
>
>
> Unfortunately, with the Jessie Boot-Images the screen remained
> completely black, no network traffic at all.
>
> With the Boot-Images from stretch, the boot process was visible until it
> jumped in the kernel, and again turned black. Keyboard completely
> ignored. Although the boot process offers to abort the boot process
> „with any key”, it does not respond to the keyboard. Again, no network
> traffic (but then, it tries to boot over the network when pulling out
> the memory card within the boot process so that it can't read it's kernel).
This message is probably from u-boot and I'm guessing you're using
an usb keyboard. Possibly either usb-support is not enabled in the u-boot
build and/or the "usb start" command has not been run to scan the usb bus.
Could ofcourse be something completely different but that's where I'd
start looking.
>
> According to the web pages mentioned above the problem is that linux
> assumes the UART as the console. It takes a UART adapter to connect to
> the console port and to take control of the boot process.
An UART adapter is something you'll need to debug and improve the
situation for people not using one..... Please also note that there
are tradeoffs to consider here. Running "usb start" will add a noticable
delay in your bootup times. Probably worth it since otherwise people in
the situation you described above can run into problems. Anyone who wants
to optimize their bootup can just alter their u-boot environments themselves.
>
> One of the web pages mentioned that a workaround is to replace u-boot
> with a self-compiled recent version.
>
>
> This is quite impracticable. I have to deal with one or two dozens of
> Banana Pis, each contained in a case, and creating an installation
> process suitable for non-experts. Connecting to the UART pins is no option.
You seems to have reason to work on this then... or hire someone to help you. ;)
Debian lives on peoples contributions. If you're not able to contribute
your own time, maybe consider contracting a developer to do it (if patiently
waiting isn't an option for you).
>
> Therefor I'd suggest
>
> * boot code that uses the grapical console (which is obviously
> possible since stretch's boot code displays several things), or
AFAIK recent u-boot have a simple way to get the display controller set
up, but Linux still has no display driver. Work is in progress for other
Allwinner based SoCs (H3[1] and A10[2], the latter should hopefully work as a
base for an A20 display driver which would be relevant for Banana Pi but
please notice that this work does not yet include HDMI support!).
> * boot code that opens a network connection and allows to configure
> over the network.
You should be able to install openssh-server via d-i preseeding so that
you can connect and login on the target over network after installation.
>
> The current boot images seem to be rather unusable / too difficult to
> use for regular users.
There are certainly room for further improvements, as always.
Regards,
Andreas Henriksson
[1]: http://lists.freedesktop.org/archives/dri-devel/2016-January/098004.html
[2]: http://lists.freedesktop.org/archives/dri-devel/2016-January/098709.html
Reply to: