On 2023.05.08 21:02, Lennart Sorensen wrote:
Well devicetree is part of open firmware aka IEEE-1275, from 1994.
ACPI is from 1996.
Interesting; TIL.
I guess I'm probably not the only person who thought DT was something
that was only cooked recently by Linux kernel maintainers, since that's
Well, I guess at this stage, and to help provide some more context about
the DT vs ACPI conundrum, I'm going to stop tiptoeing around the literal
elephant in the room, but not without first adding a preliminary notice
that I wasn't privy to whatever discussions occurred with regards to the
Hi James,
Since we're getting off-topic, and I don't think there's much of this
reply that's going to be relevant to it, I dropped the CC to bug 1035392.
On 2023.05.04 14:16, James Addison wrote:
Yep, and for those situations, that's a point in favour of the third
"System Table Selection"
Hello all and sorry for pinging in late into this conversation.
First of all, as someone who noticed the original issue but never got
around to properly report or investigate it, a big thanks go to the
people here who have been devoting time and effort trying to get to the
bottom of it, and
Hi Paul,
On 2021.09.10 00:10, Paul Wise wrote:
On Thu, Sep 9, 2021 at 9:46 PM Pete Batard wrote:
If you read my posts carefully, you find that the only slight request
that I have made is that Debian (i.e. people on this list whom I expect
to know better) should stop advertising pre-built
On 2021.09.09 23:28, lkcl wrote:
Pete: thank you for pointing out that you've actively contributed, do keep
emphasising that, it will help undo some of the damage.
Talk about implication loaded statement here.
So you are taking as fact that everybody is agreeing with your *opinion*
that I
ptember 9, 2021 4:17:08 PM UTC, Vagrant Cascadian
wrote:
I think I missed that decree... I daresay, this argument has been
running around in circles, based on some false assertions...
and a sense of "entitlement". yes, you, Pete Batard: you carry a strong "entitlement&qu
On 2021.09.09 04:43, Paul Wise wrote:
On Tue, Sep 7, 2021 at 10:00 AM Pete Batard wrote:
Yes, but that is *outside* of the scope of Debian, just like booting
Debian on UEFI x86 based PCs also requires the use of intel or AMD
non-free blobs (for RAM bringup, ME and all the other stuff that CPU
On 2021.09.07 18:36, lkcl wrote:
On September 7, 2021 4:16:27 PM UTC, Pete Batard wrote:
And my point is that, since we are dealing with non free systems, it
makes little difference whether the non-free blobs reside in an EEPROM
or on boot media.
it makes ALL the difference in the world
On 2021.09.07 15:55, Reco wrote:
It's illogical, but still - as long as the device has non-modifiable
firmware it's considered good, proper and "free".
If said firmware can be modified (as in - reflashed in EEPROM), or worse
- the device requires firmware to be uploaded on it at every poweron -
On 2021.09.07 13:31, Reco wrote:
Yet there's a difference. Intel ME or AMD PSP do not require firmware to
be written on a boot media, thus making the boot media redistributable
and (other blobs excluded) - DFSG-compliant.
I disagree.
The reason why the firmware needs to be written on boot
Hi Reco,
On 2021.09.07 10:42, Reco wrote:
Hi.
On Tue, Sep 07, 2021 at 10:29:40AM +0100, Pete Batard wrote:
Hi Gunnar,
On 2021.09.06 18:59, Gunnar Wolf wrote:
Gene Heskett dijo [Sat, Sep 04, 2021 at 09:43:07AM -0400]:
(...)
So I found my own solutions. So, debian-arm, please make up
Hi Gunnar,
On 2021.09.06 18:59, Gunnar Wolf wrote:
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_
Hi Andrew,
On 2021.06.14 12:46, Andrew M.A. Cater wrote:
And by the way, this method of installing Debian from a single media by
leveraging the ESP is something that's also frequently used on x86 UEFI
based PCs, so there's really nothing "custom" about that method, apart from
the fact that you
On 2021.06.14 11:14, Arnd Bergmann wrote:
As far as I can tell (please let me know if this has changed), the only
way to get UEFI boot on Raspberry Pi is to load an EDK2 from
a special partition on a bootable drive (µSD or USB).
Not really.
You can load everything from a standard FAT32 EFI
On 2021.06.13 00:53, Paul Wise wrote:
The Raspberry Pi 4 UEFI firmware has been an official EDK2
implementation for some time...
Hmm, then I don't understand the point of the rpi4-uefi.dev project
then. I guess it only exists because people don't want to compile
edk2-platforms themselves,
On 2021.06.12 23:15, Andrew M.A. Cater wrote:
On Sat, Jun 12, 2021 at 11:04:35PM +0100, Wookey wrote:
On 2021-06-12 11:57 +0100, Pete Batard wrote:
As a matter of fact, starting with RPi3, the Raspberry Pi has been an
official EDK2/UEFI platform for more than 2 years now.
... Debian could
On 2021.06.12 09:29, Paul Wise wrote:
Will this be added to edk2-platforms?
https://github.com/tianocore/edk2-platforms/
It already has:
https://github.com/tianocore/edk2-platforms/tree/master/Platform/RaspberryPi/RPi4
The Raspberry Pi 4 UEFI firmware has been an official EDK2
Hi Luke,
On 2021.02.20 04:16, Luke Kenneth Casson Leighton wrote:
On Friday, February 19, 2021, Pete Batard <mailto:p...@akeo.ie>> wrote:
> Why, when it is absolutely possible to achieve it, as was
demonstrated on a cheap platform like the Pi (that actually comes with
hor
On 2021.02.19 22:10, Diederik de Haas wrote:
So don't shoot down other solutions if you aren't or can't be certain they're
incorrect.
Again, I am not trying to shoot down other solutions.
You are misreading way too much into what I stated, and this is starting
to get a bit annoying.
All I
On 2021.02.19 16:01, Arnd Bergmann wrote:
The main purpose of the Tianocore port to the Raspberry Pi (as I
understand it) is to give developers a chance to hack on Tianocore
without having to buy or risk breaking an expensive server.
No.
It can be used as such, yes. But that is certainly not
On 2021.02.19 15:35, Diederik de Haas wrote:
I find it interesting that you felt the need to critique my suggestion.
I'm afraid you are misreading my point.
I'm trying to bring attention to the fact that maybe it is time to start
considering moving away from providing custom images to
On 2021.02.19 13:37, Diederik de Haas wrote:
On vrijdag 19 februari 2021 00:02:27 CET Rick Thomas wrote:
Is it possible to install Debian Bullseye on a Raspberry Pi 4 (4GB) from a
CD/DVD or USB Flash stick or uSDcard?
If so, where would I look for instructions for doing so?
On 2021.02.18 23:02, Rick Thomas wrote:
Is it possible to install Debian Bullseye on a Raspberry Pi 4 (4GB) from a
CD/DVD or USB Flash stick or uSDcard?
Absolutely!
This can be done using the *vanilla* ARM64 bullseyes ISOs, in a manner
that, once you have prepared your USB media (which too
On 2020.03.31 22:02, Ralph Aichinger wrote:
On Tue, Mar 31, 2020 at 05:08:35PM +0100, Pete Batard wrote:
Not from Debian (AFAIK) but, for the Pi 3, you will find some posts on the
Raspberry Pi forums:
https://www.raspberrypi.org/forums/viewtopic.php?f=50=249449=beb9a5a5fc456deef7c00f1ffc0be1df
Hi Arnd,
On 2020.03.31 19:33, Arnd Bergmann wrote:
There is no need to use ACPI when using the UEFI boot path, that can
just as well work with a normal DT.
But there's also no reason to declare that DT should be the only way to
boot a platform.
There is also no need to use UEFI for
Hi Gene,
On 2020.03.31 17:41, Gene Heskett wrote:
The only thing that's missing, really, is for Debian folks to
integrate the retrofitted Genet network driver, which we submitted 2
months ago, in the vanilla aarch64 installation images...
Tweaks my curiosity. That driver doesn't exist in the
Hi Ralph,
On 2020.03.31 15:24, Ralph Aichinger wrote:
Is there some "official" Debian documentation on how to
install aarch64 Debian on the Pi 3 or 4 in an "official" (i.e.
diverging as little as possible from Debian standards) way?
Not from Debian (AFAIK) but, for the Pi 3, you will find
On 2020.03.02 09:56, Andrei POPESCU wrote:
On Lu, 02 mar 20, 09:49:33, Pete Batard wrote:
Well, the situation for networking on Pi4 might change once the Debian
maintainers add https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950578
which is a kernel patch I submitted a few weeks ago
On 2020.03.01 04:31, Keith Bainbridge wrote:
The last I have seen is that debian hasn't been
given drivers for the Pi4. Any info on when that will change?
Well, the situation for networking on Pi4 might change once the Debian
maintainers add
On 2020.03.01 16:30, Gene Heskett wrote:
Debian 10.3 ARM64 should install and work just fine on the Pi 3,
including full graphical mode. No need for 32-bit.
Yes, I've done it, works fine, with one glaring exception all the 64 bit
fans refuse to recognize.
I think you're assuming a bit too
On 2020.03.01 08:23, Keith Bainbridge wrote:
On 1/3/20 6:22 pm, deloptes wrote:
Keith Bainbridge wrote:
Is there a preferred debian arm that people here use basically trouble
free?
This is for Pi3B
many suggest 32bit for the Pi3 incl. raspbian.
Debian 10.3 ARM64 should install and work
Hi Paul,
On 2020.02.04 03:09, Paul Wise wrote:
Is there a plan to package edk2-platforms for Debian?
Not that I know of.
We already have
an edk2 package, but it only supports x86/ARM virtual machines. It
would be nice to have open UEFI firmware for ARM platforms available
in Debian.
You
Hi,
On 2020.02.03 15:53, Lennart Sorensen wrote:
On Mon, Feb 03, 2020 at 10:41:17AM -0500, Gene Heskett wrote:
Written to a 64GB card with dd, makes zero attempt to boot on rp4b.
Put presently running raspbian buster 10.2 card back in, boots up normal.
Suggestions?
According to
Hi All,
I'm just going to point out that there exists another way to boot into
the UI installer on RPi3, and perform an ARM64 Debian install in a
manner that is very close to what a user would perform on an x86 PC.
This is accomplished through the use of the official UEFI firmware that
now
Hi,
On 2019.09.08 16:39, basti wrote:
can anybody confirm this
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939284 bug?
I can confirm this too, on a Raspberry Pi 3 Model B+, with a fully
updated Debian 10:
root@pi3:~# cat /etc/debian_version
10.1
root@pi3:~# uname -a
Linux pi3
36 matches
Mail list logo
