On Mon, 8 May 2023 at 14:57, Diederik de Haas wrote:
>
> On Monday, 8 May 2023 14:08:14 CEST James Addison wrote:
> > On Mon, 1 May 2023 11:18:03 +0100, James Addison
> > wrote:
> > > > Diederik de Haas (2023-04-30):
> > > > > And that's exactly what happens or will happen. Even though the
On Monday, 8 May 2023 14:08:14 CEST James Addison wrote:
> On Mon, 1 May 2023 11:18:03 +0100, James Addison wrote:
> > > Diederik de Haas (2023-04-30):
> > > > And that's exactly what happens or will happen. Even though the RPi4
> > > > filename doesn't contain spaces, there are several in the
Package: firmware-brcm80211
Followup-For: Bug #1029843
X-Debbugs-Cc: k...@debian.org, didi.deb...@cknow.org,
debian-b...@lists.debian.org, p...@akeo.ie
On Mon, 1 May 2023 11:18:03 +0100, James Addison wrote:
> > Diederik de Haas (2023-04-30):
> > > And that's exact
James Addison (2023-05-04):
> I think that the edits to 'debian/config/brcm80211/defines' may be the cause
> of the space-escaping issue (noticed that in your fork on Salsa).
>
> Building locally without modifications from firmware-nonfree_20230210-5 I get:
> lrwxrwxrwx 1 jka jka 44 May 4
Hi,
Diederik de Haas (2023-05-04):
> Assuming the '55' stands for max 55 chars, that could be an issue?
That's not how format strings work. :)
That happily overflows:
$ printf "%-10s and the rest of the line\n" kibi
kibi and the rest of the line
$ printf "%-10s and the rest
[ replying with some re-ordering ]
On Wed, 3 May 2023 at 21:23, Pete Batard wrote:
> Obviously, with the idea of not having ARM based device that are
> constrained to a single OS (be it Windows, Linux, BSD or something> else),
> and considering that Windows and Device Tree don't work together,
Control: block -1 1035505
On Thursday, 4 May 2023 01:41:12 CEST Cyril Brulebois wrote:
> Diederik de Haas (2023-05-04):
> > And that makes it a firmware-brcm80211 issue and now it all does make
> > sense as it now all does tie together :-)
>
> Great, that's what it looked like to me but I was
Hi,
Diederik de Haas (2023-05-04):
> On Thursday, 4 May 2023 00:21:25 CEST James Addison wrote:
> > I added a note[1] on the rpi4-uefi.dev GitHub repository, and from
> > one of your fellow contributors' responses, it seems that in fact
> > the filename-with-spaces format _is_ referenced from
>
On Thursday, 4 May 2023 01:03:08 CEST Diederik de Haas wrote:
> Control: affects -1 -raspi-firmware
That it affects a RPi device does NOT mean it affects the raspi-firmware
package,
so I removed that field (hopefully)
signature.asc
Description: This is a digitally signed message part.
Control: reassign -1 firmware-brcm80211
Control: affects -1 -raspi-firmware
Control: retitle -1 Missing symlinks for RPi 4 (to
brcmfmac43455-sdio.raspberrypi,4-model-b.txt)
On Thursday, 4 May 2023 00:21:25 CEST James Addison wrote:
> I added a note[1] on the rpi4-uefi.dev GitHub repository, and
Package: src:linux
Followup-For: Bug #1029843
X-Debbugs-Cc: p...@akeo.ie, k...@debian.org, didi.deb...@cknow.org,
debian-b...@lists.debian.org, 1029...@bugs.debian.org, 1035...@bugs.debian.org,
989...@bugs.debian.org, debian-...@lists.debian.org
Control: retitle -1 brcmfmac: requested firmware
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
Control: unmerge 1029843 1030519
Control: reassign 1029843 src:linux
Control: retitle 1029843 brcmfmac: requested firmware filename
inconsistent with linux-firmware.git on non-devicetree systems
Control: affects 1029843 firmware-brcm80211 raspi-firmware
Dear Maintainer,
This bugreport relates to
On Wed, 3 May 2023 at 16:49, Cyril Brulebois wrote:
> James Addison (2023-05-03):
> > After editing and rebuilding the Device Tree (DTS) files, and
> > deploying those changes to the system, I can confirm that adjusting
> > the 'model' field value in there has no effect on the requested fw
> >
On Wednesday, 3 May 2023 17:18:42 CEST James Addison wrote:
> The system's dmesg includes this line:
>
> DMI: Raspberry Pi Foundation Raspberry Pi 400/Raspberry Pi 400, BIOS
> UEFI Firmware v1.34 1 2/16/2022
>
> As Cyril said though.. this can't (shouldn't) be genuine DMI. So
> what's going
Hi,
James Addison (2023-05-03):
> After editing and rebuilding the Device Tree (DTS) files, and
> deploying those changes to the system, I can confirm that adjusting
> the 'model' field value in there has no effect on the requested fw
> filename.
Did those modifications stay in place once you
Mystery may be (partially) solved. Responses inline below.
On Wed, 3 May 2023 at 15:17, Diederik de Haas wrote:
>
> On Wednesday, 3 May 2023 03:41:05 CEST James Addison wrote:
> > I think that the vendor name is coming from a DMI fallback:
> > ...
> >
On Wednesday, 3 May 2023 03:41:05 CEST James Addison wrote:
> I think that the vendor name is coming from a DMI fallback:
>
> https://sources.debian.org/src/linux/6.1.25-1/drivers/net/wireless/broadcom/
> brcm80211/brcmfmac/common.c/?hl=487#L487
>
> Whether the model name is from DMI or from the
On Wed, 3 May 2023 at 03:02, Cyril Brulebois wrote:
> James Addison (2023-05-03):
> > I think that the vendor name is coming from a DMI fallback:
> > https://sources.debian.org/src/linux/6.1.25-1/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c/?hl=487#L487
>
> I smiled. :)
>
> The
Hi,
James Addison (2023-05-03):
> I think that the vendor name is coming from a DMI fallback:
> https://sources.debian.org/src/linux/6.1.25-1/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c/?hl=487#L487
I smiled. :)
The (still quick) glance I had earlier stopped when I reached “DMI”
Control: retitle -1 hw-detect: firmware file path handling is fragile
Control: clone -1 -2
Control: reassign -2 src:linux
Control: retitle -2 brcmfmac: firmware filename inconsistency with
linux-firmware.git
On Wed, 3 May 2023 at 00:34, Cyril Brulebois wrote:
>
> James Addison (2023-05-02):
>
Hi James,
I've just finished a very long debugging session[1], so the following is
really best effort and probably not 100%.
1.
https://lore.kernel.org/all/20230428223500.23337-1-jim2101...@gmail.com/T/#m846b07884ef687d3669654c782aa3b61216f15b7
James Addison (2023-05-02):
> Could either of
On Mon, 1 May 2023 at 20:03, Cyril Brulebois wrote:
> James Addison (2023-05-01):
> > Also, the brcmfmac kernel module code mentions[3] that it can load
> > board-specific firmware file paths. I'm not yet sure whether that's
> > relevant (either now, or in future).
>
> Yeah, both the function
Hi,
James Addison (2023-05-01):
> Also, the brcmfmac kernel module code mentions[3] that it can load
> board-specific firmware file paths. I'm not yet sure whether that's
> relevant (either now, or in future).
Yeah, both the function you pointed to and the one handling actual
firmware requests
On Mon, 1 May 2023 at 03:00, Cyril Brulebois wrote:
> Diederik de Haas (2023-04-30):
> > I suggest we stick to `brcmfmac43455-sdio.raspberrypi,4-model-b.txt` as that
> > is its name in the upstream repo:
> > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
>
> Yes
Hi,
Diederik de Haas (2023-04-30):
> I suggest we stick to `brcmfmac43455-sdio.raspberrypi,4-model-b.txt` as that
> is its name in the upstream repo:
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
Yes please.
> > And a nitpick: the way this appears in the
On Sunday, 30 April 2023 20:25:50 CEST James Addison wrote:
> Do we _need_ to retain the vendor name and model name in the firmware
> filename?
>
> My guess (without being too familiar with the firmware loading process yet)
> is that it'd be easier to ship a concisely-named file that omit the
Followup-For: Bug #1029843
X-Debbugs-Cc: a.dalm2...@googlemail.com, p...@akeo.ie,
debian-b...@lists.debian.org
Control: reassign -1 hw-detect
Control: merge -1 1030519
Control: affects -1 raspi-firmware
Control: title -1 check-missing-firmware: patch for files with space
characters, mediamount
instead of the overlapping there could simply be an issue with the parsing
of the "brcmfmac43340.To be filled by O.E.M.txt" file at the first space
character so a .To is file requested.
"To be filled by O.E.M." is the Manufacturer Name and "Z83" the Product
Name stored in my BIOS, there are some
Package: live-boot
Severity: normal
X-Debbugs-Cc: a.dalm2...@googlemail.com
Dear Maintainer,
on the Devices Requiring Firmware step in the debian-installer
(debian-11.6.0-amd64-netinst.iso)
multiple files are requested for my Beelink BT3:
brcmfmac43340-sdio.bin
30 matches
Mail list logo
