fuse control on raspPi
On Tue, 7 Sep 2021 15:46:22 +0300 Reco wrote: >>IMO that's expected from fuse. But even root couldn't chown. I don't recall this difficulty with raspberryOS before. Do you mean that fuse is not correctable? \ What woukd happen if I removed the 'pi' user account? This is why I started a new thread. All the best Keith Bainbridge keith.bainbridge.3...@gmail.com 0447 667 468
Re: Replacement for raspPi
On Tue, 7 Sep 2021 15:46:22 +0300 Reco wrote: >> Hi. >> >>On Tue, Sep 07, 2021 at 08:32:14PM +1000, Keith Bainbridge wrote: >>> I'm looking for suggestions for a new SBC, please. Ideally something >>> more than 2M RAM. I see that a few a happy with Pine laptops. Does >>> this translate to their SBC? >> >>I'd suggest [1], but I'm unsure about the completeness of hardware >>support of the current Debian stable. >>Or [2], but given the current state of Mesa's panfrost it would be >>rough, and this SBC has its share of issues with built-in USB. >> Thanks for these suggestions. >>But without a specific requirement probably the best way is to direct >>you to the list like [3]. You can probably expect working UART, USB >>and Ethernet from the most of SBCs there. >> Looking through that list is daunting to say the least. But I've found a few candidates, which I'll weed out with the help of Andrew's words of wisdom. >> >>> Background. >>> I've just set up a new SDCard with raspberryOS. Set myself up as a >>> user, and set root passsword. When I sshfs to my laptop, the mount >>> point AND all subdirectories are owned exclusively buy user pi. >> >>IMO that's expected from fuse. I'm changing this to a new thread. >> >> >>> Some will recall the discussion around raspberry adding a MS repo to >>> sources.list last year. >> >>I've "installed" fresh RaspiOS recently and they're still doing it. >> I must check my server only set up. >>Reco >> >>[1] https://www.khadas.com/product-page/edge-v >>[2] https://www.hardkernel.com/shop/odroid-n2-with-4gbyte-ram-2/ >>[3] >>https://linuxgizmos.com/150-open-spec-community-backed-linux-sbcs-under-200/ >> Thanks for you suggestions. I started looking at about mid-night this morning, after a couple of very callenging cryptics. Not completed by a long shot. All the best Keith Bainbridge keith.bainbridge.3...@gmail.com 0447 667 468
Re: Debian on Pine64 H64B?
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. not only is it deeply unethical to support non-free firmware, in the instance where such firmware contained spying backdoors that resulted in a user system being compromised, DEBIAN DEVELOPERS COULD BE HELD LEGALLY LIABLE. No. Not when Debian are *NOT* the ones providing said non-free blobs. Somehow I get the feeling that some people here are misconstruing the Pi 3 and Pi 4 installation process as: "Debian is in charge of providing the non free blobs along with the Debian installation files". This is not the case The process is as follows: 1. The user downloads the UEFI Firmware and non-free blobs (that are use SOLELY for UEFI bringup) FROM A THIRD PARTY that has no direct association with Debian. And let me be 100% clear on that, NOONE here is or has been even remotely asking that Debian should provide these files. NOONE. 2. Separately, the user downloads the vanilla installation ISO from Debian. 3. User extracts all of this content on a single installation media (or separate media if they are of the idea that having both contents reside on the one media somehow taints it) . So you're going to have to explain to me how Debian developers, who had no involvement in the above process, and aren't providing any of the firmware blobs, are supposed to be held liable. If anything, it's the user choosing to place content from two independent project that are governed by two separate licenses, that is liable for the end result of what their own action of mixing the content entails (though, in the boot process we're talking about, I also don't see a liability in having binaries governed by different licenses when the handoff process between executables governed by these licenses is the same as the handoff process between non GPL UEFI and GPL Debian) In other words, your assertion is exactly like saying that, if someone happens to download malware from a third party on a Debian OS, then "DEBIAN DEVELOPERS COULD BE HELD LEGALLY LIABLE". That makes absolutely zero sense. I do understand that you have strong objection to the Pi Foundation blobs, but that's not a reason for magically extrapolating liability of a process that does *NOT* involve Debian providing said blobs. Please bear in mind that we are talking about a process that is very *NOT* talking about a process that involves pre-built images, as the whole goal is to work with vanilla Debian ISOs, and guide the user into what preliminary, non-Debian related steps (since these steps can just as well apply to Windows or FreeBSD) they can take to achieve that. As I tried to explain earlier, these blobs are associated with the UEFI firmware, not with Debian, in the same manner as x86 proprietary blobs are associated with the UEFI firmware and not Debian. And I am certainly not seeing anyone throwing a hissy fit at x86 UEFI requiring said proprietary blobs, or pretending that, because Debian boot relies on them, as part of the pre-Debian UEFI boot, Debian devs can be held legally liable. Therefore, it makes no sense to pretend that it should be any different for the Raspberry Pi, when the principle (UEFI early boot relies on proprietary blobs, that are consumed by UEFI and become completely irrelevant, apart from the fact that some of them may reside in memory, to the rest of the boot process after UEFI handoff) is the same. And yes, it is also possible to use this blobs to boot a Linux kernel directly, but that is *NOT* at all what we are discussing here. if however the Pi Foundation wishes to distribute such unethical firmware to individuals, then they have engaged in a Contract of Sale with those individuals and THEY are legally liable for any damage or harm caused, under various Sale of Goods Acts or equivalent in the respective country. It is your right to refuse to use a system that relies on proprietary blobs. I therefore am going to assume that you are not using any modern x86 PC, because, even if you use CoreBoot, you will find that they are unavoidable. likewise with a PC *that you bought* you did *NOT* buy that PC from a Debian Developer, you bought it from a PC distributor and your Contract of Sale is with THEM. Yup, and in the case of the Raspberry Pi process we are describing here, the firmware blobs and UEFI firmware that you used were not provided by a Debian developer, but obtained from a third party (mostly EDK2 + Raspberry Pi Foundation) and whatever you want to pretend is a contract of sale is also with THEM, not Debian. That these blobs and UEFI firmware are being provided on SD or USB media rather than an EEPROM does not change this picture. if you want a Debian Deve
Re: Debian on Pine64 H64B?
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. not only is it deeply unethical to support non-free firmware, in the instance where such firmware contained spying backdoors that resulted in a user system being compromised, DEBIAN DEVELOPERS COULD BE HELD LEGALLY LIABLE. if however the Pi Foundation wishes to distribute such unethical firmware to individuals, then they have engaged in a Contract of Sale with those individuals and THEY are legally liable for any damage or harm caused, under various Sale of Goods Acts or equivalent in the respective country. likewise with a PC *that you bought* you did *NOT* buy that PC from a Debian Developer, you bought it from a PC distributor and your Contract of Sale is with THEM. if you want a Debian Developer to enter into a Contract to provide you with a preinstalled nonfree firmware blob you should pay them adequate amounts of money so that they can take out the requisite Liability and Indemnity Insurance. if you are not prepared to do that please do not complain because your life is made more "inconvenient". >The goal of the Pi Foundation has always been to provide the cheapest >platform they could, and eliminating the need of an Flash EEPROM for >platform bringup is one effective way to do that. indeed. thus, that places the product firmly in EXACTLY the same category as a non-free WIFI product that requires non-free firmware. by forcing YOU to download that nonfree firmware, YOU take responsibility for that action. WHEN the Pi Foundation realise the seriousness of their laziness and provide an on-board EEPROM or SPI NOR Flash IC just like every x86 PC has done since the late 1980s THEN it will be possible for debian to support their products because Debian Developers will not find themselves in the situation of being legally liable for distribution of potentially dangerous firmware. >Again, that does not mean that I approve or am happy with that >decision, >but I don't think there's much to disagree about what the intention of >the Pi Foundation has been, and why they happily went with an SoC that >allowed users to provide all the firmware blobs needed for early boot >on >their own boot media. yes. this has been pissing people off for some considerable time. Broadcom licensed the ARC Core firmware before ARC was bought by Synopsis and their License Agreement clearly prevents and prohibits them from providing the source code to third parties (you, me, Pi Foundation). the sale of ARC to Synopsis makes that even more challenging. it also places them needlessly under NDA and also likely prevents and prohibits them from engaging in reverse-engineering, or be seen supporting ANY efforts which violate their Contract with Synopsis. given that Broadcom's ACTUAL market for these SoCs is 100+ MILLION unit Set Top Boxes and TVs, the Pi Foundation Market is utterly trivial by comparison and, commercially, Broadcom really don't give a flying f*** about it. they care about their relationship with ARC (Synopsis) and do not want to do ANYTHING that could jeapordise their multi-billion-dollar sales. people forget: the *only reason* that the Pi exists at all is because Eben Upton was an employee doing the design in his spare time, with inside access to NDA'd documents. when his Managers discovered what he was doing and that it was for "Education" they couldn't exactly tell him to stop. the Pi Processors due to being manufactured in such absolutely insane quantities are at least FOUR times lower cost than equivalents from Freescale, FIVE OR MORE times cheaper than Texas Instruments equivalents, and even beat the s*** out of Allwinner pricing, which is quite an achievement. it makes *using* it very attractive, but unfortunately, that low "price" burdens everyone else with a "cost" - a real and actual financial burden - that Broadcom is in no way compensating anyone for (and would jeapordise their business if they did) the situation is one where Broadcom is effectively spongeing off of Free Software developers, YET AGAIN burdening the entire Free Software Community with the cost of cleaning up their mess caused by sheer pathological Corporate laziness and profiteering, and i'm getting pretty fed up with it. i am ESPECIALLY getting fed up of people not fully and properly understanding the realities of the situation and complaining that they can't get nonfree firmware preinstalled with products, for their own convenience. please therefore have a little more understanding and appreciation for what Debian Developers are doing, and why they are doing it, and the difficult (spongeing) circumstances and obligations they are under. l.
Re: Debian on Pine64 H64B?
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 - one has to distinguish between free and non-free firwmare. Okay, then we're on the same page that there's no fundamental difference between modern x86 PC and Raspberry Pi, as PCs have reflashable EEPROM. My point of contention here is that there's no reason to treat RPi and x86 PCs differently, because, since both these platforms use proprietary blobs for boot (at least for any PC produced in the next 10 years), they both must be considered non-free. 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. But the system was designed to be as cheap as possible, and therefore, to spare the cost of flash, with the result of requiring uses to provide firmware from the boot media. I have to disagree here. Not sure what you're disagreeing with. It's pretty obvious that one thing the Raspberry Pi Foundation has been doing to cut cost was to use a boot method that does not require the adding of a flash chip to the board (which is further evidenced by newer revisions of the Pi 4 having done away with the flash that was previously used for the xHCI firmware when they figured out a way to load it from the boot media as well). The goal of the Pi Foundation has always been to provide the cheapest platform they could, and eliminating the need of an Flash EEPROM for platform bringup is one effective way to do that. Again, that does not mean that I approve or am happy with that decision, but I don't think there's much to disagree about what the intention of the Pi Foundation has been, and why they happily went with an SoC that allowed users to provide all the firmware blobs needed for early boot on their own boot media. If there's one thing that RPi design shows us, it's how to make a profit on a bad-selling SOC initially intended for media players. I mean, the primary CPU is initalized by GPU. The "main" OS is actually a second-class citizen running in a confined environment, making RPIs unsuitable for any serious kind of realtime. The lack of proper RTC (I know there's separate addons for that). Network and I/O added as an afterthought, attached via USB (RPi 4 not included). Overheating problems. I don't disagree with that. I've had to deal with the Broadcom quirks and bugs (including a major screwup with DMA access above 3 GB for the SoC used on the Pi 4), and I too would much rather have preferred the Pi Foundation to go with something where corners had clearly not been cut. But I don't think it's really relevant to this discussion, outside of justifying why we don't happen to be dealing with non-free blobs that are semi-hidden in an EEPROM, as we do for other systems. If you're looking for a cheap as possible SBC, I suggest you to look at NanoPIs. I'm not looking for anything. I'm a happy user of NanoPC-T4 (running armbian), which I think does a much better job than a Pi 4. But I'm also realist in that the Pi 4 has enough momentum to make it a very attractive platform for many, regardless of its obvious flaws, and therefore, that we need to make sure that users are in a position to install OSes like Debian without penalizing them more for using non-free blobs than x86 PC users are being penalized for having non-free blobs in their platform's firmware. As long as the booting process does not require the OS to deal with non-free blobs directly, i.e. - not having those at filesystem or first megabytes of media does not have any impact on the boot process - yep, I kind of feel like you are making rules here. The only part I can agree with is the "as long as the booting process does not require the OS to deal with non-free blobs directly", which, IMO, the UEFI installation processes for Debian that I linked to do qualify for. These processes are specifically designed so that Debian does not even have to know whether these non-free blobs exist, since they are only being used for TF-A/UEFI bringup. And as a matter of fact, we could actually delete them from the media altogether, from within UEFI, before UEFI hand-off, and it'd create no issue whatsoever (outside of inconveniencing users by forcing them to copy these files again for the next boot). Of course they would still be present in memory, but since your concern appears to be with what resides on the media... So, as I said, these blobs are orthogonal to the Debian boot process and should be considered as if they were internal to UEFI, in the same manner as Intel ME or RAM set-up blobs of Intel UEFI PC platforms are considered to be internal to x86 UEFI firmware. But this hypothetical addon looks
Re: Replacement for raspPi
On Tue, Sep 07, 2021 at 08:32:14PM +1000, Keith Bainbridge wrote: > G'day > > I've been following the recent thread Subject: Re: Debian on Pine64 > H64B? > > I'm looking for suggestions for a new SBC, please. Ideally something > more than 2M RAM. I see that a few a happy with Pine laptops. Does this > translate to their SBC? > > Thanks > > Background. > I've just set up a new SDCard with raspberryOS. Set myself up as a > user, and set root passsword. When I sshfs to my laptop, the mount > point AND all subdirectories are owned exclusively buy user pi. Not > even root has access. So I'm out of raspberry as quick as possible. > I'm in the process of writing debian to a SDcard in the hope that that > will let me get on. > Some will recall the discussion around raspberry adding a MS repo to > sources.list last year. > You'll have seen the pointer to 100+ SBCs. The problem with many of them is that they are cut down to a price point rather than being built to a quality standard. "Raspberry Pi-alike" GPIO pins don't transfer to automagically being able to run an add on in the same way you would on a Raspberry Pi, for example, and some manufacturers appear to produce a large range of almost identical looking boards where you can't rely on them _actually being identical. I'd single out Odroid as being very highly priced by comparison but also very well built: the problem is that the boards take a while to be fully supported on non-vendor kernel and in vanilla Debian - and by that stage, the board may be out of production. Pine's RockPi with 4G of memory seems to work quite well and be relatively well supported. Factor in cases, eMMC and so on as well, if you want them. A lot of the boards do not hve a custom made case and some of them will be non-standard shapes/sizes. All the very best, as ever, Andy Cater > > > > > All the best > > Keith Bainbridge > keith.bainbridge.3...@gmail.com >
Re: Debian on Pine64 H64B?
On Tue, Sep 07, 2021 at 03:02:20PM +0100, Pete Batard wrote: > 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 media is > because the system was designed *NOT* to have its boot firmware on SPI > flash. > > So that's a pure design issue. 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 - one has to distinguish between free and non-free firwmare. I did not make those rules, RMS made them before my time. > For instance, if the PI 4 SPI was large enough to accommodate the 3 MB > we need, we would happily run UEFI (and the proprietary blobs) from > there, instead of boot media. I agree, but sadly it does not change anything in the grand scheme of things. SPI flash can be modified by user, modification requires non-free blobs. > But the system was designed to be as cheap as possible, and therefore, > to spare the cost of flash, with the result of requiring uses to > provide firmware from the boot media. I have to disagree here. If there's one thing that RPi design shows us, it's how to make a profit on a bad-selling SOC initially intended for media players. I mean, the primary CPU is initalized by GPU. The "main" OS is actually a second-class citizen running in a confined environment, making RPIs unsuitable for any serious kind of realtime. The lack of proper RTC (I know there's separate addons for that). Network and I/O added as an afterthought, attached via USB (RPi 4 not included). Overheating problems. If you're looking for a cheap as possible SBC, I suggest you to look at NanoPIs. > If you want to be pedantic about what constitute free vs non-free > according to whether the manufacturer of the system took provisions > for firmware blobs to reside on SPI flash or on a different media, be > my guest. But, in my view, there is no difference there, as it's just > a matter of someone deciding from where the firmware files should be > booted. Again, I did not make those rules. > Heck, if you want to go that way, what do you make of a Pi system > where the firmware blobs reside on a small SD card, that acts as an > SPI flash equivalent, and the system is installed on a different media > (e.g USB, which is what would typically be used, especially on the Pi > 4, as it is *much* faster that SD anyway)? Does that not qualify as a > DSFG compliant? Because that's already completely possible for the > Raspberry Pi if you want to go that route. As long as the booting process does not require the OS to deal with non-free blobs directly, i.e. - not having those at filesystem or first megabytes of media does not have any impact on the boot process - yep, that makes OS image one step closer to DFSG. But this hypothetical addon looks user-modifiable to me, so ... see above. > > In the case of the Raspberry Pi 3 (unsure about RPi 4) it's required to > > have non-free Broadcom blobs in the first partition of SD card. > > And nobody forces you to use the SD card where the non-free blobs > reside to also be your Debian boot media, so you can consider it the > same as you would consider as SPI flash on a PC, i.e. orthogonal to > Debian and its installation process. I'm merely a Debian user, not DM or DD. I do not speak for Debian Project, and my apologies if my writing convinced you differently. I agree that using a separate media would be a viable workaround in this case, but I'm sure there are others who will say their word in the case I'm wrong. Reco
Re: Debian on Pine64 H64B?
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 media is because the system was designed *NOT* to have its boot firmware on SPI flash. So that's a pure design issue. For instance, if the PI 4 SPI was large enough to accommodate the 3 MB we need, we would happily run UEFI (and the proprietary blobs) from there, instead of boot media. But the system was designed to be as cheap as possible, and therefore, to spare the cost of flash, with the result of requiring uses to provide firmware from the boot media. If you want to be pedantic about what constitute free vs non-free according to whether the manufacturer of the system took provisions for firmware blobs to reside on SPI flash or on a different media, be my guest. But, in my view, there is no difference there, as it's just a matter of someone deciding from where the firmware files should be booted. Heck, if you want to go that way, what do you make of a Pi system where the firmware blobs reside on a small SD card, that acts as an SPI flash equivalent, and the system is installed on a different media (e.g USB, which is what would typically be used, especially on the Pi 4, as it is *much* faster that SD anyway)? Does that not qualify as a DSFG compliant? Because that's already completely possible for the Raspberry Pi if you want to go that route. In the case of the Raspberry Pi 3 (unsure about RPi 4) it's required to have non-free Broadcom blobs in the first partition of SD card. And nobody forces you to use the SD card where the non-free blobs reside to also be your Debian boot media, so you can consider it the same as you would consider as SPI flash on a PC, i.e. orthogonal to Debian and its installation process. The resulting media for Raspberry Pi 3 is non-DFSG compliant Again, I'd like to hear where you draw the line for a system where the user set up an SD card with the firmware and is installing Debian on USB. because each and every file on a media that's used to boot is within the scope of Debian. Not sure how you reach that conclusion, with which I completely disagree. Or it cannot be provided by Debian officially. Where is the part where Debian has to provide non-free blobs here? There's two parts to this: 1. The Pi boot process, just like *any other modern boot process* requires the use of non free blobs *before* the execution of the Debian bootloaders and kernel. 2. The design of the Raspberry Pi *currently* requires that these non-free blobs are provided on the boot media instead of some SPI flash, as commonly found on other systems. Considering that, even if we want to go that way, there is nothing in the above that mandates that Debian and non-free blobs should reside on the same media, if that's what you have an objection with, and one again, since it's very much possible to split the pre Debian boot process and Debian boot into completely separate media if you want to be that much of a purist, I see nothing that prevents Debian from providing an official installation media... which they actually already do in the form of the vanilla ISO anyway. I did not meant that. But I can compare Raspberry Pi to, say, kirkwood subarch (QNAP TS series), where all you need to boot is a free software without exceptions, starting with the bootloader. Yes, there we can be pedant as to what system is more free than some other because users (rather than manufacturers, through an SPI flash) have to be the ones dealing with non-free blobs. I'm all for free software (heck, if I have the choice, you're not going to see me touch non-free even with a 10 feet pole), but when the constraints of where the non-free blobs have to reside is imposed by the design of the system, and, from a bird's eye view, it doesn't technically matter whether these blobs are provided from SPI flash or from the user on their boot media, since they exist regardless, I fully disagree with the idea that because the user have to dispense the non-free blobs manually on one system, whereas this is done automatically on another, the Debian situation with the Pi when booting in UEFI mode is any different than the situation with x86 PC when booting in UEFI mode, especially as, again, if you want to be a purist, you can dedicate an SD card to the UEFI firmware, just as you would have a dedicated flash UEFI on PC, and never ever have to touch proprietary blobs in your Debian installation media. Or to put it more succinctly, don't mistaken convenience, through a logical *request* that users manually place mandatory non-free blobs on the same media as the one they will use for Debian installation, so as they don't have to add a separate media to the mix, for absolute require
Re: Replacement for raspPi
Hi. On Tue, Sep 07, 2021 at 08:32:14PM +1000, Keith Bainbridge wrote: > I'm looking for suggestions for a new SBC, please. Ideally something > more than 2M RAM. I see that a few a happy with Pine laptops. Does this > translate to their SBC? I'd suggest [1], but I'm unsure about the completeness of hardware support of the current Debian stable. Or [2], but given the current state of Mesa's panfrost it would be rough, and this SBC has its share of issues with built-in USB. But without a specific requirement probably the best way is to direct you to the list like [3]. You can probably expect working UART, USB and Ethernet from the most of SBCs there. > Background. > I've just set up a new SDCard with raspberryOS. Set myself up as a > user, and set root passsword. When I sshfs to my laptop, the mount > point AND all subdirectories are owned exclusively buy user pi. IMO that's expected from fuse. > Some will recall the discussion around raspberry adding a MS repo to > sources.list last year. I've "installed" fresh RaspiOS recently and they're still doing it. Reco [1] https://www.khadas.com/product-page/edge-v [2] https://www.hardkernel.com/shop/odroid-n2-with-4gbyte-ram-2/ [3] https://linuxgizmos.com/150-open-spec-community-backed-linux-sbcs-under-200/
Re: Debian on Pine64 H64B?
On Tue, Sep 07, 2021 at 11:00:29AM +0100, Pete Batard wrote: > 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 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. > > > > > > I'd say that's not really true, since it's very much possible to > > > install Bullseye on the Pi 4 using *vanilla* unmodified ARM64 Debian > > > ISOs [1]. And the same has been true for Buster on the Pi 3 for some > > > time too [2]. > > > > A small nitpick. While it's indeed possible to boot rebuilt UEFI on > > Raspberry Pi3 (which is free software, since it's patched TianoCore), > > and boot unmodified Debian ARM64 via said UEFI - the booting of UEFI > > itself still requires Broadcom blobs, which are non-free software. > > 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 > manufacturers have decided they no longer want to open) that are > integrated into the UEFI firmware and that you don't see or have to > provide yourself, but that are very much present still. 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. In the case of the Raspberry Pi 3 (unsure about RPi 4) it's required to have non-free Broadcom blobs in the first partition of SD card. The resulting media for Raspberry Pi 3 is non-DFSG compliant, because each and every file on a media that's used to boot is within the scope of Debian. Or it cannot be provided by Debian officially. I'm not writing that to imply that x86 or RPi is somehow more or less "free" compared to each other. Compared to other ARM boards I've dealt with, both x86 and RPis are equally non-free ;) And of course, the porting of UEFI on RPi 3 (have not tried this on RPi 4) is an important achievement by itself, because while UEFI is an overcomplicated and overengineered beast, it's still the best effort of standartization of ARM booting we have these days. > If the idea is that the Pi platform is less free than the x86 platform > because you need to provide non-free blobs for boot, you may want to > take a closer look at how modern x86 PCs behave in that matter, > because they are just as non-free as the Pi, albeit in a manner that > makes it less visible to the user. I did not meant that. But I can compare Raspberry Pi to, say, kirkwood subarch (QNAP TS series), where all you need to boot is a free software without exceptions, starting with the bootloader. Or, I can compare it to Odroid N2/N2+, where all non-free blobs are contained to SPI, and the proper free OS is booted via simple kexec. > But again, it doesn't matter because the provision of non-free blobs > is then moved outside of what Debian needs to concern itself with > (it's now part of TF-A/UEFI bringup, which is the place where these > blobs should logically reside), which allows the use of blob-free > Debian images. But still, if [1] haven't stalled - all this discussion we're having today would be pointless. Reco [1] https://github.com/christinaa/rpi-open-firmware
Replacement for raspPi
G'day I've been following the recent thread Subject: Re: Debian on Pine64 H64B? I'm looking for suggestions for a new SBC, please. Ideally something more than 2M RAM. I see that a few a happy with Pine laptops. Does this translate to their SBC? Thanks Background. I've just set up a new SDCard with raspberryOS. Set myself up as a user, and set root passsword. When I sshfs to my laptop, the mount point AND all subdirectories are owned exclusively buy user pi. Not even root has access. So I'm out of raspberry as quick as possible. I'm in the process of writing debian to a SDcard in the hope that that will let me get on. Some will recall the discussion around raspberry adding a MS repo to sources.list last year. All the best Keith Bainbridge keith.bainbridge.3...@gmail.com
Re: Debian on Pine64 H64B?
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 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. I'd say that's not really true, since it's very much possible to install Bullseye on the Pi 4 using *vanilla* unmodified ARM64 Debian ISOs [1]. And the same has been true for Buster on the Pi 3 for some time too [2]. A small nitpick. While it's indeed possible to boot rebuilt UEFI on Raspberry Pi3 (which is free software, since it's patched TianoCore), and boot unmodified Debian ARM64 via said UEFI - the booting of UEFI itself still requires Broadcom blobs, which are non-free software. 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 manufacturers have decided they no longer want to open) that are integrated into the UEFI firmware and that you don't see or have to provide yourself, but that are very much present still. If the idea is that the Pi platform is less free than the x86 platform because you need to provide non-free blobs for boot, you may want to take a closer look at how modern x86 PCs behave in that matter, because they are just as non-free as the Pi, albeit in a manner that makes it less visible to the user. But again, it doesn't matter because the provision of non-free blobs is then moved outside of what Debian needs to concern itself with (it's now part of TF-A/UEFI bringup, which is the place where these blobs should logically reside), which allows the use of blob-free Debian images. While UEFI is Open Source, it far from being Free Software (which of course it was never designed to be, in order to accommodate system providers who do did to add proprietary blobs from the get go), and the provision of non-free blobs there becomes a non-issue (outside of user-acceptance that their system relies on using non-free software, but considering that any modern x86 user is pretty forced to accept that these days, I don't see how the Pi situation should suddenly become special in that regard). Regards, /Pete
Re: Debian on Pine64 H64B?
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 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. > > I'd say that's not really true, since it's very much possible to > install Bullseye on the Pi 4 using *vanilla* unmodified ARM64 Debian > ISOs [1]. And the same has been true for Buster on the Pi 3 for some > time too [2]. A small nitpick. While it's indeed possible to boot rebuilt UEFI on Raspberry Pi3 (which is free software, since it's patched TianoCore), and boot unmodified Debian ARM64 via said UEFI - the booting of UEFI itself still requires Broadcom blobs, which are non-free software. Reco
Re: Debian on Pine64 H64B?
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_ 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. I'd say that's not really true, since it's very much possible to install Bullseye on the Pi 4 using *vanilla* unmodified ARM64 Debian ISOs [1]. And the same has been true for Buster on the Pi 3 for some time too [2]. So there are official Debian images for the Raspberry Pi hardware in the form of the vanilla ISOs that are already being published, and that let users sort the install issue by letting them bring the proprietary blobs along with an SBBR compliant UEFI firmware, to make the whole process work (and the same will apply to any ARM platform that is made SBBR compliant, as this is the whole point of introducing a boot standard). Granted, that wasn't possible for the Pi 1 and Pi 2 platforms, so your original point stands, but the situation has been evolving and, as much as I appreciate the work you did, I think it is time to seriously look at whether Debian wants to continue promoting the use of *custom-built* images for the installation of the system on modern Raspberry Pis' (which, in my view is a dead end) or whether we should start advocating for a more universal approach that no longer relies on volunteers like yourself investing a lot of time to produce said pre-built images, with all the drawbacks that that entails. Now, I'm not going to pretend that everything is peachy with this new UEFI/SBBR mode of installing vanilla images, because it's still fairly new, and there are still quite a few rough edges to sort out (for instance, the Debian installer appears to have a multiple problem with the provision of firmware blobs, one of which being that is chokes on ones that contain spaces, which means that it'll request "brcm/brcmfmac43455-sdio.Raspberry" instead of "brcm/brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 Model B.txt", and also it doesn't seem to be able to look up a blob on USB drives unless the media is re-plugged for each blob) as well as missing drivers. But I'm continuing to be concerned that Pi users coming to this list are still being painted the picture that there is no salvation outside of the use of pre-built images, when there much certainly exist an alternative. Whatever floats your boat. Exactly. I think it should be better for us to provide users with a choice when there exist multiple ones when it comes to installing Debian on the Pi, and not give the impression that pre-built images is the only way. Please bear in mind that some people have probably worked as hard as you did on making sure that there exists an alternative to pre-built, so, as much as I understand that you want to promote your work, I'd also appreciate if you started to paint a more accurate picture when it comes to not being able to use official images for the installation of Debian on modern Raspberry Pi's, especially after some people, including Debian maintainers who worked on fixing bugs related to UEFI/SBBR boot, invested time and effort making sure that this statement was no longer true. Regard, /Pete [1] https://www.raspberrypi.org/forums/viewtopic.php?f=50&t=282839 [2] https://pete.akeo.ie/2019/07/installing-debian-arm64-on-raspberry-pi.html
Re: Debian on Raspberry Pi and Pine* and probably ARM support in general (was Re: Debian on Pine64 H64B?)
On Sb, 04 sep 21, 08:31:11, Vagrant Cascadian wrote: > On 2021-09-04, LinAdmin wrote: > > The unnamed decision makers of Debian some unknown time ago > > decided that Pi and Pine stuff won't be supported by Debian. > > I personally have added support in Debian for: > > Raspberry Pi 1 > Raspberry Pi 2b > Raspberry Pi 3b+ > Pine64+ > Pinebook > Pinebook Pro > RockPro64 > Rock64 Thank you! Kind regards, Andrei -- happy Debian user of a PINE A64+ and (still) considering the Pinebook Pro for my next laptop -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
