guix-devel
[Top][All Lists]
Advanced

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

Re: Staging branch [substitute availability armhf-linux]


From: Vincent Legoll
Subject: Re: Staging branch [substitute availability armhf-linux]
Date: Fri, 15 Jan 2021 18:15:54 +0100

Hello,

On Fri, Jan 15, 2021 at 10:54 AM Mathieu Othacehe <othacehe@gnu.org> wrote:
> It seems that Caliph Nomble succeeded to build a Pinebook Pro image and
> booted it, without graphics, after a few fixes:
> https://issues.guix.gnu.org/45584.
>
> You may want to try again :).

DONE, it's a bit better, this time initrd, kernel & dtb loaded properly.

But serial output stopped after "Starting kernel ..." which is probably
because of mismatched serial port speed, but I tried to relaunch screen
with 57600, 115200 and still go no output. [complete uboot log attached]

LCD screen stays black which is probably normal.

The image was built like the following:

# ./pre-inst-env guix describe
Git checkout:
  repository: /home/vince/dev/repo/guix
  branch: master
  commit: c03875b0361f114634caeb54935fe37a9b7b05af
# echo "(use-modules (gnu system images pinebook-pro))
pinebook-pro-barebones-os" > /tmp/os.scm
# ./pre-inst-env guix system disk-image -t pinebook-pro-raw /tmp/os.scm
[...]
/gnu/store/5fj3aha8jsyji9mpqzf2krakl08r9zlw-disk-image

Next I'll try the hints from:
https://issues.guix.gnu.org/45584

> >> There is almost no armhf hardware that is suitable
> >> for a build-from-source distro in terms of performance, thermal design
> >> and suitable storage (SD cards will not last for unless you pay a huge
> >> amount for the absolute highest quality). Binary distros like Trisquel
> >> are a much better option for armhf.
> >
> > The cross buildability *should* be kind of a solution for this.
>
> Yes we could always decide to stop supporting native ARMv7 substitutes
> and only focus on the cross-building to provide ready to use image for
> this architecture.

Isn't there a way to reconcile the 2 ? At least theoretically cross- or native-
compilation should give identical output, though I dunno how far that
is from reality (probably not good, or we would be doing just that)

> >> All that is not a reason to not support armhf, but if nobody is using
> >> it, then we should officially deprecate it, and not leave it in this
> >> in-between state.
> >
> > I'm not using it because I can't make it work.
>
> Don't hesitate to report the issues you encountered!

I've done it a few times already, for armhf, arm64, powerpc64, mipsel.

And I'll (re-)try anything if I'm hinted as what to try next.

The main problem from my PoV is the scatteredness of the infos.

Tchuss

-- 
Vincent Legoll

Attachment: pbp-ubootlog.txt
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]