Bug#911133: Debian Installer assumes serial console on arm64

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#911133: Debian Installer assumes serial console on arm64

Steve Capper
Package: debian-installer
Version: 20180610

Hello,
When trying to install Debian Buster on an arm64 system via a vga
console (for example a BMC console or attached GPU with UEFI +
X86EmulatorPkg) the debian-installer process itself appears to launch
on the serial console (so is invisible to the user).

It is possible to simply alt+F2 to another window, open up a new
console then manually invoke debian-installer from there and proceed
with an install. So this bug is not a blocker.

Cheers,
--
Steve

Reply | Threaded
Open this post in threaded view
|

Bug#911133: Graphical installer

Marcin Juszkiewicz-10
What we probably need is expanding fb-modules udeb for arm64 with
several entries:

- radeonfb
- nouveau
- virtio-gpu (for VM guest instances)

This should cover real hardware machines with either AMD Radeon or
NVidia graphic cards and also virtual machines.

UEFI does not even need to have X86EmulatorPkg to get it working. For
Radeon cards (not checked with NVidia) kernel can initialize them
perfectly fine without Option ROM support.

And for VMs it just works with recent EDK2 used.

Reply | Threaded
Open this post in threaded view
|

Bug#911133: Graphical installer

Ben Hutchings-3
On Thu, 2018-10-18 at 19:48 +0200, Marcin Juszkiewicz wrote:
> What we probably need is expanding fb-modules udeb for arm64 with
> several entries:
>
> - radeonfb

We don't build radeonfb for arm64, since it only supports old Radeon
chips (up to about 2004).

For current AMD chips the only native driver is amdgpu; for older chips
it's radeon.  Both of them will need some firmware just to light up the
display.

> - nouveau

This also needs firmware to drive recent chips.  It's possible the
driver can set up the display controller without it though.

> - virtio-gpu (for VM guest instances)
>
> This should cover real hardware machines with either AMD Radeon or
> NVidia graphic cards and also virtual machines.
>
> UEFI does not even need to have X86EmulatorPkg to get it working. For
> Radeon cards (not checked with NVidia) kernel can initialize them
> perfectly fine without Option ROM support.
>
> And for VMs it just works with recent EDK2 used.
I really don't think it makes sense to try to support this case.  It
seems to be that the proportion of ARM64 systems booting with UEFI
*and* using a plug-in graphics card *and* using that card for display
(rather than off-screen rendering or GPGPU) is likely to be vanishingly
small.

Ben.

--
Ben Hutchings
Man invented language to satisfy his deep need to complain.
                                                          - Lily Tomlin



signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#911133: Graphical installer

Marcin Juszkiewicz-10
W dniu 19.10.2018 o 01:03, Ben Hutchings pisze:

> On Thu, 2018-10-18 at 19:48 +0200, Marcin Juszkiewicz wrote:
>> What we probably need is expanding fb-modules udeb for arm64 with
>> several entries:
>>
>> - radeonfb
>
> We don't build radeonfb for arm64, since it only supports old Radeon
> chips (up to about 2004).
>
> For current AMD chips the only native driver is amdgpu; for older chips
> it's radeon.  Both of them will need some firmware just to light up the
> display.

OK. Last time I used Radeon cards few years ago - before amdgpu driver.
HD5450 worked fine in arm64 machine without being initialized by
mainboard firmware - Linux was able to get it running with loading it's
firmware from hard drive.

But yeah - non-free part. Which (according to [1]) can be put on install
media by user.

1. https://wiki.debian.org/Firmware

>> - nouveau
>
> This also needs firmware to drive recent chips.  It's possible the
> driver can set up the display controller without it though.

As above.

>> - virtio-gpu (for VM guest instances)
>>
>> This should cover real hardware machines with either AMD Radeon or
>> NVidia graphic cards and also virtual machines.
>>
>> UEFI does not even need to have X86EmulatorPkg to get it working. For
>> Radeon cards (not checked with NVidia) kernel can initialize them
>> perfectly fine without Option ROM support.
>>
>> And for VMs it just works with recent EDK2 used.

> I really don't think it makes sense to try to support this case.  It
> seems to be that the proportion of ARM64 systems booting with UEFI
> *and* using a plug-in graphics card *and* using that card for display
> (rather than off-screen rendering or GPGPU) is likely to be vanishingly
> small.

