ThinkPad T420 and FireWire chip on Linux
Hello, Recently I have decided to give a try to coreboot for first time and flashed my ThinkPad T420, but a few weeks ago I have swapped the USB controller on the back, next to the battery, with a FireWire/USB controller (40GAB5809-G200) from another T420. Nothing special, since some models have been shipped like this. The controller is no longer accessible on my laptop. It seems like it may have been detected as an "SD Host Controller" or not detected at all. I will probably have to remove the chip and compare the output of lspci and lshw. If nothing has changed, I will probably have to return the stock BIOS and compare the results again. I have also tried to load some of the firewire kernel modules manually with modprobe. The operating systems I have tested so far are Arch Linux and Xubuntu. I am willing to provide more useful information, boot into a fresh Windows install, flash the chip again or whatever else. Correct me if I am wrong, but if I go back to the stock BIOS, the next time I flash, I will have to disassemble the laptop again and otherwise I must be fine with flashing internally, right? Thanks
Hi, I am in the same situation. Same board and same controller. Still didn't flash coreboot but I also want to make FW work with coreboot. Could you please share your coreboot build config? Did you build master repo? Thanks. I am also willing to test images and configs to make that setup work. On April 8, 2020 6:23:27 AM UTC, Alesandar Metodiev <alesandarmetodiev@gmail.com> wrote:
Hello,
Recently I have decided to give a try to coreboot for first time and flashed my ThinkPad T420, but a few weeks ago I have swapped the USB controller on the back, next to the battery, with a FireWire/USB controller (40GAB5809-G200) from another T420. Nothing special, since some models have been shipped like this. The controller is no longer accessible on my laptop.
It seems like it may have been detected as an "SD Host Controller" or not detected at all. I will probably have to remove the chip and compare the output of lspci and lshw. If nothing has changed, I will probably have to return the stock BIOS and compare the results again. I have also tried to load some of the firewire kernel modules manually with modprobe.
The operating systems I have tested so far are Arch Linux and Xubuntu. I am willing to provide more useful information, boot into a fresh Windows install, flash the chip again or whatever else. Correct me if I am wrong, but if I go back to the stock BIOS, the next time I flash, I will have to disassemble the laptop again and otherwise I must be fine with flashing internally, right?
Thanks
Dear AreYouLoco, Am 08.04.20 um 10:59 schrieb AreYouLoco?:
I am in the same situation. Same board and same controller. Still didn't flash coreboot but I also want to make FW work with coreboot. Could you please share your coreboot build config? Did you build master repo?
Thanks. I am also willing to test images and configs to make that setup work.
So, as you still running the vendor firmware, does this setup, especially the FireWire/USB controller (40GAB5809-G200), work with the vendor firmware? If so, please share the Linux messages and attach the output of `sudo lspci -vvxxx`. Kind regards, Paul
On stock latest firmware and ubuntu studio I do see this: https://del.dog/raw/firewire_lspci I just builded coreboot. Backing up stock and trying to see if it's detected with coreboot. Fingers crossed! On April 8, 2020 9:15:22 AM UTC, Paul Menzel <pmenzel@molgen.mpg.de> wrote:
Dear AreYouLoco,
Am 08.04.20 um 10:59 schrieb AreYouLoco?:
I am in the same situation. Same board and same controller. Still didn't flash coreboot but I also want to make FW work with coreboot. Could you please share your coreboot build config? Did you build master repo?
Thanks. I am also willing to test images and configs to make that setup work.
So, as you still running the vendor firmware, does this setup, especially the FireWire/USB controller (40GAB5809-G200), work with the vendor firmware? If so, please share the Linux messages and attach the output of `sudo lspci -vvxxx`.
Kind regards,
Paul _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
AreYouLoco, I am really glad to see there is someone else who is interested in this. If necessary, I will provide the coreboot config in a few hours, but it was nothing special. It was built from master and I have simply selected mainboard vendor/model, checked *Use CMOS for configuration values *and increased *Size of CBFS* up to 0x300000. In the meanwhile, here's my only lspci entry related to Ricoh: https://del.dog/lspci_ricoh_coreboot.txt I believe that *src/mainboard/lenovo/t420/devicetree.cb* (around line 85) has a statement related to that controller, but I will have to take a closer look at the coreboot source-code. device pci 1c.4 on
chip drivers/ricoh/rce822 register "sdwppol" = "1" register "disable_mask" = "0x87" device pci 00.0 on end end end # PCIe Port #5 (Ricoh SD & FW)
On Wed, Apr 8, 2020 at 1:05 PM AreYouLoco? <areyouloco@paranoici.org> wrote:
On stock latest firmware and ubuntu studio I do see this: https://del.dog/raw/firewire_lspci
I just builded coreboot. Backing up stock and trying to see if it's detected with coreboot.
Fingers crossed!
On April 8, 2020 9:15:22 AM UTC, Paul Menzel <pmenzel@molgen.mpg.de> wrote:
Dear AreYouLoco,
Am 08.04.20 um 10:59 schrieb AreYouLoco?:
I am in the same situation. Same board and same controller. Still didn't flash coreboot but I also want to make FW work with coreboot. Could you please share your coreboot build config? Did you build master repo?
Thanks. I am also willing to test images and configs to make that setup work.
So, as you still running the vendor firmware, does this setup, especially the FireWire/USB controller (40GAB5809-G200), work with the vendor firmware? If so, please share the Linux messages and attach the output of `sudo lspci -vvxxx`.
Kind regards,
Paul _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
I can confirm that my Firewire controller with coreboot is detected as MMC/SD Controller. The same situation as yours so seems like a bug. I tried Debian and Ubuntu Studio both detect it as SD/MMC Controller. It gets detected correctly on stock BIOS. Devs? On 08.04.2020 13:22, Alesandar Metodiev wrote:
AreYouLoco, I am really glad to see there is someone else who is interested in this. If necessary, I will provide the coreboot config in a few hours, but it was nothing special. It was built from master and I have simply selected mainboard vendor/model, checked /Use CMOS for configuration values /and increased /Size of CBFS/ up to 0x300000.
In the meanwhile, here's my only lspci entry related to Ricoh: https://del.dog/lspci_ricoh_coreboot.txt
I believe that /src/mainboard/lenovo/t420/devicetree.cb/ (around line 85) has a statement related to that controller, but I will have to take a closer look at the coreboot source-code.
device pci 1c.4 on chip drivers/ricoh/rce822 register "sdwppol" = "1" register "disable_mask" = "0x87" device pci 00.0 on end end end # PCIe Port #5 (Ricoh SD & FW)
On Wed, Apr 8, 2020 at 1:05 PM AreYouLoco? <areyouloco@paranoici.org <mailto:areyouloco@paranoici.org>> wrote:
On stock latest firmware and ubuntu studio I do see this: https://del.dog/raw/firewire_lspci
I just builded coreboot. Backing up stock and trying to see if it's detected with coreboot.
Fingers crossed!
On April 8, 2020 9:15:22 AM UTC, Paul Menzel <pmenzel@molgen.mpg.de <mailto:pmenzel@molgen.mpg.de>> wrote: >Dear AreYouLoco, > > >Am 08.04.20 um 10:59 schrieb AreYouLoco?: > >> I am in the same situation. Same board and same controller. Still >> didn't flash coreboot but I also want to make FW work with coreboot. >> Could you please share your coreboot build config? Did you build >> master repo? >> >> Thanks. I am also willing to test images and configs to make that >> setup work. > >So, as you still running the vendor firmware, does this setup, >especially the FireWire/USB controller (40GAB5809-G200), work with the >vendor firmware? If so, please share the Linux messages and attach the >output of `sudo lspci -vvxxx`. > > >Kind regards, > >Paul >_______________________________________________ >coreboot mailing list -- coreboot@coreboot.org <mailto:coreboot@coreboot.org> >To unsubscribe send an email to coreboot-leave@coreboot.org <mailto:coreboot-leave@coreboot.org>
-- AreYouLoco? GPG 2717 7338 4742 E034 F65F 7C83 C757 3088 E8B7 DEDA
Attaching logs: cbmem -1 > https://del.dog/raw/cbmemlog lspci -vvxxx > https://del.dog/raw/sd-mmc-not-fw On 08.04.2020 13:45, AreYouLoco? wrote:
I can confirm that my Firewire controller with coreboot is detected as MMC/SD Controller. The same situation as yours so seems like a bug.
I tried Debian and Ubuntu Studio both detect it as SD/MMC Controller. It gets detected correctly on stock BIOS. Devs?
On 08.04.2020 13:22, Alesandar Metodiev wrote:
AreYouLoco, I am really glad to see there is someone else who is interested in this. If necessary, I will provide the coreboot config in a few hours, but it was nothing special. It was built from master and I have simply selected mainboard vendor/model, checked /Use CMOS for configuration values /and increased /Size of CBFS/ up to 0x300000.
In the meanwhile, here's my only lspci entry related to Ricoh: https://del.dog/lspci_ricoh_coreboot.txt
I believe that /src/mainboard/lenovo/t420/devicetree.cb/ (around line 85) has a statement related to that controller, but I will have to take a closer look at the coreboot source-code.
device pci 1c.4 on chip drivers/ricoh/rce822 register "sdwppol" = "1" register "disable_mask" = "0x87" device pci 00.0 on end end end # PCIe Port #5 (Ricoh SD & FW)
On Wed, Apr 8, 2020 at 1:05 PM AreYouLoco? <areyouloco@paranoici.org <mailto:areyouloco@paranoici.org>> wrote:
On stock latest firmware and ubuntu studio I do see this: https://del.dog/raw/firewire_lspci
I just builded coreboot. Backing up stock and trying to see if it's detected with coreboot.
Fingers crossed!
On April 8, 2020 9:15:22 AM UTC, Paul Menzel <pmenzel@molgen.mpg.de <mailto:pmenzel@molgen.mpg.de>> wrote: >Dear AreYouLoco, > > >Am 08.04.20 um 10:59 schrieb AreYouLoco?: > >> I am in the same situation. Same board and same controller. Still >> didn't flash coreboot but I also want to make FW work with coreboot. >> Could you please share your coreboot build config? Did you build >> master repo? >> >> Thanks. I am also willing to test images and configs to make that >> setup work. > >So, as you still running the vendor firmware, does this setup, >especially the FireWire/USB controller (40GAB5809-G200), work with the >vendor firmware? If so, please share the Linux messages and attach the >output of `sudo lspci -vvxxx`. > > >Kind regards, > >Paul >_______________________________________________ >coreboot mailing list -- coreboot@coreboot.org <mailto:coreboot@coreboot.org> >To unsubscribe send an email to coreboot-leave@coreboot.org <mailto:coreboot-leave@coreboot.org>
-- AreYouLoco? GPG 2717 7338 4742 E034 F65F 7C83 C757 3088 E8B7 DEDA
Hi, On 08.04.20 13:45, AreYouLoco? wrote:
I can confirm that my Firewire controller with coreboot is detected as MMC/SD Controller. The same situation as yours so seems like a bug.
I tried Debian and Ubuntu Studio both detect it as SD/MMC Controller. It gets detected correctly on stock BIOS. Devs?
what you show in the lspci output with coreboot just looks like a different controller. The output is not enough to figure where it is connected. The controller is not "detected" as SD/MMC, it identifies itself as such. In theory, this identification could change, e.g. when the BIOS uploads some special firmware. But it seems unlikely. To know more, we'd need to see the PCIe RootPort allocation. It's the 1c.* devices, but the firmware can change the numbers. Both lspci -nnvvv -s 1c lspci -tv with the vendor firmware would be helpful. Or just -nnvvv for all devices (just -v might also be enough if you have that at hand). Nico
Nico, AreYouLoco has already posted the output of `sudo lspci -vvxxx -s 0d:00.3` (when he was still running with the vendor firmware). Here it is. https://del.dog/raw/firewire_lspci On Wed, Apr 8, 2020 at 6:41 PM Nico Huber <nico.h@gmx.de> wrote:
Hi,
On 08.04.20 13:45, AreYouLoco? wrote:
I can confirm that my Firewire controller with coreboot is detected as MMC/SD Controller. The same situation as yours so seems like a bug.
I tried Debian and Ubuntu Studio both detect it as SD/MMC Controller. It gets detected correctly on stock BIOS. Devs?
what you show in the lspci output with coreboot just looks like a different controller. The output is not enough to figure where it is connected. The controller is not "detected" as SD/MMC, it identifies itself as such. In theory, this identification could change, e.g. when the BIOS uploads some special firmware. But it seems unlikely.
To know more, we'd need to see the PCIe RootPort allocation. It's the 1c.* devices, but the firmware can change the numbers. Both
lspci -nnvvv -s 1c lspci -tv
with the vendor firmware would be helpful. Or just -nnvvv for all devices (just -v might also be enough if you have that at hand).
Nico
Now I flashed backed up stock (to get the output of full lspci and lspci -nntv) but it doesn't boot up...flashing stock again... On 08.04.2020 18:01, Alesandar Metodiev wrote:
Nico, AreYouLoco has already posted the output of `sudo lspci -vvxxx -s 0d:00.3` (when he was still running with the vendor firmware). Here it is. https://del.dog/raw/firewire_lspci
On Wed, Apr 8, 2020 at 6:41 PM Nico Huber <nico.h@gmx.de <mailto:nico.h@gmx.de>> wrote:
Hi,
On 08.04.20 13:45, AreYouLoco? wrote: > I can confirm that my Firewire controller with coreboot is detected as > MMC/SD Controller. The same situation as yours so seems like a bug. > > I tried Debian and Ubuntu Studio both detect it as SD/MMC Controller. > It gets detected correctly on stock BIOS. Devs?
what you show in the lspci output with coreboot just looks like a different controller. The output is not enough to figure where it is connected. The controller is not "detected" as SD/MMC, it identifies itself as such. In theory, this identification could change, e.g. when the BIOS uploads some special firmware. But it seems unlikely.
To know more, we'd need to see the PCIe RootPort allocation. It's the 1c.* devices, but the firmware can change the numbers. Both
lspci -nnvvv -s 1c lspci -tv
with the vendor firmware would be helpful. Or just -nnvvv for all devices (just -v might also be enough if you have that at hand).
Nico
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- AreYouLoco? GPG 2717 7338 4742 E034 F65F 7C83 C757 3088 E8B7 DEDA
Flashed stock it worked. Seems like LVDS ribbon was not connected. Here is lspci --nntv output: https://del.dog/raw/lspci_nntv On 08.04.2020 18:01, Alesandar Metodiev wrote:
Nico, AreYouLoco has already posted the output of `sudo lspci -vvxxx -s 0d:00.3` (when he was still running with the vendor firmware). Here it is. https://del.dog/raw/firewire_lspci
On Wed, Apr 8, 2020 at 6:41 PM Nico Huber <nico.h@gmx.de <mailto:nico.h@gmx.de>> wrote:
Hi,
On 08.04.20 13:45, AreYouLoco? wrote: > I can confirm that my Firewire controller with coreboot is detected as > MMC/SD Controller. The same situation as yours so seems like a bug. > > I tried Debian and Ubuntu Studio both detect it as SD/MMC Controller. > It gets detected correctly on stock BIOS. Devs?
what you show in the lspci output with coreboot just looks like a different controller. The output is not enough to figure where it is connected. The controller is not "detected" as SD/MMC, it identifies itself as such. In theory, this identification could change, e.g. when the BIOS uploads some special firmware. But it seems unlikely.
To know more, we'd need to see the PCIe RootPort allocation. It's the 1c.* devices, but the firmware can change the numbers. Both
lspci -nnvvv -s 1c lspci -tv
with the vendor firmware would be helpful. Or just -nnvvv for all devices (just -v might also be enough if you have that at hand).
Nico
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- AreYouLoco? GPG 2717 7338 4742 E034 F65F 7C83 C757 3088 E8B7 DEDA
Hi, this is a fun one. Alesandar Metodiev wrote:
AreYouLoco has already posted the output of `sudo lspci -vvxxx -s 0d:00.3` (when he was still running with the vendor firmware). Here it is. https://del.dog/raw/firewire_lspci
Comparing that with https://del.dog/raw/lspci_nntv shows that the chip presents itself differently on the very lowes level. Factory BIOS: Ricoh Co Ltd PCIe SDXC/MMC Host Controller [1180:e823] coreboot: Ricoh Co Ltd MMC/SD Host Controller [what:ids?] If we look at the beginning of the config space dump in the coreboot case, we see: 00: 80 11 22 e8 These are little-endian vendor and device IDs, swap around to: [1180:e822] The same chip seems to present itself differently depending on the firmware. I've seen this before, and in fact I think it was the same kind of chip. That time there was no coreboot involved, the ID seemed to change depending on whether the laptop was rebooted or actually powered off. I guess that this device behaves differently depending on how and when it is initialized. I've also seen Atheros PCI devices come up as 0000:0000, which hints to a race condition where the PCI device just isn't ready when coreboot comes to speak to it. Maybe try sprinkling random delays in the code. Or increase debug level. Or enable spkmodem. Something to make coreboot run slower. Then maybe that hardware works correctly. //Peter
I was wrong it isn't detected as SD/MMC it doesn't get detected at all. There is a separate device for SD/MMC present both on coreboot and stock. Same chip tho Ricoh Co Ltd R5C832. @hell__ on the IRC mentioned it's a function of the Ricoh interface seen here as slash: https://del.dog/raw/lspci_nntv I've tried adding: "device pci 00.3 on end # FireWire Controller" after: https://github.com/coreboot/coreboot/blob/master/src/mainboard/lenovo/t420/d... And rebuild and flashed but still no luck. I am no programmer. Just hit and run technique. Help would be more than welcomed here. On 08.04.2020 20:02, Peter Stuge wrote:
Hi,
this is a fun one.
Alesandar Metodiev wrote:
AreYouLoco has already posted the output of `sudo lspci -vvxxx -s 0d:00.3` (when he was still running with the vendor firmware). Here it is. https://del.dog/raw/firewire_lspci
Comparing that with https://del.dog/raw/lspci_nntv shows that the chip presents itself differently on the very lowes level.
Factory BIOS: Ricoh Co Ltd PCIe SDXC/MMC Host Controller [1180:e823]
coreboot: Ricoh Co Ltd MMC/SD Host Controller [what:ids?]
If we look at the beginning of the config space dump in the coreboot case, we see:
00: 80 11 22 e8
These are little-endian vendor and device IDs, swap around to: [1180:e822]
The same chip seems to present itself differently depending on the firmware.
I've seen this before, and in fact I think it was the same kind of chip.
That time there was no coreboot involved, the ID seemed to change depending on whether the laptop was rebooted or actually powered off.
I guess that this device behaves differently depending on how and when it is initialized. I've also seen Atheros PCI devices come up as 0000:0000, which hints to a race condition where the PCI device just isn't ready when coreboot comes to speak to it.
Maybe try sprinkling random delays in the code. Or increase debug level. Or enable spkmodem. Something to make coreboot run slower. Then maybe that hardware works correctly.
//Peter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- AreYouLoco? GPG 2717 7338 4742 E034 F65F 7C83 C757 3088 E8B7 DEDA
On 08.04.20 20:02, Peter Stuge wrote:
Alesandar Metodiev wrote:
AreYouLoco has already posted the output of `sudo lspci -vvxxx -s 0d:00.3` (when he was still running with the vendor firmware). Here it is. https://del.dog/raw/firewire_lspci
Comparing that with https://del.dog/raw/lspci_nntv shows that the chip presents itself differently on the very lowes level.
Factory BIOS: Ricoh Co Ltd PCIe SDXC/MMC Host Controller [1180:e823]
coreboot: Ricoh Co Ltd MMC/SD Host Controller [what:ids?]
If we look at the beginning of the config space dump in the coreboot case, we see:
00: 80 11 22 e8
These are little-endian vendor and device IDs, swap around to: [1180:e822]
e822 vs. e823 smells like an upgrade to me. I suspect that we'd need to load some firmware on the 0.0 device. Or at least to configure something there so it switches 0.3 on. Nico
I have tried to enable spkmodem, but now I can not boot at all. Maybe I did something wrong. No SeaBios, just a black screen. I will try to find some free time tomorrow, in order to disassemble and flash the laptop again, but I can't promise anything. On Wed, Apr 8, 2020 at 10:29 PM Nico Huber <nico.h@gmx.de> wrote:
On 08.04.20 20:02, Peter Stuge wrote:
Alesandar Metodiev wrote:
AreYouLoco has already posted the output of `sudo lspci -vvxxx -s 0d:00.3` (when he was still running with the vendor firmware). Here it is. https://del.dog/raw/firewire_lspci
Comparing that with https://del.dog/raw/lspci_nntv shows that the chip presents itself differently on the very lowes level.
Factory BIOS: Ricoh Co Ltd PCIe SDXC/MMC Host Controller [1180:e823]
coreboot: Ricoh Co Ltd MMC/SD Host Controller [what:ids?]
If we look at the beginning of the config space dump in the coreboot case, we see:
00: 80 11 22 e8
These are little-endian vendor and device IDs, swap around to: [1180:e822]
e822 vs. e823 smells like an upgrade to me. I suspect that we'd need to load some firmware on the 0.0 device. Or at least to configure something there so it switches 0.3 on.
Nico
On 08.04.20 21:29, Nico Huber wrote:
On 08.04.20 20:02, Peter Stuge wrote:
Alesandar Metodiev wrote:
AreYouLoco has already posted the output of `sudo lspci -vvxxx -s 0d:00.3` (when he was still running with the vendor firmware). Here it is. https://del.dog/raw/firewire_lspci
Comparing that with https://del.dog/raw/lspci_nntv shows that the chip presents itself differently on the very lowes level.
Factory BIOS: Ricoh Co Ltd PCIe SDXC/MMC Host Controller [1180:e823]
coreboot: Ricoh Co Ltd MMC/SD Host Controller [what:ids?]
If we look at the beginning of the config space dump in the coreboot case, we see:
00: 80 11 22 e8
These are little-endian vendor and device IDs, swap around to: [1180:e822]
e822 vs. e823 smells like an upgrade to me. I suspect that we'd need to load some firmware on the 0.0 device. Or at least to configure something there so it switches 0.3 on.
Some more vendor dumps courtesy of AreYouLoco: https://del.dog/raw/nnvvvxxx_root https://del.dog/raw/xxxx_root https://del.dog/raw/lspci_tv Note, lspci calls it e823 even the DID register says e822, I have no idea where it gets the number from. Peter, do you happen to know something about the Virtual Channel capability? Nico
AreYouLoco? wrote:
I was wrong it isn't detected as SD/MMC it doesn't get detected at all. There is a separate device for SD/MMC present both on coreboot and stock.
Are you really sure? There is no such device in the vendor BIOS logs. Alesandar Metodiev wrote:
I have tried to enable spkmodem, but now I can not boot at all. Maybe I did something wrong. No SeaBios, just a black screen.
No - just wait really long, 10-20 minutes, depending on console level. IIRC it's 1200 bps, around 100 byte per second, so the 110860 byte console log at https://del.dog/raw/cbmemlog would take 18 minutes. Reduce the console level with spkmodem. Nico Huber wrote:
e822 vs. e823 smells like an upgrade to me. I suspect that we'd need to load some firmware on the 0.0 device. Or at least to configure something there so it switches 0.3 on.
Nico Huber wrote:
https://del.dog/raw/nnvvvxxx_root https://del.dog/raw/xxxx_root https://del.dog/raw/lspci_tv
Note, lspci calls it e823 even the DID register says e822, I have no idea where it gets the number from.
Also fun. lspci has an -A option to specify how it reads data. It would be interesting to compare what the kernel has (the default is one of the linux- methods) with the registers in the devices (the intel-conf1 method). If there is a difference then maybe the device still wasn't quite ready when the kernel booted.
Peter, do you happen to know something about the Virtual Channel capability?
I didn't, and I looked at the spec now but it seems uninteresting. It's a mechanism for multiple channels over a single link, with each VC possibly having different buffering and traffic class. I found something that might be relevant in https://del.dog/raw/cbmemlog however, search it for Remap: --8<-- https://del.dog/raw/cbmemlog#149 PCI: 00:1c.0: Disabling device PCI: 00:1c.0: check set enabled PCH: Remap PCIe function 1 to 0 PCI: 00:1c.1 [8086/1c12] enabled PCI: 00:1c.2: Disabling device PCH: Remap PCIe function 3 to 0 PCI: 00:1c.3 [8086/1c16] enabled PCH: Remap PCIe function 4 to 0 PCI: 00:1c.4 [8086/1c18] enabled -->8-- It looks strange that fn 1, 3 and 4 are all supposedly remapped to fn 0. I looked in the code, to me it looks like this will cause a mess in RPFN: --8<-- southbridge/intel/bd82x6x/pch.c#229 /* Swap function numbers assigned to two PCIe Root Ports */ static void pch_pcie_function_swap(u8 old_fn, u8 new_fn) { u32 old_rpfn = new_rpfn; printk(BIOS_DEBUG, "PCH: Remap PCIe function %d to %d\n", old_fn, new_fn); new_rpfn &= ~(RPFN_FNMASK(old_fn) | RPFN_FNMASK(new_fn)); /* Old function set to new function and disabled */ new_rpfn |= RPFN_FNSET(old_fn, RPFN_FNGET(old_rpfn, new_fn)); new_rpfn |= RPFN_FNSET(new_fn, RPFN_FNGET(old_rpfn, old_fn)); } ... line 373: int fn; /* * Check if there is a lower disabled port to swap with this * port in order to maintain linear order starting at zero. */ if (config->pcie_port_coalesce) { for (fn=0; fn < PCI_FUNC(dev->path.pci.devfn); fn++) { if (!(new_rpfn & RPFN_HIDE(fn))) continue; /* Swap places with this function */ pch_pcie_function_swap( PCI_FUNC(dev->path.pci.devfn), fn); break; } } -->8-- But later in the log it doesn't look like RPFN has all functions on top of each other, but it also doesn't look really good: --8<-- https://del.dog/raw/cbmemlog#162 PCH: PCIe map 1c.0 -> 1c.4 PCH: PCIe map 1c.1 -> 1c.0 PCH: PCIe map 1c.3 -> 1c.1 PCH: PCIe map 1c.4 -> 1c.3 -->8-- If the gaps are to be filled then I'd expect to see something like: 1c.1 -> 1c.0 1c.3 -> 1c.1 1c.4 -> 1c.2 The devicetree.cb seems not quite done, at least not for this mainboard: --8<-- https://del.dog/raw/cbmemlog#175 PCI: Leftover static devices: PCI: 00:01.0 PCI: 00:16.1 PCI: 00:16.2 PCI: 00:16.3 PCI: 00:1c.4 PCI: 00:1c.2 PCI: 00:1c.5 PCI: 00:1c.7 PCI: Check your devicetree.cb. -->8-- But scanning the busses, actually both the Renesas xHCI/USB3 and the Ricoh are visible: --8<-- https://del.dog/raw/cbmemlog#189 PCI: pci_scan_bus for bus 02 PCI: 02:00.0 [1912/0015] enabled Enabling Common Clock Configuration ASPM: Enabled L0s and L1 PCIe: Max_Payload_Size adjusted to 128 scan_bus: bus PCI: 00:1c.1 finished in 0 msecs PCI: 00:1c.3 scanning... PCI: pci_scan_bus for bus 03 PCI: 03:00.0 [1180/e822] enabled Enabling Common Clock Configuration ASPM: Enabled L0s and L1 PCIe: Max_Payload_Size adjusted to 128 Failed to enable LTR for dev = PCI: 03:00.0 scan_bus: bus PCI: 00:1c.3 finished in 0 msecs -->8-- But the Ricoh has the wrong DID, and while looking at https://del.dog/raw/sd-mmc-not-fw I notice that the device looks more like a PCI device than a PCI Express one, with INTA routed to IRQ 16 instead of using MSI. Sorry - I'm not able to suggest anything really concrete, but these are my observations. //Peter
I have booted with spkmodem enabled, but nothing has changed. The device is still not present. On Thu, Apr 9, 2020 at 3:04 AM Peter Stuge <peter@stuge.se> wrote:
AreYouLoco? wrote:
I was wrong it isn't detected as SD/MMC it doesn't get detected at all. There is a separate device for SD/MMC present both on coreboot and stock.
Are you really sure? There is no such device in the vendor BIOS logs.
Alesandar Metodiev wrote:
I have tried to enable spkmodem, but now I can not boot at all. Maybe I did something wrong. No SeaBios, just a black screen.
No - just wait really long, 10-20 minutes, depending on console level. IIRC it's 1200 bps, around 100 byte per second, so the 110860 byte console log at https://del.dog/raw/cbmemlog would take 18 minutes. Reduce the console level with spkmodem.
Nico Huber wrote:
e822 vs. e823 smells like an upgrade to me. I suspect that we'd need to load some firmware on the 0.0 device. Or at least to configure something there so it switches 0.3 on.
Nico Huber wrote:
https://del.dog/raw/nnvvvxxx_root https://del.dog/raw/xxxx_root https://del.dog/raw/lspci_tv
Note, lspci calls it e823 even the DID register says e822, I have no idea where it gets the number from.
Also fun. lspci has an -A option to specify how it reads data. It would be interesting to compare what the kernel has (the default is one of the linux- methods) with the registers in the devices (the intel-conf1 method). If there is a difference then maybe the device still wasn't quite ready when the kernel booted.
Peter, do you happen to know something about the Virtual Channel capability?
I didn't, and I looked at the spec now but it seems uninteresting. It's a mechanism for multiple channels over a single link, with each VC possibly having different buffering and traffic class.
I found something that might be relevant in https://del.dog/raw/cbmemlog however, search it for Remap:
--8<-- https://del.dog/raw/cbmemlog#149 PCI: 00:1c.0: Disabling device PCI: 00:1c.0: check set enabled PCH: Remap PCIe function 1 to 0 PCI: 00:1c.1 [8086/1c12] enabled PCI: 00:1c.2: Disabling device PCH: Remap PCIe function 3 to 0 PCI: 00:1c.3 [8086/1c16] enabled PCH: Remap PCIe function 4 to 0 PCI: 00:1c.4 [8086/1c18] enabled -->8--
It looks strange that fn 1, 3 and 4 are all supposedly remapped to fn 0. I looked in the code, to me it looks like this will cause a mess in RPFN:
--8<-- southbridge/intel/bd82x6x/pch.c#229 /* Swap function numbers assigned to two PCIe Root Ports */ static void pch_pcie_function_swap(u8 old_fn, u8 new_fn) { u32 old_rpfn = new_rpfn;
printk(BIOS_DEBUG, "PCH: Remap PCIe function %d to %d\n", old_fn, new_fn);
new_rpfn &= ~(RPFN_FNMASK(old_fn) | RPFN_FNMASK(new_fn));
/* Old function set to new function and disabled */ new_rpfn |= RPFN_FNSET(old_fn, RPFN_FNGET(old_rpfn, new_fn)); new_rpfn |= RPFN_FNSET(new_fn, RPFN_FNGET(old_rpfn, old_fn)); } ... line 373: int fn;
/* * Check if there is a lower disabled port to swap with this * port in order to maintain linear order starting at zero. */ if (config->pcie_port_coalesce) { for (fn=0; fn < PCI_FUNC(dev->path.pci.devfn); fn++) { if (!(new_rpfn & RPFN_HIDE(fn))) continue;
/* Swap places with this function */ pch_pcie_function_swap( PCI_FUNC(dev->path.pci.devfn), fn); break; } } -->8--
But later in the log it doesn't look like RPFN has all functions on top of each other, but it also doesn't look really good:
--8<-- https://del.dog/raw/cbmemlog#162 PCH: PCIe map 1c.0 -> 1c.4 PCH: PCIe map 1c.1 -> 1c.0 PCH: PCIe map 1c.3 -> 1c.1 PCH: PCIe map 1c.4 -> 1c.3 -->8--
If the gaps are to be filled then I'd expect to see something like:
1c.1 -> 1c.0 1c.3 -> 1c.1 1c.4 -> 1c.2
The devicetree.cb seems not quite done, at least not for this mainboard:
--8<-- https://del.dog/raw/cbmemlog#175 PCI: Leftover static devices: PCI: 00:01.0 PCI: 00:16.1 PCI: 00:16.2 PCI: 00:16.3 PCI: 00:1c.4 PCI: 00:1c.2 PCI: 00:1c.5 PCI: 00:1c.7 PCI: Check your devicetree.cb. -->8--
But scanning the busses, actually both the Renesas xHCI/USB3 and the Ricoh are visible:
--8<-- https://del.dog/raw/cbmemlog#189 PCI: pci_scan_bus for bus 02 PCI: 02:00.0 [1912/0015] enabled Enabling Common Clock Configuration ASPM: Enabled L0s and L1 PCIe: Max_Payload_Size adjusted to 128 scan_bus: bus PCI: 00:1c.1 finished in 0 msecs PCI: 00:1c.3 scanning... PCI: pci_scan_bus for bus 03 PCI: 03:00.0 [1180/e822] enabled Enabling Common Clock Configuration ASPM: Enabled L0s and L1 PCIe: Max_Payload_Size adjusted to 128 Failed to enable LTR for dev = PCI: 03:00.0 scan_bus: bus PCI: 00:1c.3 finished in 0 msecs -->8--
But the Ricoh has the wrong DID, and while looking at https://del.dog/raw/sd-mmc-not-fw
I notice that the device looks more like a PCI device than a PCI Express one, with INTA routed to IRQ 16 instead of using MSI.
Sorry - I'm not able to suggest anything really concrete, but these are my observations.
//Peter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
By the way, since I have manually swapped the chip, I wanted to let you know that it is not directly mounted to the motherboard. It is attached to a smaller daughter board which might be the SD host controller itself. On Thu, Apr 9, 2020 at 10:20 AM Alesandar Metodiev < alesandarmetodiev@gmail.com> wrote:
I have booted with spkmodem enabled, but nothing has changed. The device is still not present.
On Thu, Apr 9, 2020 at 3:04 AM Peter Stuge <peter@stuge.se> wrote:
AreYouLoco? wrote:
I was wrong it isn't detected as SD/MMC it doesn't get detected at all. There is a separate device for SD/MMC present both on coreboot and stock.
Are you really sure? There is no such device in the vendor BIOS logs.
Alesandar Metodiev wrote:
I have tried to enable spkmodem, but now I can not boot at all. Maybe I did something wrong. No SeaBios, just a black screen.
No - just wait really long, 10-20 minutes, depending on console level. IIRC it's 1200 bps, around 100 byte per second, so the 110860 byte console log at https://del.dog/raw/cbmemlog would take 18 minutes. Reduce the console level with spkmodem.
Nico Huber wrote:
e822 vs. e823 smells like an upgrade to me. I suspect that we'd need to load some firmware on the 0.0 device. Or at least to configure something there so it switches 0.3 on.
Nico Huber wrote:
https://del.dog/raw/nnvvvxxx_root https://del.dog/raw/xxxx_root https://del.dog/raw/lspci_tv
Note, lspci calls it e823 even the DID register says e822, I have no idea where it gets the number from.
Also fun. lspci has an -A option to specify how it reads data. It would be interesting to compare what the kernel has (the default is one of the linux- methods) with the registers in the devices (the intel-conf1 method). If there is a difference then maybe the device still wasn't quite ready when the kernel booted.
Peter, do you happen to know something about the Virtual Channel capability?
I didn't, and I looked at the spec now but it seems uninteresting. It's a mechanism for multiple channels over a single link, with each VC possibly having different buffering and traffic class.
I found something that might be relevant in https://del.dog/raw/cbmemlog however, search it for Remap:
--8<-- https://del.dog/raw/cbmemlog#149 PCI: 00:1c.0: Disabling device PCI: 00:1c.0: check set enabled PCH: Remap PCIe function 1 to 0 PCI: 00:1c.1 [8086/1c12] enabled PCI: 00:1c.2: Disabling device PCH: Remap PCIe function 3 to 0 PCI: 00:1c.3 [8086/1c16] enabled PCH: Remap PCIe function 4 to 0 PCI: 00:1c.4 [8086/1c18] enabled -->8--
It looks strange that fn 1, 3 and 4 are all supposedly remapped to fn 0. I looked in the code, to me it looks like this will cause a mess in RPFN:
--8<-- southbridge/intel/bd82x6x/pch.c#229 /* Swap function numbers assigned to two PCIe Root Ports */ static void pch_pcie_function_swap(u8 old_fn, u8 new_fn) { u32 old_rpfn = new_rpfn;
printk(BIOS_DEBUG, "PCH: Remap PCIe function %d to %d\n", old_fn, new_fn);
new_rpfn &= ~(RPFN_FNMASK(old_fn) | RPFN_FNMASK(new_fn));
/* Old function set to new function and disabled */ new_rpfn |= RPFN_FNSET(old_fn, RPFN_FNGET(old_rpfn, new_fn)); new_rpfn |= RPFN_FNSET(new_fn, RPFN_FNGET(old_rpfn, old_fn)); } ... line 373: int fn;
/* * Check if there is a lower disabled port to swap with this * port in order to maintain linear order starting at zero. */ if (config->pcie_port_coalesce) { for (fn=0; fn < PCI_FUNC(dev->path.pci.devfn); fn++) { if (!(new_rpfn & RPFN_HIDE(fn))) continue;
/* Swap places with this function */ pch_pcie_function_swap( PCI_FUNC(dev->path.pci.devfn), fn); break; } } -->8--
But later in the log it doesn't look like RPFN has all functions on top of each other, but it also doesn't look really good:
--8<-- https://del.dog/raw/cbmemlog#162 PCH: PCIe map 1c.0 -> 1c.4 PCH: PCIe map 1c.1 -> 1c.0 PCH: PCIe map 1c.3 -> 1c.1 PCH: PCIe map 1c.4 -> 1c.3 -->8--
If the gaps are to be filled then I'd expect to see something like:
1c.1 -> 1c.0 1c.3 -> 1c.1 1c.4 -> 1c.2
The devicetree.cb seems not quite done, at least not for this mainboard:
--8<-- https://del.dog/raw/cbmemlog#175 PCI: Leftover static devices: PCI: 00:01.0 PCI: 00:16.1 PCI: 00:16.2 PCI: 00:16.3 PCI: 00:1c.4 PCI: 00:1c.2 PCI: 00:1c.5 PCI: 00:1c.7 PCI: Check your devicetree.cb. -->8--
But scanning the busses, actually both the Renesas xHCI/USB3 and the Ricoh are visible:
--8<-- https://del.dog/raw/cbmemlog#189 PCI: pci_scan_bus for bus 02 PCI: 02:00.0 [1912/0015] enabled Enabling Common Clock Configuration ASPM: Enabled L0s and L1 PCIe: Max_Payload_Size adjusted to 128 scan_bus: bus PCI: 00:1c.1 finished in 0 msecs PCI: 00:1c.3 scanning... PCI: pci_scan_bus for bus 03 PCI: 03:00.0 [1180/e822] enabled Enabling Common Clock Configuration ASPM: Enabled L0s and L1 PCIe: Max_Payload_Size adjusted to 128 Failed to enable LTR for dev = PCI: 03:00.0 scan_bus: bus PCI: 00:1c.3 finished in 0 msecs -->8--
But the Ricoh has the wrong DID, and while looking at https://del.dog/raw/sd-mmc-not-fw
I notice that the device looks more like a PCI device than a PCI Express one, with INTA routed to IRQ 16 instead of using MSI.
Sorry - I'm not able to suggest anything really concrete, but these are my observations.
//Peter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
The FireWire functionality is hanfled by SD/MMC Ricoh chip. The small daughter board is just wired to MMC Controller and its a secondary function of that chip (from what I got from thinkpad forum and IRC channel). On April 9, 2020 7:44:26 AM UTC, Alesandar Metodiev <alesandarmetodiev@gmail.com> wrote:
By the way, since I have manually swapped the chip, I wanted to let you know that it is not directly mounted to the motherboard. It is attached to a smaller daughter board which might be the SD host controller itself.
On Thu, Apr 9, 2020 at 10:20 AM Alesandar Metodiev < alesandarmetodiev@gmail.com> wrote:
I have booted with spkmodem enabled, but nothing has changed. The device is still not present.
On Thu, Apr 9, 2020 at 3:04 AM Peter Stuge <peter@stuge.se> wrote:
AreYouLoco? wrote:
I was wrong it isn't detected as SD/MMC it doesn't get detected at all. There is a separate device for SD/MMC present both on coreboot and stock.
Are you really sure? There is no such device in the vendor BIOS logs.
Alesandar Metodiev wrote:
I have tried to enable spkmodem, but now I can not boot at all. Maybe I did something wrong. No SeaBios, just a black screen.
No - just wait really long, 10-20 minutes, depending on console level. IIRC it's 1200 bps, around 100 byte per second, so the 110860 byte console log at https://del.dog/raw/cbmemlog would take 18 minutes. Reduce the console level with spkmodem.
Nico Huber wrote:
e822 vs. e823 smells like an upgrade to me. I suspect that we'd need to load some firmware on the 0.0 device. Or at least to configure something there so it switches 0.3 on.
Nico Huber wrote:
https://del.dog/raw/nnvvvxxx_root https://del.dog/raw/xxxx_root https://del.dog/raw/lspci_tv
Note, lspci calls it e823 even the DID register says e822, I have no idea where it gets the number from.
Also fun. lspci has an -A option to specify how it reads data. It would be interesting to compare what the kernel has (the default is one of the linux- methods) with the registers in the devices (the intel-conf1 method). If there is a difference then maybe the device still wasn't quite ready when the kernel booted.
Peter, do you happen to know something about the Virtual Channel capability?
I didn't, and I looked at the spec now but it seems uninteresting. It's a mechanism for multiple channels over a single link, with each VC possibly having different buffering and traffic class.
I found something that might be relevant in https://del.dog/raw/cbmemlog however, search it for Remap:
--8<-- https://del.dog/raw/cbmemlog#149 PCI: 00:1c.0: Disabling device PCI: 00:1c.0: check set enabled PCH: Remap PCIe function 1 to 0 PCI: 00:1c.1 [8086/1c12] enabled PCI: 00:1c.2: Disabling device PCH: Remap PCIe function 3 to 0 PCI: 00:1c.3 [8086/1c16] enabled PCH: Remap PCIe function 4 to 0 PCI: 00:1c.4 [8086/1c18] enabled -->8--
It looks strange that fn 1, 3 and 4 are all supposedly remapped to fn 0. I looked in the code, to me it looks like this will cause a mess in RPFN:
--8<-- southbridge/intel/bd82x6x/pch.c#229 /* Swap function numbers assigned to two PCIe Root Ports */ static void pch_pcie_function_swap(u8 old_fn, u8 new_fn) { u32 old_rpfn = new_rpfn;
printk(BIOS_DEBUG, "PCH: Remap PCIe function %d to %d\n", old_fn, new_fn);
new_rpfn &= ~(RPFN_FNMASK(old_fn) | RPFN_FNMASK(new_fn));
/* Old function set to new function and disabled */ new_rpfn |= RPFN_FNSET(old_fn, RPFN_FNGET(old_rpfn, new_fn)); new_rpfn |= RPFN_FNSET(new_fn, RPFN_FNGET(old_rpfn, old_fn)); } ... line 373: int fn;
/* * Check if there is a lower disabled port to swap with this * port in order to maintain linear order starting at zero. */ if (config->pcie_port_coalesce) { for (fn=0; fn < PCI_FUNC(dev->path.pci.devfn); fn++) { if (!(new_rpfn & RPFN_HIDE(fn))) continue;
/* Swap places with this function */ pch_pcie_function_swap(
PCI_FUNC(dev->path.pci.devfn),
fn); break; } } -->8--
But later in the log it doesn't look like RPFN has all functions on top of each other, but it also doesn't look really good:
--8<-- https://del.dog/raw/cbmemlog#162 PCH: PCIe map 1c.0 -> 1c.4 PCH: PCIe map 1c.1 -> 1c.0 PCH: PCIe map 1c.3 -> 1c.1 PCH: PCIe map 1c.4 -> 1c.3 -->8--
If the gaps are to be filled then I'd expect to see something like:
1c.1 -> 1c.0 1c.3 -> 1c.1 1c.4 -> 1c.2
The devicetree.cb seems not quite done, at least not for this mainboard:
--8<-- https://del.dog/raw/cbmemlog#175 PCI: Leftover static devices: PCI: 00:01.0 PCI: 00:16.1 PCI: 00:16.2 PCI: 00:16.3 PCI: 00:1c.4 PCI: 00:1c.2 PCI: 00:1c.5 PCI: 00:1c.7 PCI: Check your devicetree.cb. -->8--
But scanning the busses, actually both the Renesas xHCI/USB3 and the Ricoh are visible:
--8<-- https://del.dog/raw/cbmemlog#189 PCI: pci_scan_bus for bus 02 PCI: 02:00.0 [1912/0015] enabled Enabling Common Clock Configuration ASPM: Enabled L0s and L1 PCIe: Max_Payload_Size adjusted to 128 scan_bus: bus PCI: 00:1c.1 finished in 0 msecs PCI: 00:1c.3 scanning... PCI: pci_scan_bus for bus 03 PCI: 03:00.0 [1180/e822] enabled Enabling Common Clock Configuration ASPM: Enabled L0s and L1 PCIe: Max_Payload_Size adjusted to 128 Failed to enable LTR for dev = PCI: 03:00.0 scan_bus: bus PCI: 00:1c.3 finished in 0 msecs -->8--
But the Ricoh has the wrong DID, and while looking at https://del.dog/raw/sd-mmc-not-fw
I notice that the device looks more like a PCI device than a PCI Express one, with INTA routed to IRQ 16 instead of using MSI.
Sorry - I'm not able to suggest anything really concrete, but these are my observations.
//Peter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
I did try this (patch format) but it still didn't work. It adds correct pci_device_id and tries to enable it in devicetree.cb: From 3f60158b5b19400f2f705b41411cd9c88517328d Mon Sep 17 00:00:00 2001 From: AreYouLoco <areyouloco@paranoici.org> Date: Thu, 9 Apr 2020 17:17:18 +0200 Subject: [PATCH] Initial changes to support Ricoh Co Ltd R5C832 PCIe IEEE 1394 Controller --- src/drivers/ricoh/rce822/rce822.c | 4 ++-- src/mainboard/lenovo/t420/devicetree.cb | 3 ++- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/src/drivers/ricoh/rce822/rce822.c b/src/drivers/ricoh/rce822/rce822.c index fb714c2406..44c8538094 100644 --- a/src/drivers/ricoh/rce822/rce822.c +++ b/src/drivers/ricoh/rce822/rce822.c @@ -50,7 +50,7 @@ static struct device_operations rce822_ops = { .ops_pci = &lops_pci, }; -static const unsigned short pci_device_ids[] = { 0xe822, 0xe823, 0 }; +static const unsigned short pci_device_ids[] = { 0xe822, 0xe823, 0xe832, 0 }; static const struct pci_driver rce822 __pci_driver = { .ops = &rce822_ops, @@ -59,5 +59,5 @@ static const struct pci_driver rce822 __pci_driver = { }; struct chip_operations drivers_ricoh_rce822_ops = { - CHIP_NAME("RICOH RCE822") + CHIP_NAME("RICOH RCE822s") }; diff --git a/src/mainboard/lenovo/t420/devicetree.cb b/src/mainboard/lenovo/t420/devicetree.cb index 5ac9cf5a96..7d256f9df7 100644 --- a/src/mainboard/lenovo/t420/devicetree.cb +++ b/src/mainboard/lenovo/t420/devicetree.cb @@ -86,7 +86,8 @@ chip northbridge/intel/sandybridge chip drivers/ricoh/rce822 register "sdwppol" = "1" register "disable_mask" = "0x87" - device pci 00.0 on end + device pci 00.0 on end # Ricoh Co Ltd MMC/SD Host Controller + device pci 00.3 on end # Ricoh Co Ltd PCIe IEEE 1394 Controller end end # PCIe Port #5 (Ricoh SD & FW) device pci 1c.5 off end # PCIe Port #6 Intel Gigabit Ethernet PHY (not PCIe) -- 2.20.1 On 08.04.2020 20:02, Peter Stuge wrote:
Hi,
this is a fun one.
Alesandar Metodiev wrote:
AreYouLoco has already posted the output of `sudo lspci -vvxxx -s 0d:00.3` (when he was still running with the vendor firmware). Here it is. https://del.dog/raw/firewire_lspci
Comparing that with https://del.dog/raw/lspci_nntv shows that the chip presents itself differently on the very lowes level.
Factory BIOS: Ricoh Co Ltd PCIe SDXC/MMC Host Controller [1180:e823]
coreboot: Ricoh Co Ltd MMC/SD Host Controller [what:ids?]
If we look at the beginning of the config space dump in the coreboot case, we see:
00: 80 11 22 e8
These are little-endian vendor and device IDs, swap around to: [1180:e822]
The same chip seems to present itself differently depending on the firmware.
I've seen this before, and in fact I think it was the same kind of chip.
That time there was no coreboot involved, the ID seemed to change depending on whether the laptop was rebooted or actually powered off.
I guess that this device behaves differently depending on how and when it is initialized. I've also seen Atheros PCI devices come up as 0000:0000, which hints to a race condition where the PCI device just isn't ready when coreboot comes to speak to it.
Maybe try sprinkling random delays in the code. Or increase debug level. Or enable spkmodem. Something to make coreboot run slower. Then maybe that hardware works correctly.
//Peter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- AreYouLoco? GPG 2717 7338 4742 E034 F65F 7C83 C757 3088 E8B7 DEDA
Solved with the help of @icon__ at the IRC channel. The crucial part was to change disable_mask bit from 0x87 to 0x83 in src/mainboard/lenovo/t420/devicetree.cb: line 88. Thank you for your support @icon__! On April 9, 2020 3:21:42 PM UTC, AreYouLoco? <areyouloco@paranoici.org> wrote:
I did try this (patch format) but it still didn't work. It adds correct pci_device_id and tries to enable it in devicetree.cb:
From 3f60158b5b19400f2f705b41411cd9c88517328d Mon Sep 17 00:00:00 2001 From: AreYouLoco <areyouloco@paranoici.org> Date: Thu, 9 Apr 2020 17:17:18 +0200 Subject: [PATCH] Initial changes to support Ricoh Co Ltd R5C832 PCIe IEEE 1394 Controller
--- src/drivers/ricoh/rce822/rce822.c | 4 ++-- src/mainboard/lenovo/t420/devicetree.cb | 3 ++- 2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/drivers/ricoh/rce822/rce822.c b/src/drivers/ricoh/rce822/rce822.c index fb714c2406..44c8538094 100644 --- a/src/drivers/ricoh/rce822/rce822.c +++ b/src/drivers/ricoh/rce822/rce822.c @@ -50,7 +50,7 @@ static struct device_operations rce822_ops = { .ops_pci = &lops_pci, };
-static const unsigned short pci_device_ids[] = { 0xe822, 0xe823, 0 }; +static const unsigned short pci_device_ids[] = { 0xe822, 0xe823, 0xe832, 0 };
static const struct pci_driver rce822 __pci_driver = { .ops = &rce822_ops, @@ -59,5 +59,5 @@ static const struct pci_driver rce822 __pci_driver = { };
struct chip_operations drivers_ricoh_rce822_ops = { - CHIP_NAME("RICOH RCE822") + CHIP_NAME("RICOH RCE822s") }; diff --git a/src/mainboard/lenovo/t420/devicetree.cb b/src/mainboard/lenovo/t420/devicetree.cb index 5ac9cf5a96..7d256f9df7 100644 --- a/src/mainboard/lenovo/t420/devicetree.cb +++ b/src/mainboard/lenovo/t420/devicetree.cb @@ -86,7 +86,8 @@ chip northbridge/intel/sandybridge chip drivers/ricoh/rce822 register "sdwppol" = "1" register "disable_mask" = "0x87" - device pci 00.0 on end + device pci 00.0 on end # Ricoh Co Ltd MMC/SD Host Controller + device pci 00.3 on end # Ricoh Co Ltd PCIe IEEE 1394 Controller end end # PCIe Port #5 (Ricoh SD & FW) device pci 1c.5 off end # PCIe Port #6 Intel Gigabit Ethernet PHY (not PCIe)
Awesome! I was sure it has to do something with this lines. I can confirm that the device is listed properly now. It would be nice if we push that change to the mainline, but I believe that it was declared as 0x87 on a purpose. Probably because of the USB/modem version of the chip? We will have to detect this somehow, so other people won't have to be in the same situation. Any ideas? I will try to spend some time during the weekend. My laptop actually we came without FireWire/modem port, but a tinier version of the chip and a cover (without a hole) on the panel. On Thu, Apr 9, 2020 at 9:55 PM AreYouLoco? <areyouloco@paranoici.org> wrote:
Solved with the help of @icon__ at the IRC channel.
The crucial part was to change disable_mask bit from 0x87 to 0x83 in src/mainboard/lenovo/t420/devicetree.cb: line 88.
Thank you for your support @icon__!
On April 9, 2020 3:21:42 PM UTC, AreYouLoco? <areyouloco@paranoici.org> wrote:
I did try this (patch format) but it still didn't work. It adds correct pci_device_id and tries to enable it in devicetree.cb:
From 3f60158b5b19400f2f705b41411cd9c88517328d Mon Sep 17 00:00:00 2001 From: AreYouLoco <areyouloco@paranoici.org> Date: Thu, 9 Apr 2020 17:17:18 +0200 Subject: [PATCH] Initial changes to support Ricoh Co Ltd R5C832 PCIe IEEE 1394 Controller
--- src/drivers/ricoh/rce822/rce822.c | 4 ++-- src/mainboard/lenovo/t420/devicetree.cb | 3 ++- 2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/drivers/ricoh/rce822/rce822.c b/src/drivers/ricoh/rce822/rce822.c index fb714c2406..44c8538094 100644 --- a/src/drivers/ricoh/rce822/rce822.c +++ b/src/drivers/ricoh/rce822/rce822.c @@ -50,7 +50,7 @@ static struct device_operations rce822_ops = { .ops_pci = &lops_pci, };
-static const unsigned short pci_device_ids[] = { 0xe822, 0xe823, 0 }; +static const unsigned short pci_device_ids[] = { 0xe822, 0xe823, 0xe832, 0 };
static const struct pci_driver rce822 __pci_driver = { .ops = &rce822_ops, @@ -59,5 +59,5 @@ static const struct pci_driver rce822 __pci_driver = { };
struct chip_operations drivers_ricoh_rce822_ops = { - CHIP_NAME("RICOH RCE822") + CHIP_NAME("RICOH RCE822s") }; diff --git a/src/mainboard/lenovo/t420/devicetree.cb b/src/mainboard/lenovo/t420/devicetree.cb index 5ac9cf5a96..7d256f9df7 100644 --- a/src/mainboard/lenovo/t420/devicetree.cb +++ b/src/mainboard/lenovo/t420/devicetree.cb @@ -86,7 +86,8 @@ chip northbridge/intel/sandybridge chip drivers/ricoh/rce822 register "sdwppol" = "1" register "disable_mask" = "0x87" - device pci 00.0 on end + device pci 00.0 on end # Ricoh Co Ltd MMC/SD Host Controller + device pci 00.3 on end # Ricoh Co Ltd PCIe IEEE 1394 Controller end end # PCIe Port #5 (Ricoh SD & FW) device pci 1c.5 off end # PCIe Port #6 Intel Gigabit Ethernet PHY (not PCIe)
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
There are 3 models of that daughter board that I have seen on the internets: Usb+firewire, usb only, usb+rj11 modem. On April 10, 2020 6:52:13 AM UTC, Alesandar Metodiev <alesandarmetodiev@gmail.com> wrote:
Awesome! I was sure it has to do something with this lines. I can confirm that the device is listed properly now.
It would be nice if we push that change to the mainline, but I believe that it was declared as 0x87 on a purpose. Probably because of the USB/modem version of the chip? We will have to detect this somehow, so other people won't have to be in the same situation. Any ideas? I will try to spend some time during the weekend.
My laptop actually we came without FireWire/modem port, but a tinier version of the chip and a cover (without a hole) on the panel.
On Thu, Apr 9, 2020 at 9:55 PM AreYouLoco? <areyouloco@paranoici.org> wrote:
Solved with the help of @icon__ at the IRC channel.
The crucial part was to change disable_mask bit from 0x87 to 0x83 in src/mainboard/lenovo/t420/devicetree.cb: line 88.
Thank you for your support @icon__!
On April 9, 2020 3:21:42 PM UTC, AreYouLoco? <areyouloco@paranoici.org> wrote:
I did try this (patch format) but it still didn't work. It adds correct pci_device_id and tries to enable it in devicetree.cb:
From 3f60158b5b19400f2f705b41411cd9c88517328d Mon Sep 17 00:00:00 2001 From: AreYouLoco <areyouloco@paranoici.org> Date: Thu, 9 Apr 2020 17:17:18 +0200 Subject: [PATCH] Initial changes to support Ricoh Co Ltd R5C832 PCIe IEEE 1394 Controller
--- src/drivers/ricoh/rce822/rce822.c | 4 ++-- src/mainboard/lenovo/t420/devicetree.cb | 3 ++- 2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/drivers/ricoh/rce822/rce822.c b/src/drivers/ricoh/rce822/rce822.c index fb714c2406..44c8538094 100644 --- a/src/drivers/ricoh/rce822/rce822.c +++ b/src/drivers/ricoh/rce822/rce822.c @@ -50,7 +50,7 @@ static struct device_operations rce822_ops = { .ops_pci = &lops_pci, };
-static const unsigned short pci_device_ids[] = { 0xe822, 0xe823, 0 }; +static const unsigned short pci_device_ids[] = { 0xe822, 0xe823, 0xe832, 0 };
static const struct pci_driver rce822 __pci_driver = { .ops = &rce822_ops, @@ -59,5 +59,5 @@ static const struct pci_driver rce822 __pci_driver = { };
struct chip_operations drivers_ricoh_rce822_ops = { - CHIP_NAME("RICOH RCE822") + CHIP_NAME("RICOH RCE822s") }; diff --git a/src/mainboard/lenovo/t420/devicetree.cb b/src/mainboard/lenovo/t420/devicetree.cb index 5ac9cf5a96..7d256f9df7 100644 --- a/src/mainboard/lenovo/t420/devicetree.cb +++ b/src/mainboard/lenovo/t420/devicetree.cb @@ -86,7 +86,8 @@ chip northbridge/intel/sandybridge chip drivers/ricoh/rce822 register "sdwppol" = "1" register "disable_mask" = "0x87" - device pci 00.0 on end + device pci 00.0 on end # Ricoh Co Ltd MMC/SD Host Controller + device pci 00.3 on end # Ricoh Co Ltd PCIe IEEE 1394 Controller end end # PCIe Port #5 (Ricoh SD & FW) device pci 1c.5 off end # PCIe Port #6 Intel Gigabit Ethernet PHY (not PCIe)
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On 10.04.20 08:52, Alesandar Metodiev wrote:
It would be nice if we push that change to the mainline, but I believe that it was declared as 0x87 on a purpose.
I assume bit 2 simply turns the FW function on and off. People without a FW connector would simply see a spurious FW controller. But we can do better of course :)
Probably because of the USB/modem version of the chip? We will have to detect this somehow, so other people won't have to be in the same situation. Any ideas? I will try to spend some time during the weekend.
There is a 1394_DTCT line in the schematics. It goes straight to GPIO16 of the PCH. It has a pull-up on the mainboard, so if GPIO16 is low, we should have FW => 0x83 if it's high => 0x87. If you can switch between the daughter cards easily, please check GPIO values with inteltool (in util/inteltool/ of the coreboot tree) for each card. Nico
I got a new mobo because the old one got fried somehow^^ I could provide GPIO values from inteltool with both daughter boards. So someone could write better handling code. But how do I do that specifically? On 10.04.2020 11:53, Nico Huber wrote:
On 10.04.20 08:52, Alesandar Metodiev wrote:
It would be nice if we push that change to the mainline, but I believe that it was declared as 0x87 on a purpose.
I assume bit 2 simply turns the FW function on and off. People without a FW connector would simply see a spurious FW controller. But we can do better of course :)
Probably because of the USB/modem version of the chip? We will have to detect this somehow, so other people won't have to be in the same situation. Any ideas? I will try to spend some time during the weekend.
There is a 1394_DTCT line in the schematics. It goes straight to GPIO16 of the PCH. It has a pull-up on the mainboard, so if GPIO16 is low, we should have FW => 0x83 if it's high => 0x87.
If you can switch between the daughter cards easily, please check GPIO values with inteltool (in util/inteltool/ of the coreboot tree) for each card.
Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- AreYouLoco? GPG 2717 7338 4742 E034 F65F 7C83 C757 3088 E8B7 DEDA
I did dumped the GPIO with inteltool. Here are the results: https://del.dog/raw/fw_board https://del.dog/raw/usb_board On April 10, 2020 9:53:08 AM UTC, Nico Huber <nico.h@gmx.de> wrote:
On 10.04.20 08:52, Alesandar Metodiev wrote:
It would be nice if we push that change to the mainline, but I believe that it was declared as 0x87 on a purpose.
I assume bit 2 simply turns the FW function on and off. People without a FW connector would simply see a spurious FW controller. But we can do better of course :)
Probably because of the USB/modem version of the chip? We will have to detect this somehow, so other people won't have to be in the same situation. Any ideas? I will try to spend some time during the weekend.
There is a 1394_DTCT line in the schematics. It goes straight to GPIO16 of the PCH. It has a pull-up on the mainboard, so if GPIO16 is low, we should have FW => 0x83 if it's high => 0x87.
If you can switch between the daughter cards easily, please check GPIO values with inteltool (in util/inteltool/ of the coreboot tree) for each card.
Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Since https://del.dog paste service is no longer operating... I am re-sending the dumps to the mailing list as requested by Nico. On 5/18/20 21:52, AreYouLoco? wrote:
I did dumped the GPIO with inteltool. Here are the results: https://del.dog/raw/fw_board https://del.dog/raw/usb_board
On April 10, 2020 9:53:08 AM UTC, Nico Huber <nico.h@gmx.de> wrote:
On 10.04.20 08:52, Alesandar Metodiev wrote:
It would be nice if we push that change to the mainline, but I believe that it was declared as 0x87 on a purpose. I assume bit 2 simply turns the FW function on and off. People without a FW connector would simply see a spurious FW controller. But we can do better of course :)
Probably because of the USB/modem version of the chip? We will have to detect this somehow, so other people won't have to be in the same situation. Any ideas? I will try to spend some time during the weekend. There is a 1394_DTCT line in the schematics. It goes straight to GPIO16 of the PCH. It has a pull-up on the mainboard, so if GPIO16 is low, we should have FW => 0x83 if it's high => 0x87.
If you can switch between the daughter cards easily, please check GPIO values with inteltool (in util/inteltool/ of the coreboot tree) for each card.
Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On 2021-12-15 06:44, AreYouLoco? wrote:
Since https://del.dog paste service is no longer operating...
I am re-sending the dumps to the mailing list as requested by Nico.
I took a look at those inteltool dumps, and they don't seem to be consistent with what the schematic shows. As Nico mentioned before, the 1394_DTCT line goes into GPIO16, according the schematic. However, the logs indicate that GPIO16 is configured for its native function, and not a GPIO. The existing coreboot code for the T420 also configures it for its native function. Looking for pins configured as input GPIOs where the value changes between the 3 dumps yields 2 candidates: 54 and 71. Both of those pins read 0 with the Firewire board, and read 1 with no board/usb only. According to the schematic (or at least the one I found) GPIO54 is connected to BDC_PRESENCE, and GPIO71 is not used and pulled high through a resistor. Out of those 2 GPIO71 seems more likely, but we'd need to find a way to confirm that to be sure. Cheers, Nicholas
participants (6)
-
Alesandar Metodiev -
AreYouLoco? -
Nicholas Chin -
Nico Huber -
Paul Menzel -
Peter Stuge