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
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 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
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:
>>
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
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
wrote:
>Awesome! I was sure it has to do something with this lines. I can
>confirm
>that the device is listed properly now.
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
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? wrote:
>I did try this (patch format) but
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
Date: Thu, 9 Apr 2020 17:17:18 +0200
Subject: [PATCH] Initial changes to support
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
wrote:
>By the way, since I
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 <
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 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
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
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
>>
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
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
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:
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
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
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
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 wrote:
> Hi,
>
> On 08.04.20 13:45, AreYouLoco? wrote:
> > I can
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
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
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
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
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 wrote:
>Dear AreYouLoco,
>
>
>Am 08.04.20 um
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
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.
27 matches
Mail list logo