Now I know why there is nearly no desktop-class hardware for arm64 - no
one believes that it will have any use. When all what is needed is one
change to kernel packaging.

There are people using Macchiatobin, Synquacer etc boards as their
desktops. I do not expect them to have to use serial cables just to
install operating system.

Reply | Threaded
Open this post in threaded view
|

Bug#911133: Graphical installer

Vagrant Cascadian-4
In reply to this post by Ben Hutchings-3
On 2018-10-18, Ben Hutchings wrote:
> On Thu, 2018-10-18 at 19:48 +0200, Marcin Juszkiewicz wrote:
> For current AMD chips the only native driver is amdgpu; for older chips
> it's radeon.  Both of them will need some firmware just to light up the
> display.
>
>> - nouveau

There is a tegra laptop that uses nouveau, though I think it was armhf,
not arm64 (not sure if this bug is specifically about arm64).

There are at least two arm64 laptops, but as far as I know they both
currently just support simplefb, though I'm not sure what needs to
change in debian-installer to support them; just tried the pinebook
earlier today without much luck getting d-i running on the tty displayed
on the LCD.


live well,
  vagrant

signature.asc (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#911133: Graphical installer

Ben Hutchings-3
On Thu, 2018-10-18 at 23:43 -0700, Vagrant Cascadian wrote:

> On 2018-10-18, Ben Hutchings wrote:
> > On Thu, 2018-10-18 at 19:48 +0200, Marcin Juszkiewicz wrote:
> > For current AMD chips the only native driver is amdgpu; for older chips
> > it's radeon.  Both of them will need some firmware just to light up the
> > display.
> >
> > > - nouveau
>
> There is a tegra laptop that uses nouveau, though I think it was armhf,
> not arm64 (not sure if this bug is specifically about arm64).
On Tegra chips, nouveau seems to be used for rendering only.  The
display controller is driven by tegra-drm, which we already include in
the installer (for both arm64 and armhf).

> There are at least two arm64 laptops, but as far as I know they both
> currently just support simplefb, though I'm not sure what needs to
> change in debian-installer to support them; just tried the pinebook
> earlier today without much luck getting d-i running on the tty displayed
> on the LCD.

Can you check whether u-boot is updating the simple-framebuffer device
tree node?  There should be a
/proc/device-tree/chosen/framebuffer@<address> directory containing
status, width, height, etc.  That would help to isolate the problem to
either u-boot or the kernel.

Ben.

--
Ben Hutchings
If at first you don't succeed, you're doing about average.



signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#911133: Graphical installer

Vagrant Cascadian-4
On 2018-10-19, Ben Hutchings wrote:

> On Thu, 2018-10-18 at 23:43 -0700, Vagrant Cascadian wrote:
>> There are at least two arm64 laptops, but as far as I know they both
>> currently just support simplefb, though I'm not sure what needs to
>> change in debian-installer to support them; just tried the pinebook
>> earlier today without much luck getting d-i running on the tty displayed
>> on the LCD.
>
> Can you check whether u-boot is updating the simple-framebuffer device
> tree node?  There should be a
> /proc/device-tree/chosen/framebuffer@<address> directory containing
> status, width, height, etc.  That would help to isolate the problem to
> either u-boot or the kernel.
Booted using u-boot loading the kernel using extlinux.conf, LCD works
fine:

$ uname -a
Linux pbkb 4.18.0-2-arm64 #1 SMP Debian 4.18.10-2 (2018-10-07) aarch64 GNU/Linux

$ head /proc/device-tree/chosen/framebuffer@be000000/* ; echo
==> /proc/device-tree/chosen/framebuffer@be000000/allwinner,pipeline <==
mixer0-lcd0
==> /proc/device-tree/chosen/framebuffer@be000000/clocks <==
dc4
==> /proc/device-tree/chosen/framebuffer@be000000/compatible <==
allwinner,simple-framebuffersimple-framebuffer
==> /proc/device-tree/chosen/framebuffer@be000000/dvdd12-supply <==

==> /proc/device-tree/chosen/framebuffer@be000000/dvdd25-supply <==

==> /proc/device-tree/chosen/framebuffer@be000000/format <==
x8r8g8b8
==> /proc/device-tree/chosen/framebuffer@be000000/height <==

==> /proc/device-tree/chosen/framebuffer@be000000/name <==
framebuffer
==> /proc/device-tree/chosen/framebuffer@be000000/panel-supply <==

==> /proc/device-tree/chosen/framebuffer@be000000/reg <==
@
==> /proc/device-tree/chosen/framebuffer@be000000/status <==
okay
==> /proc/device-tree/chosen/framebuffer@be000000/stride <==
X
==> /proc/device-tree/chosen/framebuffer@be000000/width <==
V

$ head /proc/device-tree/chosen/framebuffer@be000000/* | sha256sum
e87568d4e7086f45c02e4fe25bdddca9c0808eb519d68100db3cecf82dd260c5  -


Booting the d-i daily kernel, I got the same checksum:

# uname -a
Linux (none) 4.18.0-1-arm64 #1 SMP Debian 4.18.6-1 (2018-09-06) aarch64 GNU/Linux

# head /proc/device-tree/chosen/framebuffer@be000000/* | sha256sum
e87568d4e7086f45c02e4fe25bdddca9c0808eb519d68100db3cecf82dd260c5  -

But, the LCD display worked this time.

A cold boot just now failed, and I'm unable to get a console... I'm
guessing the LCD is intermittant, at least with 4.18.x. The LCD has been
pretty reliable with linux 4.19-rc7 from experimental. So this aspect of
this issue may just go away once d-i uses linux 4.19.

There may also be differences booting with u-boot's EFI support (d-i's
mini.iso) and using u-boot's extlinux.conf support, which is what I've
been mostly testing.

Needs some further exploration.


live well,
  vagrant

signature.asc (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#911133: Graphical installer

Steve McIntyre
Forgot to add the bug in on the mails I just sent. Wookey has been
working through how to do some of this. See:

 * https://lists.debian.org/debian-boot/2019/01/msg00183.html
 * https://lists.debian.org/debian-boot/2019/01/msg00184.html

and my responses there.

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
"I can't ever sleep on planes ... call it irrational if you like, but I'm
 afraid I'll miss my stop" -- Vivek Das Mohapatra

Reply | Threaded
Open this post in threaded view
|

Bug#911133: Debian Installer assumes serial console on arm64

wookey-4
In reply to this post by Steve Capper
Here is a patch to debian-installer to enable it to run D-I on all available consoles.

This is one part of making arm64 machines work 'just like PCs' in the installer.

I have also done some work on getting the graphical installer
working. I have enabled that, but input is not working yet, so 'more
later' on that.

The multiple-console support involves a major revamp of
'reopen-consoles-linux' in rootskel in debian-installer, to get rid of
a load of old cruft, and use /proc/consoles (i.e. the kernel's list)
to choose the set of enabled consoles, running the startup rc scripts
on just one console (to avoid doing things twice), then running
debian-installer itself on all the consoles that are enabled and have
device files.

More details are available in the thread steve linked to on debian-boot.

It seems like there is actually a cleaner way to do this, by getting
init to do the heavy process/session/parallel-tasks lifting (instead
of reopen-consoles and steal-ctty). I have a proof-of-concept patch
for that, but it's not actually working right yet. I'll send that in
when it does if I don't hit any roadblocks.

Wookey
--
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/

debian-installer-multiple-consoles.patch (5K) Download Attachment
signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#911133: Multiple console support in d-i

wookey-4
In reply to this post by Steve Capper
OK. Steve stayed up very late last night checking that this worked OK
on x86 and adding some useful logging (allowing for the fact that it
needs to work before syslog is actually started).

We've checked some more stuff today, including testing the matching
finish-install functionality on full installs, and reverting my fancy
inittab seddery to go back to simply appending which is more reliable
and easier to understand. We are now confident that the 'use init'
version is the superior (cleaner and more reliable) approach.

That's all merged in the attached patches which we reckon are now
ready for general use.

I will do some more testing (to check I've not broken hurd - bsd
doesn't seem to be built at the moment so there is nothing to break),
and of course we are ready to prod it some more if we find this does
actually cause unhelpful behaviour for anyone. I also need to check
the docs which no doubt need a few updates.

I've found a couple of other things whilst poking about in the D-I
entrails. There is plenty of cruft from older ways of doing things,
which of course tends to get ignored if it's not actually breaking
things, largely due to chronic undermanning in D-I land. I'll file
some bugs and patches. None of it is urgent, but worth noting before I
forget.

Wookey
--
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/

rootskel-multiple-consoles-inittab4.patch (10K) Download Attachment
finish-install-multiconsole2.patch (4K) Download Attachment
signature.asc (849 bytes) Download Attachment