Re: Is an ARM computer a good choice? Which one?

[Gunnar Wolf]

Lionel Élie Mamane dijo [Tue, Mar 21, 2023 at 11:59:08AM +0100]:
> > If you can get a Raspberry Pi 4 - it woill work as a small desktop,
> > more or less silently. To fit extra disks you'll need an add on case
> > - something like the Argon which will take NVME. There are
> > bottlenecks. It's still essentially a phone SOC. It's not *free*
> > because blobs and if you want peripherals, you more or less are tied
> > to running Raspberry Pi OS.
> 
> What ties me into Raspberry Pi OS for peripherals? Non-free drivers
> and/or firmware that cannot get into Debian, or just "it is not
> packaged for Debian because nobody did the work but could be"?

Most of what you need from a Raspberry in terms of using it as "just"
a computer, you will be getting from a standard Debian install.

You will want to look at RaspberryOS if you want to work with specific
"hats", with some electronics-oriented buses, or such. I don't know
the current status of video acceleration, but if I understand
correctly, it is (beginning to be) supported in mainline kernels.

Re: Is an ARM computer a good choice? Which one?

[Gunnar Wolf]

Lionel Élie Mamane dijo [Tue, Mar 21, 2023 at 02:04:55AM +0100]:
> The Raspberrys have to me a reputation of being small cheap "slower"
> hackable mini-computers, not "workhorses". Have they scaled up that
> much since they were introduced?

No.

They scaled up quite a bit; I would not dare do this same experiment
on a RPi0 or 1 (armel)... But still, they are far, far apart from
other ARM systems.

This discussion prompted me to make this into a blog post:


https://gwolf.org/2023/03/impact-of-parallelism-and-processor-architecture-while-building-a-kernel.html?

> Is even the Raspberry Pi 4 even close to 'a beefy but quiet desktop
> that won't shy away from compiling e.g. LibreOffice'? I don't know
> what hardware it runs, but the buildd for arm64 took 17 hours to build
> LibreOffice
> https://buildd.debian.org/status/logs.php?pkg=libreoffice&ver=4%3A7.4.5-2&arch=arm64
> and from https://db.debian.org/machines.cgi
> the hardware seems to be sponsored by Ampere Computing, so maybe it
> uses one of their CPUs?

My main personal laptop nowadays is an ARM machine; you can see that
with "-j 8" I built a Linux kernel in ~25.5 minutes (and ~100 minutes
with no parallelization). The Raspberry achieved ~101 minutes with its
four cores working towards the build. A decently-new and
decently-beefy small server my workplace bought in early 2021 got 21.5
minutes single-core and got down to less than three minutes when
building with its 8 cores, hyperthreading enabled (so "-j 16").

> Also, I'm worried about the memory. My current desktop has as 8.7GB to
> 10GB memory used when running "nothing in particular", no compilation,
> just Exim4 (+ bayesian spam filtering software when an email comes
> in), XFCE, Firefox, Emacs, terminal emulator / shell windows, mutt and
> a few instant messaging clients. And a Raspberry Pi 4 tops at 8GB?

Keep in mind a great part of that memory can be mapped but not active
— mapped libraries and executables, or even data that's sent "down" to
virtual memory. Not all of it hurts. FWIW, my previous machine at home
had 12GB, and I switched for a 8GB system with a newer SSD. It feels
much better.

> Or are you saying I should run that as a silent "terminal" to SSH into
> my real work machine? Which begs the question of what the work machine
> would be :)
> 
> And any idea for a laptop?

There are several decently supported ARM laptops -- however, not
everybody has the same definition of decency.

I'm very happy with the performance of my C630. I bought it
second-hand for US$300 (IIRC it started roughly at twice that price in
2019); I installed with a _modified_ Debian installer¹; it requires
several bits of firmware that it "borrows" from the Windows
installation, and several bits of hardware are not supported (i.e. I
have two sets of kernels, one that's mainline and works "mostly fine"
and IIRC even has audio support, but does not support external video,
and one that carries some patches to enable external video; given I
use this laptop to teach my classes, I almost always use this patched
kernel).

Nowadays, many people report good support with Lenovo's high-range ARM
system, the Thinkpad X13S. I'd jump for mine if I wanted to buy a
>US$1500 laptop (which I don't, of course!)

Good luck switching over to ARM! 😉

¹ https://github.com/aarch64-laptops/debian-cdimage


signature.asc
Description: PGP signature

Re: About ARM

[Gunnar Wolf]

p db dijo [Wed, Feb 08, 2023 at 05:26:18PM +0100]:
> Good evening to all the members of Debian,
> 
> I just want to ask a question:
> 
> Are there computers with ARM cpu's on which can run Debian?
> 
> Awaiting your reply,

I'm currently typing this on my ARM laptop ☺ It's somewhat
higher-specced than the one you mentioned in your other post.

Let me drop a link here for you:

https://github.com/aarch64-laptops/debian-cdimage

This is a *modified* Debian installation image, with the needed bits
to install on a number of ARM64 laptops. The differences with Debian
are quite minimal, mostly oriented at obtaining the firmware needed to
get things going.

My laptop is a Lenovo Yoga C630: this project supports also the Lenovo
Flex 5G, which is quite simlar, a bit newer, and the newer Thinkpad
X13S.

Hope this information is useful to you.

Re: On ARM64 Bit. A Qualcomm Chip.

[Gunnar Wolf]

Hello Dan,

Dan Zulla dijo [Sat, Oct 01, 2022 at 11:35:23AM +0200]:
>Dear Debian Friends,
> 
>I have reached out to a member of the @debian.org community who was
>displayed on the website as a skilled engineer for the Installer, yet he
>advised me to go on the mailing list,  So I am.
> 
>I acquired a rather cheap laptop, a Samsung Galaxy Go with LTE, and that
>was about 300$. It is a nice piece of hardware, and anyone should be able
>to work on ARM64 with that price point and that comfort. I am well aware
>performance of the chip is mediocre, and compiling Debian is going to take
>a while.

FWIW, my main laptop for the last year has been a Lenovo Yoga C630,
which is also an ARM64 system. Let me tell you that I'm more than
happy with it, although I am more than aware it will never be a
fast compiling beast. And mine has an earlier CPU than yours! You will
find it to be quite snappy for non-intensive use.

I hope, though, you got the 5G version, as 8GB RAM is quite a
difference over 4GB RAM.

> (...)
>Are you available to be motivated .. to potentially advise? The Bootloader
>works. As soon as you try to run the installer, textual or graphical,
>crash. Not a commented crash. Just a total nuke of the CPU and reboot. Or
>just uncommented fail to switch into graphical model. (We should work on
>that, if that is the case.)

I cannot provide much help in this regard, but I can point you to a
group of people who most probably will. There is a group for
supporting ARM64 laptops under different Linux distributions at:

https://github.com/aarch64-laptops/

Particularly, they have a slightly modified Debian installer available
at:

https://github.com/aarch64-laptops/debian-cdimage

It is, yes, mostly geared at the Lenovo offerings. But it's a step in
the right position!

You can also join via IRC, at #aarch64-laptops in OFTC
(irc.debian.org).

>Do you have any insight or experience, or idea, about why Grub works?
>Ubuntu image boot displays something about being unable to establish
>graphics output mode, low-level wise. I am a high level programmer getting
>started low-level. I don’t know what that means. The display driver?

Well, I'd venture that Grub works because it is not Linux! It is a
completely independent, much easier system, and works by using UEFI as
its operating-system-of-sorts (which is provided by the
firmware). Linux wants to control hardware much more closely than
Grub.

raspi-firmware: Performance regression under RPi4B

[Gunnar Wolf]

Package: raspi-firmware
Version: 1.20220120+ds-1
Severity: important
Tags: upstream

Hank Barta reported a performance regression under the Raspberry Pi
4B, after comparing Bullseye and Bookworm (Debian 11 and 12). I am
copying over to this bug report only part of the information; a
full(er) report is available in Hank's GitHub project
Pi-4B-bookworm-performance:

https://github.com/HankB/Pi-4B-bookworm-performance

The problem presented when running sysbench:

   /--- bullseye ↓
   | $ time sysbench --test=cpu --cpu-max-prime=2 run
   | (...)
   | CPU speed:
   | events per second:   584.72
   |
   | General statistics:
   | total time:  10.0006s
   | total number of events:  5850
   | Latency (ms):
   |   min:1.70
   |   avg:1.71
   |   max:2.99
   |   95th percentile:1.73
   |   sum: 9997.34
   |
   | Threads fairness:
   | events (avg/stddev):   5850./0.00
   | execution time (avg/stddev):   9.9973/0.00
   +--- bookworm ↓
   | # time sysbench --test=cpu --cpu-max-prime=2 run
   | (...)
   | CPU speed:
   |  events per second:   233.03
   | 
   | General statistics:
   | total time:  10.0038s
   | total number of events:  2333
   | 
   | Latency (ms):
   |  min:4.28
   |  avg:4.29
   |  max:4.34
   |  95th percentile:4.33
   |  sum:10001.67
   | 
   | Threads fairness:
   | events (avg/stddev):   2333./0.00
   | execution time (avg/stddev):   10.0017/0.00
   \---

Hank did a thorough saerch, and found out this issue happens after the
firmware update (raspi-firmware/testing 1.20220120+ds-1 arm64
[upgradable from: 1.20210805+ds-1]).

Further information is available on the debian-arm mailing list
thread:

https://lists.debian.org/debian-arm/2022/03/threads.html#3

I prompted Hank to report this issue to the Raspberrrypi Firmware
project in GitHub, which he did, but was outright dismissed:

https://github.com/raspberrypi/firmware/issues/1705

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.16.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 



signature.asc
Description: PGP signature

Re: Performance degraded, Bookworm on Raspberry Pi 4B

[Gunnar Wolf]

Diederik de Haas dijo [Tue, Mar 15, 2022 at 03:01:59PM +0100]:
> Personally I think it's more useful if Hank reported the issue himself to
> https://github.com/raspberrypi/firmware/ then let Gunnar do it on his behalf.

I agree with you, Diederik. I think Hank has a better grasp of the
problems he is reporting than me, and it would be better if he were
able to send this information to the upstream authors; of course, it
makes sense to link to this thread.

Hank, are you OK with this suggestion?


signature.asc
Description: PGP signature

Re: Performance degraded, Bookworm on Raspberry Pi 4B

[Gunnar Wolf]

Hank Barta dijo [Mon, Mar 14, 2022 at 09:31:36PM -0500]:
> I started installing packages I thought were likely to cause the regression
> (one or two at a time) and following installation of raspi-firmware the
> problem appeared.

As the maintainer of raspi-firmware, I have to say:

Ouch.


raspi-firmware, as you know, is just a blob we cannot debug or do
anything about; it is a core component of our Raspberries, but... it
is non-free ☹

Given you have already pursued the situation to this detail, could you
share... between which versions do you see the regression?

FWIW, I cannot do much about it, other than report it as an issue in
https://github.com/raspberrypi/firmware/issues (which I will do) ;
taking a quick look at the reported issues, and found just the
following, although I don't know if they are in any way related to
your report:

   https://github.com/raspberrypi/firmware/issues/1619

Greetings, and thanks for this report!

Re: odd result for sudo dpkg -V

[Gunnar Wolf]

Gene Heskett dijo [Fri, Nov 05, 2021 at 12:32:44PM -0400]:
> On Friday 05 November 2021 10:22:11 Markus Weyermann wrote:
> 
> > I ran it on RPi4B RaspberryPi  OS aarch64 Buster and got

Please do note that we (Debian) do not control how dpkg works on
RaspberryPi OS -- It is a Debian derivative, but it deviates quite a
bit from us.
> Thats exactly what I got, around 200 of them.  And its quasi-random, I 
> ran it again on my raspian pi4b with a |wc -l and only got 87 next time.

Ugh, that is even worse! :-(

I ran it on a clean Debian, on my Raspberry p400 (using one of the
Bullseye images from https://raspi.debian.net/), and got:

root@rpi-p400:~# dpkg -V
??5?? c /etc/fuse.conf
??5?? c /etc/default/raspi-firmware
root@rpi-p400:~# 

Both are conffiles, and while I don't remember (but don't rule out)
having modified the first one, I'm sure I have touched the second one.

I rebooted the system and ran it again, and got the exact same
results.

> I think the armhf and arm64 versions have a bug. The machine is otherwise 
> fine and could be carveing steel 2 or 3 minutes after I got to it.  
> Takes that long to properly chuck up a workpiece.
> 
> That is not a commonly used option, but I used it because dpkg reported 
> an incomplete quite a few packages update this morning and I was looking 
> for the cause. But a sudo -E synaptic said its all fine, no errors, no 
> fix-brokens etc.

I suggest you bring this issue up on the Raspberry Pi Foundation's
tracker, as it does not seem to be related to Debian.

Re: Debian on Pine64 H64B?

[Gunnar Wolf]

Paul Wise dijo [Tue, Sep 14, 2021 at 04:23:52AM +]:
> On Mon, Sep 13, 2021 at 6:07 PM Gunnar Wolf wrote:
> 
> > Please don't pay me. If you offer a good hosting solution and plan to
> > keep it viable in the long run, I can be persuaded to move
> > raspi.debian.net from my current hosting provider.
> 
> As an interim step, I suggest talking to the debian.net team, who can
> provide VMs on a couple of cloud services, sponsored by Debian Project
> funds.
> 
> https://wiki.debian.org/Teams/DebianNet
> 
> Longer-term you could move to cdimage.debian.org, which has good
> bandwidth and also does torrents.

Yup - For full disclosure of something that has not yet happened, I
recently talked with Steve McIntyre, and in the next few days I'll
start looking into enabling the move to cdimage.debian.org. So, yay! \o/

Re: Debian on Pine64 H64B?

[Gunnar Wolf]

lkcl dijo [Sun, Sep 12, 2021 at 10:21:45PM +]:
> >> But I understand you might have better preferences. Please provide me
> >> the details for a web space you will sponsor and keep for several
> >> years, and I will move raspi.debian.net there.
> 
> Gunnar: can i ask: I take it that you, personally, are not
> comfortable paying for hosting bandwidth, out of your own personal
> funds, if the end-users who are downloading images do not themselves
> offer you any financial compensation or give you donations for doing
> so?

No, nothing like that -- I am paying for bandwidth+disk space for many
of my personal sites, projects, and what amounts to my data dump. I
have enough space and bandwidth to tuck raspi.debian.net along all
that. I believe the service quality to be more than enough; this is
the first time I see aby complaints regarding my service provider.

> do you ever receive any such offers that would aid and assist in
> covering the full cost of the hosting, or for your efforts in
> maintaining the server?

I prefer not to have to think about international money transfers and
the like. I am paying for this service, and will continue to do so
even if raspi.debian.net found a different hosting.

> Gunnar mentioned that you are free to provide an offer of an
> alterative hosting service - AND PAY FOR IT (or find a long-term
> sponsor) as a very polite way of saying, by omission and
> implication:
> 
>  "you get what you pay for... and you haven't paid me anything"

I prefer to leave the "paying" out of the question. I don't want
people to think that they can pay me for my time; my time is not for
sale.

> put plainly: hosting those images costs *real money*, for which
> someone has to pay!

It is marginal cost only, it's using resources that are already paid
and available.

> so please: if you find the service that Gunnar provides at no charge
> to yourself to be inadequate for your needs, *pay him to improve
> it*!!!
> 
> [or, help him to find a sponsor willing to pay for better and
> long-term service, as he suggested]

Please don't pay me. If you offer a good hosting solution and plan to
keep it viable in the long run, I can be persuaded to move
raspi.debian.net from my current hosting provider.

Thanks,

Re: Debian on Pine64 H64B?

[Gunnar Wolf]

Oregano dijo [Sat, Sep 11, 2021 at 11:26:37PM +]:
> >> I have some doubts that debian.net has the same ownership
> >> than official debian.org?
> > 
> > debian.net and debian.org have the same ownership (Debian, via our
> > fiscal sponsor SPI). debian.org subdomains are setup by the Debian
> > sysadmins and mostly run on hardware owned by Debian and systems run
> > by the Debian sysadmins. debian.net subdomains are registered by
> > individual Debian members for experiments, temporary or unofficial
> > services. Gunnar Wolf registered the raspi.debian.net domain for
> > delivering Debian RPi images.
> 
> OK, but nslookup raspi.debian.net and whois 208.97.148.173 shows
> raspi.debian.net is hosted at NightmareHost, which probably explains
> the very long delays in seeing the site sometimes. I respect
> Gunnar's support for raspi's, but the choice of host could be much
> better, IMO.

Actually, I have been a DreamHost client for >20 years, and am quite
happy with them. They provide me more than enough bandwidth and
storage for basically every need I have come across for a very
agreeable price. That's the reason I hosted my images there.

But I understand you might have better preferences. Please provide me
the details for a web space you will sponsor and keep for several
years, and I will move raspi.debian.net there.

Re: Debian on Pine64 H64B?

[Gunnar Wolf]

Gene Heskett dijo [Fri, Sep 10, 2021 at 08:07:56AM -0400]:
> > On Fri, Sep 10, 2021 at 09:50:24AM +0200, LinAdmin wrote:
> > > I have some doubts that debian.net has the same ownership
> > > than official debian.org?
> >
> > RPi images from raspi.debian.net are GPG-signed by Gunnar Wolf's key
> > (who is Debian Developer), that's good enough for me.
> >
> > Reco
> 
> But will they run my lathe? If they cannot do it safely, with IRQ latency 
> response well under 50 microseconds they are of sub-zero interest to me.

They are not designed to suit you. I guess you want to build your own
kernels with the RT_PREEMPT enabled, and that's not something you will
get with any of the mainstream Linux distributions. Also, the
Raspberry is not the right platform for using RT (I'd suggest you look
at the Beaglebone, as its hardware with separate microcontrollers is
better suited at real-time tasks - it has less computing power, but is
better suited for RT tasks -- you will find
https://beagleboard.org/static/presentations/MakerFaireNY20140920_UsingBeagleBoneRealTimeMicrocontrollers.pdf
interesting).

Our images' goal is to provide something as close as possible to a
base, just-installed Debian image, following the RPi culture of having
installed images. You can build from there.

Of course, if you want to do a shipping in the hundreds, thousands or
further numbers of units, you won't want to use the images we generate
-- but you might find the vmdb2 scripts we have as a worthy starting
point for you to customize and build your own images. FWIW, I have a
script set for the ~10 Raspberries we use at work for driving displays
with our activities; I only use our "raw" images for testing them.

Re: Debian on Pine64 H64B?

[Gunnar Wolf]

LinAdmin dijo [Fri, Sep 10, 2021 at 09:51:51AM +0200]:
> The unnamed decision makers of Debian some unknown time ago
> decided that Pi and *Pine* stuff won't be supported by Debian.

Hey, we do have names!

I am one of them. I am willing (and have done so extensively) to put
time into making Debian easy to use in the Raspberry family, but I am
convinced raspi-firmware cannot be part of Debian itself.

That's why I ensured that all of the footers in
https://raspi.debian.net/ mention that «This site is not an official
Debian project. While the maintainer (Gunnar Wolf) is a Debian
Developer, content herein provided should be considered unofficial».

Greetings,


signature.asc
Description: PGP signature

Re: Debian on Pine64 H64B?

[Gunnar Wolf]

Gene Heskett dijo [Sat, Sep 04, 2021 at 09:43:07AM -0400]:
> (...)
> So I found my own solutions. So, debian-arm, please make up your mind, do 
> you support the pi's or do you NOT support the pi's?

Debian has a very clear line set: We do _NOT_ ship non-free software,
no exceptions. Given the Raspberries need a non-free firmware blob for
the GPU to hand over execution to the ARM CPU at bootup... Yes, that
clearly means no official Debian images exist for Raspberry Pi
hardware. So, yes, we made up our mind, and the situation has been the
same since the original RPi was released in 2013.

Some people, me included (but by far, it's not only me) have prepared
prebuilt Debian images¹ that allow booting a standard Debian system
with *only* the raspi-firmware non-free package installed. 

¹ https://raspi.debian.net
² https://tracker.debian.net/raspi-firmware

> When I did try a net install of buster, but had no network after the 
> reboot, I went back to a raspbian seed image and haven't looked back, it 
> Just Works.

Try running one of our tested images³. I strongly suggest you to use
the Bullseye images, as they are newer and more recently tested, and
are our primary target nowadays.

³ https://raspi.debian.net/tested-images/

> > Whatever floats your boat.
> 
> That attitude is Indicating to me that debian-arm still has zero interest 
> in arm. A sad truth IMO.

We have zero interest to get engaged with divisive, aggressive users
that feel entitled to a full support tier when downloading free
software built by a bunch of volunteers. Do you want us to spend more
time fixing the many quirks in the RPi? Consider hiring a couple of us
to do so. No, not me -- I have my time fully booked and am happily
employed. But if you are interested, I can point you to many people
who might be interested.

Re: Unformatted sd card

[Gunnar Wolf]

Paul Wise dijo [Wed, Aug 18, 2021 at 03:27:39AM +]:
> On Tue, Aug 17, 2021 at 11:11 PM pcr wrote:
> 
> > I am trying again to get bullseye to run on my raspberry pi 4.
> 
> The raspi images are probably the easiest option:
> 
> https://raspi.debian.net/tested-images/
> https://raspi.debian.net/

Yup -- I have not yet pushed out a set of tested images after Bullseye
was released, but should be able to do so before the end of the
week. In the meantime, you can either download the "daily image" from
that same site, or download the latest "tested image" and update, and
add the following line to /etc/apt/sources.list:

deb http://deb.debian.org/debian/ bullseye-security main

(or your favorite mirror), as well as (if you want) the matching
deb-src lines for having the source packages handy as well.

Re: WiFi on RPi

[Gunnar Wolf]

Ryutaroh Matsumoto dijo [Thu, Mar 04, 2021 at 08:10:15AM +0900]:
> > | 3: wlan0:  mtu 1500 qdisc noop state DOWN mode 
> > DEFAULT group default qlen 1000
> > | link/ether dc:a6:32:ae:8d:59 brd ff:ff:ff:ff:ff:ff
> > \--
> 
> Just FYI, with kernel version 5.9 and 5.10, I have been unable to
> get WiFi on RPi4B 8GB working with 2.4GHz.
> 5GHz works fine without vc4.ko and fails with vc4.ko.
> 2.4GHz WiFi is usable with Raspbian kernel 64-bit 5.10,
> so I am assuming my hardware is OK.
> Since I do not use 2.4GHz WiFi because it gets interfered by my
> microwave oven, I have not spent much time on investigating the cause...

I use 2.4GHz networking, as I have several devices which cannot use
5GHz. And I cannot confirm what you mention. Screenshot provided with
the same image I used yesterday. If you don't want to open an attached
image (I often avoid to): Kernel 5.10.0-3-arm64, specified my wlan
details in /etc/network/interfaces.d/wlan0, and got a working network.

Greetings,

Re: WiFi on RPi

[Gunnar Wolf]

Gunnar Wolf dijo [Wed, Mar 03, 2021 at 12:48:56PM -0600]:
> For some reason I canot set up to debug right now, the serial console
> gets garbled up (wrong baud rate or so?) when booting with Bullseye,
> but connecting a HDMI monitor, it also works -- screenshot attached
> :-)

Of course, after promising a screenshot, the next logical step is to
forget to attach it ;-) Fixed.

> Oh -- And I have just realized no image builds have happened in the
> last week (since I did some movements to my build server). I'll try to
> fix it and get the builds started  again today (but I'm quite busy,
> so lets hope it's an easy fix!)

The images were all happily built. They were not synced to the server
:-\ Pushing them now.

Re: WiFi on RPi

[Gunnar Wolf]

Ryutaroh Matsumoto dijo [Mon, Mar 01, 2021 at 11:57:47AM +0900]:
> Hi John,
> 
> > Does anyone have wifi running on an RPi400 with Debian 64 Buster or
> > Bullseye?
> 
> I'm using RPi4B 8GB model, which seems similar to RPi400.
> Without "module_blacklist=vc4" in the kernel command line
> (i.e. "cmdline.txt"), WiFi on my RPi4B does not work.

FWIW, I just popped today's daily image for Buster from
raspi.debian.net in my 8GB RPi4, and:

/buster ↓ -
| Debian GNU/Linux 10 rpi4-20210226 ttyS1
| 
| rpi4-20210226 login: root
| Linux rpi4-20210226 5.9.0-0.bpo.5-arm64 #1 SMP Debian 5.9.15-1~bpo10+1
| (2020-12-31) aarch64
| 
| The programs included with the Debian GNU/Linux system are free
| software;
| the exact distribution terms for each program are described in the
| individual files in /usr/share/doc/*/copyright.
| 
| Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
| permitted by applicable law.
| root@rpi4-20210226:~# ip l
| 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
| link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
| 2: eth0:  mtu 1500 qdisc mq state DOWN 
mode DEFAULT group default qlen 1000
| link/ether dc:a6:32:ae:8d:58 brd ff:ff:ff:ff:ff:ff
| 3: wlan0:  mtu 1500 qdisc noop state DOWN mode 
DEFAULT group default qlen 1000
| link/ether dc:a6:32:ae:8d:59 brd ff:ff:ff:ff:ff:ff
\--

For some reason I canot set up to debug right now, the serial console
gets garbled up (wrong baud rate or so?) when booting with Bullseye,
but connecting a HDMI monitor, it also works -- screenshot attached
:-)

Oh -- And I have just realized no image builds have happened in the
last week (since I did some movements to my build server). I'll try to
fix it and get the builds started  again today (but I'm quite busy,
so lets hope it's an easy fix!)

Re: Debian Bullseye on Raspberry Pi 4 4GB?

[Gunnar Wolf]

LinAdmin dijo [Sat, Feb 20, 2021 at 07:30:35PM +0100]:
> I am not convinced that all images listed on [1] do work as
> advertized.
> (...)
> > [1] https://raspi.debian.net/tested-images/


Right. I'm only one person responsible for the builds, and quite
time-starved myself. I did test on real hardware all of the provided
images, and verified basic functionality for everything I'm claiming
there... But help is most welcome to improve!

(and, yes, the great raspi-team has helped quite a bit, but all in
all, the final step of image building and creation is down to my ten
fingers and pair of eyes)

Re: Debian Bullseye on Raspberry Pi 4 4GB?

[Gunnar Wolf]

Rick Thomas dijo [Sat, Feb 20, 2021 at 04:46:00AM -0800]:
> Hmmm...   The "tested images" page [1] lists images for both Buster
> and Bullseye that reportedly boot on the RPi 0W.  I don't know what
> they had to do to make it work.  They're cheap enough that I may
> just buy one and try it, for fun.

They basically "just worked" from the beginning -- using the
linux-image-rpi kernel build and the armel architecture. Yes, they are
slow... but they work quite well if you don't want more than what they
can provide!

Re: Debian Bullseye on Raspberry Pi 4 4GB?

[Gunnar Wolf]

Hi Pete,

Pete Batard dijo [Fri, Feb 19, 2021 at 02:48:41PM +]:
> > > If so, where would I look for instructions for doing so?
> > 
> > https://raspi.debian.net/tested-images/ contains a Bullseye image that is
> > tested on a RPi4 4GB.
> 
> Technically, this is not as much installing Debian, which is what OP asked
> about, but more taking an image that was installed/setup by somebody else,
> and flat-copying that to your media.
> 
> The end result is that you may not have as much flexibility with user setup,
> partitioning and so on, as you would have with using the formal Debian
> installer.

I completely agree here - That's why I¹ have stubbornly refused adding
packages to the base install; the image is shipped with a base system,
adding only the smallest possible handful of packages I could find to
get a working system (ssh, parted, dosfstools, iw, wpasupplicant,
raspi-firmware and firmware-brcm80211). The anti-pattern is the
overloaded Raspbian (specially its first iterations, before they
started shipping the non-GUI version).

¹ I speak in first person as it is me who builds said images. Diedrik,
  who answered to your mail, is also a team member and has helped
  quite a bit with QA and insight.

> And of course, the problem with preinstalled images like these is that
> distro maintainers need to multiply them for every platform they want to
> support, which quickly become unmanageable and leaves any user of any
> platform that hasn't deemed worth supporting stranded...

Right again -- The motivation for Michael Stapelberg first, then for
me to take on his work, is simply the amount of Raspberry systems out
there for which there was no easy way to get Debian running, despite
it being completely capable of doing so.

Re: How to get Realtek RTL8723BS WiFi working with Debian Bullseye on Pine A64+?

[Gunnar Wolf]

Paul Wise dijo [Sat, Feb 13, 2021 at 10:14:34AM +0800]:
> (...)
> > On a related topic, what would it take to make the Pine Debian
> > installs more nicely packaged, like the Raspbian installs? (Thanks,
> > Gunnar!)
> 
> There are too many different SBCs to make individual images for each
> platform a viable strategy. I think the only reason there are RPi
> images is that the hardware is popular and the community around it
> expects available images rather than running an installer on-device.

Thanks for the explicit mention! However, the fact you singled me out
by name gives part of the answer -- And while I completely agree with
what Paul said and would have written the same (and that's the reason
I'm answering to his mail rather than to yours), I think this should
be said explicitly:

The Raspberry images are *not* official Debian images. Yes, they are
as-close-as-it-gets-to-being-so, but they are just a convenience
service run by an individual DD, on his hardware, hosted on his
own. You should *not* trust my images as much as you trust official
Debian projects (I promise not to have trojanized the builds... But
should you trust me? Or my computer?)

Anyway, I think it makes sense to ship built images for major, widely
available hardware. And if the images didn't need non-free firmware to
begin the boot process, I'd probably be pushing for them to become
official Debian builds!


signature.asc
Description: PGP signature

Re: No /dev/video0 on Pi 4 with CSI camera

[Gunnar Wolf]

Hi!

oreg...@disroot.org dijo [Wed, Jan 06, 2021 at 09:09:09AM +]:
> > I'm experimenting with a Raspberry Pi 4 Model B and can't seem to get
> > V4L to expose a /dev/video0 device when using the standard CSI camera
> > module. Raspbian on the same device seems to expose one correctly. I'm
> > using the 20200707_raspi_4 image.
> I was having similar problems with an early Pi 1, Model B+. The following 
> exposed a /dev/video0 device for me. Maybe it works for a Pi4 too.

I was very happy to see this message! Still...

> Installed raspi_0w image.
> Added start_x=1 in /boot/firmware/config.txt
> Installed v4l-utils, v4l2ucp, v4l-conf.
> Installed a bunch of python stuff...
> No joy.
> Upgraded system to debian testing (to get the bcm2835_v4l2 module, from the 
> staging directory).
> Reboot.
> Changed /boot/firmware/config.txt again, because it was overwritten during 
> upgrade to testing: start_x=1 ; Also added gpu_mem=128 but not sure if this 
> is needed.
> Reboot
> Magic! /dev/video0 now exists.
> Haven't captured a picture yet, but this looks promising:
> # v4l2-ctl --info

No luck yet :-( I tried this on a RPi4, and while /dev/vide0 exists,
any attempts to use it ends up with a dead camera grabbing program :-(

Re: Raspi 4 debian image update-initramfs

[Gunnar Wolf]

[ Adding a Cc: to #964915 ]

Lucas Nussbaum dijo [Fri, Jul 31, 2020 at 02:15:29PM +0200]:
> Hi,
> 
> Can you confirm that it's not
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964915

Yes, that's precisely the culprit.

Even more - Both basti and me didn't find it any further because (I
guess) we both booted with the HDMI console. When using a serial
console, I found the all too familiar:

Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.

And of course, after a couple iterations, I got dumped to the very useful 
busybox:

Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
done.
Gave up waiting for root file system device.  Common problems:
 - Boot args (cat /proc/cmdline)
 - Check rootdelay= (did the system wait long enough?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT!  /dev/mmcblk0p2 does not exist.  Dropping to a shell!

BusyBox v1.30.1 (Debian 1:1.30.1-4) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs)

So, Basti:

1. Try editing cmdline.txt in your first partition, replacing
   «/dev/mmcblk0p2» by «LABEL=RASPIROOT» as the bug report suggests

2. If you don't use a serial console, consider removing the
   «console=ttyS1,115200» part, so that the main information is sent
   to the HDMI output. Or even better, swap the order, so that the
   serial console functionality is preserved, but the main console is
   HDMI.

So, we should definitively address item 1, as it is a serious bug (and
I'm bumping up severity - It will affect all Raspberry models, not
just the 4).

As for 2... well, we can document it and maybe add some black magic to
the initrd generation to allow the user to specify what the default
console should be. But as the preferences are completely depending on
the user and there is no "righter" value...

And, following Lucas' report -- I think his last point actually makes
a lot of sense:

1) setting ROOTPART=`findmnt -n --output=source /boot/firmware/`,
2) or using the label and doing ROOTPART=`findmnt -n
   --output=source /boot/firmware/`; ROOTLABEL="`lsblk -no label
   $ROOTPART`", and when overwriting cmdline.txt using
   "root=LABEL=$ROOTLABEL",
3) or my personal favorite - not touching cmdline.txt at all. I
   don't really see the point of modifying it during postinst of a
   kernel package, unless the pre_cmdline stuff needs to modify
   console boot settings for some reason.

So that's surely an issue to look into ASAP! (and yes, the bug is not
getting any younger :-| )

Re: Raspi 4 debian image update-initramfs

[Gunnar Wolf]

basti dijo [Tue, Jul 28, 2020 at 08:58:58PM +0200]:
> Hello, I have try images from  https://raspi.debian.net/ daily build and
> also tested images.
> 
> When I copy it to SD card and boot all work, reboot also.
> When a update-initramfs is done by install new software for example lvm2
> or update the kernel the raspi won't boot anymore and hang after detect usb.
> 
> to reproduse just copy a image to sd card boot and run
> update-initramfs -u -k all && reboot
> 
> Can someone confirm?

G.

Yes, I can confirm, I just checked. It does not make me happy at all
(in part because we have recently had *two* uploads of raspi-firmware
accepted to Stable because of a much related issues).

I can confirm it happens in a RPi4, which has some bits of
"experimentalness" in it. At least it is _not_ happening in my RPi0
(and will now check on the 2, just to be sure) - So most probably the
issue is not present in the raspi-firmware (raspi3-firmware, really)
package present in stable. And it narrows down what I need to look
into.

Thanks for your report!

Re: USB on RPI4 8G (Was: Preliminary image for Raspberry Pi 4)

[Gunnar Wolf]

Lucas Nussbaum dijo [Fri, Jul 24, 2020 at 05:45:33PM +0200]:
> I confirmed it works fine with a kernel built from the Debian kernel
> team's git. For anyone needing a quick fix, a working kernel is
> available at
> https://people.debian.org/~lucas/rpi4/linux-image-5.8.0-rc6-arm64-unsigned_5.8~rc6-1~exp1_arm64.deb

Great news! Looking forward to enable it for our builds.

Re: Re: Preliminary image for Raspberry Pi 4

[Gunnar Wolf]

Hello,

jimmypierre.rouen.fra...@gmail.com dijo [Tue, Jun 30, 2020 at 01:55:25PM +0200]:
> >>https://salsa.debian.org/dilinger/image-specs/-/commits/raspi4
> 
> >>5.7 works pretty well, with a USB keyboard and the wifi tested. Here's a
> pi4 image that I built just now, for folks who don't want to do their own
> build:
> 
> >>https://people.debian.org/~dilinger/rpi4-20200626/
> 
> Just a line to report that the Pi3 B+ image from Gunnar worked well, Pi-Hole
> is working fine as well as Wireguard on old kernel 4.9.
> 
> I am writing because I have received a Pi 4 today, so before I venture with
> the Pi-hole/Wireguard scenario, anything new that I need to know with the Pi
> 4 image above please?
> 
> Thanks Gunnar for your help!

Just leaving this as probably valuable information for other people
that want to try out Andres' images:

- Some people, me included, have checked the image and are happy to
  report it works fine!

- However... There is a _very_ odd problem we will have to look into:
  The image works fine in the 4GB version of the Rpi4. The 8GB version
  does bring up wireless networking, but still does not manage to
  enable USB :-( (we haven't yet seen reports for the 2GB version).

Of course, we expect this to be easily fixable (but currently have no
clue yet as to why it happens).

There are a couple of issues to iron out before I think it's possible
to enable the image to be autogenerated, but we are on the right track!

Re: Latest image for Raspberry Pi 3+

[Gunnar Wolf]

jimmypierre.rouen.fra...@gmail.com dijo [Tue, Jun 16, 2020 at 03:37:06PM +0200]:
> Greetings,
> 
> I have a project of running WireGuard on a Raspberry Pi 3 B+.
> 
> The last image I found is
> https://people.debian.org/~gwolf/raspberrypi3/20190628/20190628_raspberry-pi
> -3_buster_PREVIEW.img.xz

Oops! It's quite an old image. Please refer to my daily-built images
instead, at:

https://raspi.debian.net/

> Please advise if you have a newer image specially with a 5.6 or 5.7 Linux
> Kernel if possible.

It is possible, although I am not building them; I want the images to
be based on the latest Debian stable release (Debian 10, Buster),
which carries Linux 4.19.

Do note, however, that once booted it is quite easy to install a newer
kernel on this image; add backports to your apt repositories and get
linux-image there (5.6).

Greetings,

Re: Pi2 does not boot with debian-10.3.0-armhf-netinst.iso on SDCard

[Gunnar Wolf]

Yves Caniou dijo [Sat, Apr 25, 2020 at 04:55:01PM +0200]:
> Hello Gunnar
> 
> Thank you for your answer.
> I'm wondering: how do you check the image? SDCard burned and PI2 booted,
> or via virt-manager or similar?
> 
> I've tried your image, and I have the exact experience than previously:
> both leds are lighted, nothing on the screen, nothing on minicom, no
> light for the network if :/

Nope, I test on the real hardware. Plus, one of my machines (Pi2) is
slightly broken (bent mmc connector), so it's quite flaky...

That is the main reason I am making two sets of images available --
The daily built ones are _not_ tested on real hardware, and the tested
ones are.

Re: Pi2 does not boot with debian-10.3.0-armhf-netinst.iso on SDCard

[Gunnar Wolf]

Reco dijo [Sun, Apr 26, 2020 at 01:29:13PM +0300]:
> > There is a very minor issue with the 0/1 image (which I intend to fix now).
> 
> There are two, actually:
> 
> 1) /etc/network/interfaces.d/eth0 has a hook to load netfilter rules,
> but the appropriate files are missing:
> 
> pre-up iptables-restore < /etc/iptables/rules.v4
> pre-up ip6tables-restore < /etc/iptables/rules.v6

I have fixed this, current images will not have this issue anymore.

> 2) An attempt to launch agetty on ttyS1 (which should be uart console
> according to /proc/cmdline) fails with:
> 
> agetty[655]: /dev/ttyS1: not a tty

G... I have to fix this one soon! I'm too tired right now,
but... Will fix it soon. Promise.

Re: Raspberry Pi images SSH access

[Gunnar Wolf]

fl4co dijo [Wed, Apr 29, 2020 at 02:43:47PM +0200]:
> Hi all,

¡Hola Flaco!

> I’d like to install one of the images provided on raspi.debian.net
> .

I'm very happy - I'm the person building them :-]

> However, at https://raspi.debian.net/defaults-and-settings/
>  I read that the
> root account doesn’t have a password and limited to local access
> only by default.

> Since I use this Pi headless and don’t have a monitor or a USB
> keyboard available for the first boot, I’d like to know if it’s
> possible to enable the SSH daemon by placing a file called ssh or
> ssh.txt on the /boot FAT32 partition of the SD card, just like in
> Raspbian
> (https://github.com/RPi-Distro/raspberrypi-sys-mods/blob/master/debian/raspberrypi-sys-mods.sshswitch.service
> ).

Read on, on that same page (defaults-and-settings). You can write to
the first partition (call it /dev/mmcblk0p1, /dev/sdb1, or wherever it
appears in your system), in the file "sysconf.txt":

root_pw: Set a password for the root user (by default, it allows
 for a passwordless login)

Now... I cannot *assure* this will work right away for allowing a
remote login. I don't have a live RPi at the moment. But others have
pointed out at the PermitRootLogin setting in /etc/ssh/sshd_config. In
earlier versions, the build _did_ modify that file to set
PermitRootLogin=yes; I am no longer deviating from the Debian
standard. If I'm not mistaken, the default Debian configuration is an
implicit:

PermitRootLogin prohibit-password

If so, you should also edit /etc/ssh/sshd_config in your second
partition and set:

PermitRootLogin yes

Re: Issues with RPI2 image from raspi.debian.net

[Gunnar Wolf]

Lucas Nussbaum dijo [Sun, May 10, 2020 at 10:59:29AM +0200]:
> Hi Gunnar,
> 
> I tried booting the RPI2 image from
> https://raspi.debian.net/daily/raspi_2.img.xz
> 
> Boot fails. It never leaves the colorful screen on HDMI.
> 
> Rebuilding the image myself worked. But even then, the serial console
> does not work (only HDMI worked). The image uses console=ttyS1 in
> cmdline.txt, while the serial port is named ttyAMA0 on this board.

Humh, I think it's due to the previous version of the firmware didn't
set upstream_kernel=1. It has now been accepted in Buster proper, so
it no longer needs the kludge I set when building for RPi0/1.

I just checked on my 2, and it boots correctly. I also updated the web
page.

Thanks!

Re: Pi2 does not boot with debian-10.3.0-armhf-netinst.iso on SDCard

[Gunnar Wolf]

Yves Caniou dijo [Fri, May 01, 2020 at 07:32:58PM +0200]:
> Hi
> 
> The image 20200430 is booting and goes to the prompt.
> Yet a minicom doesn't show anything.
> Network is not up at login, root has to make "dhclient -v eth0" to get
> registered.

I understand it _does_ start the network, will check... At least, I
added a configuration much like eth0 to my RPi3's wlan0, and it does
get an IP. Wait - It does refer some nonexistent files I deprecated as
they are not needed. I will... look into it.

> Would it be possible to have things like console-setup directly
> installed? -- all people don't have a qwerty keyboard.
> And things like bash-completion would be nice.

I prefer to keep it as minimal as possible. Installing those packages
is trivial, and... well, every user will want "just" a package or two
more. So I'll stick to keeping it as minimal as possible.

Re: Pi2 does not boot with debian-10.3.0-armhf-netinst.iso on SDCard

[Gunnar Wolf]

Yves Caniou dijo [Sat, Apr 25, 2020 at 04:55:01PM +0200]:
> Hello Gunnar
> 
> Thank you for your answer.
> I'm wondering: how do you check the image? SDCard burned and PI2 booted,
> or via virt-manager or similar?

Short answer is -- I don't. That's why I want to save and report
a set of GPG-signed known-good images. I just build them with a setup
I know that has worked, and... have to check often.

I have my time currently time-limited due to being quarantined; I have
my Raspberries of different generations, but have not been able to
test as I would like. I did test and boot my RPi2, but have not
checked on its hardware support.

> I've tried your image, and I have the exact experience than previously:
> both leds are lighted, nothing on the screen, nothing on minicom, no
> light for the network if :/

Oh, that's worrying - Either for me (bad images) or for you (bad
hardware) ☹

Greetings,

Re: The state of Arm64 on Raspberry Pi (and its Documentation

[Gunnar Wolf]

Ralph Aichinger dijo [Tue, Mar 31, 2020 at 04:24:44PM +0200]:
> Hello!
> 
> With a little bit of envy I discovered that Ubuntu not only runs
> in a vanilla flavour on the Raspberry Pi, but that there is
> a very straightforward download page and stuff seems reasonably
> documented. In both 32 and 64 bit.
> 
> https://ubuntu.com/download/raspberry-pi
> 
> In comparison to this Debian's Arm64 wiki page lists tons of 
> obsolete Arm64 hardware that is no longer available, but does
> not document the one Arm64 system that is the easiest to buy
> in shops very well, in my opinion.
> 
> https://wiki.debian.org/Arm64Port
> 
> Now I do understand that the binary blobs needed to use the 
> Raspberry Pi are a no-no for some, but from a pragmatic 
> standpoint the Pi is the Arm64 system sold in the highest
> numbers, except for cell phones, probably.
> (...)

Hi,

A couple of days ago, I announced the pure-Debian (+ raspi-firmware
from non-free), preinstalled, daily-built Buster images I have
available here:

https://raspi.debian.net/

We are still not offering images for the RPi4, but am following Lucas'
work, and hope to add them soon.

Greetings,


signature.asc
Description: PGP signature

Re: Pi2 does not boot with debian-10.3.0-armhf-netinst.iso on SDCard

[Gunnar Wolf]

Yves Caniou dijo [Fri, Apr 24, 2020 at 01:37:42AM +0200]:
> Hi,
> 
> I've been trying to install debian using debian-10.3.0-armhf-netinst.iso
> for a Pi2. The image is burned on the SDCard with a dd. The leds of the
> Pi2 show access to the SDCard, but nothing shows up on screen and minicom.
> Same hardware/SDCard/ElectricSupply/method used with Raspbian and Ubuntu
> images are working.
> It seems there is a problem with the image itself.

Hello Yves,

I have made available installed, bootable images for the RPi family
in:

https://raspi.debian.net/

I have not yet commented on it, but the image for the RPi 2 *is*
checked, and works fine. There is a very minor issue with the 0/1
image (which I intend to fix now).

Re: raspberry pi installation with debian installer

[Gunnar Wolf]

basti dijo [Thu, Oct 31, 2019 at 09:58:11PM +0100]:
> Hello Mailinglist,
> Hello Gunnar,

Hi, and thanks for the explicit mention :-]

> I get the debian installer running on my rpi3.
> This post is just to inform about the general possibility and for
> documentation propose on debian wiki.

OK, this is quite exciting news! It's great to see the Raspberries
being closer to a first-tier architecture in Debian. TBH, I believe
for almost all RPi users it will be easier to use the installed images
— But yes, I can perfectly understand many will feel this to be better
and more official.

Given you already did all this legwork... Could you add this
information to the Wiki yourself? It's always better if the person
that did the work and has the hands-on knowledge does it.

> test with arm64 mode on rpi3b+
> 
> you need:
> - sdcard with binary blob vfat partition (I use it from
> https://wiki.debian.org/RaspberryPiImages)
> - usb stick for arm64 installer
> 
> todo:
> - download arm64-netinstall iso
> - copy iso to usb stick (cp debian-10.1.0-arm64-netinst.iso /dev/sdx)
> - copy vmlinuz and initrd.gz from stick to sdcard
> - edit config.txt to boot vmlinuz and initrd.gz
> - insert sdcard and usb stick to raspi and start

Umh, this looks like quite a bit of "legwork". I understand you are
basically proving it is _possible_ to boot into d-i, but this all
should probably be prepared into a first-blob bit of a hybrid image:

https://www.debian.org/releases/stable/arm64/ch04s03.en.html

> - ignore missing firmware, brcmfmac43455-sdio.bin is wlan, can be
> installed later (firmware-brcm80211)

AIUI, you can also drop this file in your USB drive and have it picked
up by the installer.

> toto:
> - not all languages are shown correctly in installer

This seems quite odd...

Thanks a lot!

Re: cubox i4x4 hard drive seen in D-I but not in installed system.

[Gunnar Wolf]

peter green dijo [Tue, Dec 13, 2016 at 10:05:12PM +]:
> On 13/12/16 21:42, peter green wrote:
> >
> >I would guess at this point either a race condition or a power glitch
> >(maybe powering the HDD off one of the USB ports wasn't such a good idea).
> >
> OK, I found that adding  ahci-imx.hotplug=1 to the kernel command line made
> it work.
> 
> Checking the schematic I notice that the USB ports seem to have power
> control, I wonder if they are power-cycled at some point during the boot
> process.

I have a CuBox-i 4 (not 4x4). It's currently in stable use, and have
not fiddled with it for long (and right now, it sits 7000Km away from
me), but if I recall correctly, any USB media needed for the boot
process (i.e. a keyboard) has to be inserted in the lower port. I know
the issue seems completely different from yours, but this might be an
important point to get your issue properly solved.

Re: Bug#834974: Installation Report: Stretch Alpha 7 on Cubox-i4pro

[Gunnar Wolf]

tags 834974 + confirmed
thanks

Martin Michlmayr dijo [Mon, Aug 29, 2016 at 07:49:48PM -0700]:
> The log suggests that flash-kernel was installed successfully, i.e.
> that a u-boot boot script was generated correctly.
> 
> I don't know anything about this device so unfortunately I cannot help
> you.  Maybe Vagrant Cascadian knows something?

I own a Cubox-i4pro as well, and can assert I Rainer's experience is
reproducible: The installer finishes doing its work and reports having
installed the boot loader, but after it attempts to reboot, nothing
happens (the computer just hangs idly).

My Cubox-i was originally installed via a chroot and manual boot
fiddling, as I reported on my blog back in the day¹. In order to check
whether this was a regression, I tried installing Jessie, and also
ended up with a seemingly successful install that didn't boot.

¹ http://gwolf.org/content/cubox-i4pro

I might have botched something while preparing my Jessie install:
Having all the files at the same directory, it is possible I booted it
with the Stretch kernel — and I fear that because my syslog starts
with:

Jan  1 00:00:03 syslogd started: BusyBox v1.22.1
Jan  1 00:00:03 kernel: klogd started: BusyBox v1.22.1 (Debian 1:1.22.0-19)
Jan  1 00:00:03 kernel: [0.00] Booting Linux on physical CPU 0x0
Jan  1 00:00:03 kernel: [0.00] Linux version 4.6.0-1-armmp 
(debian-ker...@lists.debian.org) (gcc version 5.4.0 20160609 (Debian 5.4.0-4) ) 
#1 SMP Debian 4.6.2-2 (2016-06-25)

and of course, the installer started by telling me of a kernel version
conflict :) I cannot dig deeper into this today, but I'll come back to
this topic on Monday. Can somebody confirm whether the Jessie
installer actually works reliably on this machine? (that is, whether
it's always been broken or we have a regression)

Re: Broadcom BCM2709, ARMv8, and missing CPU features

[Gunnar Wolf]

Alan Corey dijo [Thu, Jul 28, 2016 at 12:22:23PM -0400]:
> Huh?  I thought they claimed they were interchangeable.  I had an
> image from my model B days 3 years ago that I booted on my 3B.  And I
> cloned a working current 3B SD card and booted a Zero from it.  There
> isn't a different Debian image for every brand of motherboard and CPU,
> they probe to see what hardware is there.  I wouldn't expect older
> images to contain drivers for newer hardware maybe.
> 
> I guess I wouldn't make too much of the jump to 64 bit just yet.  I
> remember when i386 jumped to 32 bit.  16 bit had a messy segmented
> memory addressing scheme I was glad to get away from.  I can't afford
> more than 32 bits worth of RAM anyway, especially since I've usually
> got about 4 machines running.

I'm far from an absolute expert in this area... But I am fairly
certain of what I say — That is, I have a RPi 1 and 2B, and they
cannot boot from the same images.

Keep in mind it's not different Debian images we are talking about —
"real" Debian cannot be booted on Raspberry hardware. I run a Debian
userland on top of their provided kernel (with the mystery blobs to
control its hardware), started by their mystery bootloader. And yes,
for us people coming from the x86 world, we expect similar devices to
"just work", but in ARM it *is* really a different way of doing things
per each kind of board.

I can suggest you to see the talk delivered by Martin Michlmayr some
weeks ago at DebConf on this topic:


http://ftp.acc.umu.se/pub/debian-meetings/2016/debconf16/Debian_on_ARM_devices_2.webm

Re: Broadcom BCM2709, ARMv8, and missing CPU features

[Gunnar Wolf]

Alan Corey dijo [Wed, Jul 27, 2016 at 01:28:31PM -0400]:
> > 64-bit/ARMv8 on the RPi3 is still in progress.
> 
> Yes, so they claim and I wonder how they're going to deal with the
> fact that some Pis are 32 bit and some 64.  I posted this question
> there but I haven't looked into the links in the response a lot:
> https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=154497&p=1010500#p1010500

It should not be that much of a deal — After all, images for the
different generations of Raspberries are not interchangable — A RPi1
won't boot a RPi2 image, nor viceversa. Of course, the earlier
generations could share all compiled binaries, while now it won't be
the case (when it actually runs 64, that is).

Re: affordable arm boards with plenty of ram.

[Gunnar Wolf]

peter green dijo [Thu, May 19, 2016 at 12:43:29PM +0100]:
> I'm looking for an arm board/box to add to my collection of buildboxes.
> 
> Critera (in roughly descending order of importance):
> 
> Reasonablly affordable (upper limit ~£200)
> As much ram as possible.
> Plenty of CPU power would be nice.
> A good storage interface (in order of preference SATA is better than USB3
> which is better than USB2).
> Support in Debian kernels would be nice.
> arm64 support would be nice.
> 
> Currently looking at the cubox i4x4. Anyone have any other suggestions?

I'm curious nobody else has suggested the Banana Pi M3.

http://www.banana-pi.org/m3.html

It has 2MB RAM only, but 8 ARM cores (A83T, so Cortex-A7), nominally
at 1.8GHz. 8GB on-board eMMC (appears as mmcblk0; the traditional SD
card interface appears as mmcblk1). It has on-board wireless
connectivity as well, and a supposedly 1Gbps Ethernet port.

I have not really used it much save for testing it. It does *not* run
on standard Linux kernels (they provide a 3.4 kernel, with the
now-famous "rootmydevice" debug roothole^Winterface open). Some users
report that submitting it to moderate loads make the thermal
throttling system shut down 4 or 8 CPU cores; probably a dissipator or
fan could help it run stably and reliably.

Greetings,

Re: ODROID-C2

[Gunnar Wolf]

Milan P. Stanic dijo [Fri, May 06, 2016 at 11:11:11PM +0200]:
> I don't know for ODROID but for different ARM machines I usually create
> (on the host) filesystem with debootstrap, compile u-boot and kernel,
> flash u-boot to card, copy created filesystem and kernel/modules to card,
> tweak all that a bit and boot.
> That way I have four different ARM machines/system (TF101, BananaPi,
> Lamobo RP1, Samsung Chromebook) with Debian on them.

This will push a bit towards the off-topic. That's what I do with some
of my boards as well. However, you are still running the
upstream-provided kernel and u-boot. And when there are stupid
settings which break down any notion of security in the provided Linux
kernel, you can get something like what I got with my Banana Pi M3:

http://gwolf.org/node/4069

So... That's way better than not having a clean Debian install, but
it's still far from ideal!

Re: bananaPro | debian jessie doesn't boot; trying to establish a serial connection

[Gunnar Wolf]

Stefan Monnier dijo [Wed, Feb 17, 2016 at 08:34:09AM -0500]:
> AFAIK the actual SoC and board doesn't setup anything on the serial
> console side.  It's setup by the later boot loader (the one loaded from
> Sd card or from nand), i.e. by U-Boot (or maybe by its earlier SPL).
> 
> So, indeed, the same params should work.  If you don't see anything when
> booting your Debian SD card but you do see something when booting
> something else (e.g. Bananian), it means that your board can't find the
> U-Boot that's on your Debian SD card.  I.e. either your card is faulty,
> incorrectly inserted, improperly flashed, or something like that.

OTOH, some SoCs' uboot have different behaviours depending on how they
are configured. As an example, on the CI20, when using their centrally
distributed images based on the 3.0.8 kernel, the console UART pins
are in a compatible position to what you'd expect in the GPIO port of
a Raspberry-like system, but on those starting off from a newer (3.18)
kernel, they are at the dedicated UART header instead:


http://elinux.org/CI20_Headless_Setup#Setting_up_SSH_using_serial_and_WiFi.2Fethernet

Re: Squeeze support

[Gunnar Wolf]

Mikhail Kotelnikov dijo [Sat, Nov 28, 2015 at 09:21:44PM +0500]:
> >> I have Netgear ReadyNAS with OS based on Debian armel arch. When I try
> >> to update it to current version of squeeze all mirrors miss some deb
> >> packages.
> >>
> [[…skip…]]
> >> Also tried us.debian.org and de.debian.org.
> >>
> > Use archive.debian.org
> > 
> > https://lists.debian.org/debian-devel-announce/2015/08/msg9.html
> 
> Thanks a lot!

Just to add some stress to the answers you got: Both are right. Using
archive.debian.org as Peter suggests will enable you to add new
packages easily again — But should *not* be considered secure, as
security support for Wheezy on armel is finished. Do pay attention to
Paul's mail, and try to update to a newer OS release, or take care to
isolate your device from the Internet.


signature.asc
Description: Digital signature