Heads on T530

[swaybar]

Has anyone successfully built heads for the T530?

[tlaurion]

@swaybar not that im aware of but should not be too much complicated. Duplicate coreboot config of t430 to t530.

[eganonoa]

@swaybar not that im aware of but should not be too much complicated. Duplicate coreboot config of t430 to t530.

I just did this for the t520 using the Master but with coreboot 4.13 and it was incredibly easy. I just took the relevant t420 board (hotp maximized) and the corresponding coreboot config and changed references to t420 to t520. Everything built perfectly. t530 should be just as simple.

[tlaurion]

@swaybar With t430 board equivalent being the base for t530 instead of t420 for t520.

@eganonoa please share through PR your t520 board + coreboot config. Everybody loves tested board configs!

[eganonoa]

@swaybar With t430 board equivalent being the base for t530 instead of t420 for t520.

@eganonoa please share through PR your t520 board + coreboot config. Everybody loves tested board configs!

I will do!

I'm working on the t530 also. That one builds in much the same way. But I've hit a major snag in testing it. The t530 I have access to apparently reads as having two 4mb chips instead of a 4mb and an 8mb. The chip that is meant to be the 8mb one reads as a macronix MX25L3205D. Everything I've read indicates that it should rather be an MX25L6406E (8MB). Additionally, when reading flashrom says "block protection could not be disabled". Any thoughts on what I might be able to do here? I'm aiming for an hotp verification version of heads.

[tlaurion]

MX25L3205D Is 4mb from data sheet? This is the top chip? The bottom chip?

@eganonoa You obtained those readings with an external reprogrammer? Normally, you should be able to read the content externally.

What is the exact output it is giving for both chips?

[eganonoa]

MX25L3205D Is 4mb from data sheet? This is the top chip? The bottom chip?

@eganonoa You obtained those readings with an external reprogrammer? Normally, you should be able to read the content externally.

What is the exact output it is giving for both chips?

Yes this was with an external programmer. The exact output was that it was a Macronix "MX25L3205D/MX25L3205D" (4096kb). It could read it but could only read as a 4mb bottom chip and said "block protection could not be disabled" while doing it. Not much more than that.

I was able to successfully build and run t530-flash, but I'm hesitant to run flash.sh.

[tlaurion]

Really confused. https://doc.coreboot.org/mainboard/lenovo/Ivy_Bridge_series.html

[tlaurion]

https://doc.coreboot.org/mainboard/lenovo/ivb_internal_flashing.html?highlight=t530

Which Lenovo proprietary firmware version are you coming from?

Which flashrom version? I cannot find information on t530 being 8mb total spi flash combined...

[eganonoa]

Really confused. https://doc.coreboot.org/mainboard/lenovo/Ivy_Bridge_series.html

Yep, it is super-confusing. I cannot find anywhere any mention of 2 x 4mb chips. I'm using flashrom on my raspberry pi. This has to-date successfully read and flashed coreboot/heads on something like 17 laptops and I have no doubt it's still working fine, including the clip. Have tried to read it, and re-seat the clip countless times, all still the same. I'm using the BIOS 2.76 (G4ETB6WW) EC 1.13 (G4HT39WW), the last ones before rollback protection was added. And in the Bios there isn't anything like computrace or a bios password enabled. I reckon I'm either looking at a problematic 8mb chip or this laptop was somehow given two 4mb chips in the factory by mistake. I'll figure it out, or may just get a used motherboard to swap in even through the laptop works great in all ways but this.

Good news is that it wasn't too difficult to get t530-flash or t530-hotp-maximized to build on coreboot 4.13. Just needed to copy t430 board, initrid/bin and coreboot config, change everything from t430 to t530, in the coreboot change LENOVO_THINKPAD_T530 to LENOVO_T530 and CONFIG_MEASURED_BOOT to CONFIG_TPM_MEASURED_BOOT. And t530_flash definitely works. Now, of course, I'll need to find a way to test the real rom!

[pgera]

T/W 530 do not have a /cs pullup. So both chips can be selected with some probability when pch is powered down. So you should hook the other chip's CS to VCC with a resistor.

Source: https://coreboot.coreboot.narkive.com/tivMH3VG/t520-vs-t530 Also: https://old.reddit.com/r/coreboot/comments/dpjm6l/problem_with_w530_and_ch341a_programmer/

[pgera]

These are the possible chip part numbers: 8 MB: MX25L6406EM2I-12G W25Q64CVSSIG N25Q064A13ESE40F

4 MB: MX25L3206EM2I-12G W25Q32BVSSIG N25Q032A13ESE40F

[eganonoa]

T/W 530 do not have a /cs pullup. So both chips can be selected with some probability when pch is powered down. So you should hook the other chip's CS to VCC with a resistor.

Source: https://coreboot.coreboot.narkive.com/tivMH3VG/t520-vs-t530 Also: https://old.reddit.com/r/coreboot/comments/dpjm6l/problem_with_w530_and_ch341a_programmer/

@pgera. Thanks. I read about that option. Since I use a pomona clip and not individual clips I assume I'd need to buy some new stuff to make this work? Have you done this before, any guidance you can give would be most appreciated.

Ultimately I definitely have an "unhappy" bottom (SPI1) chip. It is indeed, on its label, an MX25L6406E but reads not as that, but rather as a 4mb MX25L3205, and flashrom says that "block protection could not be disabled" when try to read it. Yet, after flashing t530-flash, I can run flashrom and it correctly identifies that there is 12MB total space between the two chips. My hope is to flash that 12MB from software in recovery mode, but I'm not having any success with that.

[eganonoa]

https://doc.coreboot.org/mainboard/lenovo/ivb_internal_flashing.html?highlight=t530

Which Lenovo proprietary firmware version are you coming from?

Which flashrom version? I cannot find information on t530 being 8mb total spi flash combined...

@tlaurion: it definitely is 12MB combined. When I run t530-flash I can run flashrom and it sees 12MB total spi flash space. Right now, I am having difficulty in successfully converting from t530-flash to t530-hotp-maximized, once I run flash.sh in Recovery Mode the system cannot post. And I'm a little trapped in trying to figure out the reason because there are three possibilities as I see it:

1. You cannot move from t530-flash straight to a maximized board: I know that I've been tripped up in the past with x230's by trying to go from non-maximized to maximized without a physical flash. Could this be the issue?

2. The t530 build isn't good: I would be surprised if this was the case. t530-flash works and I'm using much the same model (i.e. CONFIG_LENOVO_T530; but also CONFIG_TPM_MEASURED_BOOT). But it is surely a possibility.

3. The block protection on and general strangeness with the bottom SPI1 chip is preventing a full 12MB flash: I am sharing screenshots of the results of running flash.sh after flashing t530-flash. You will see that it sees a 12MB chip and the flash is verified, but that it also highlights that some regions are write-protected. Does this look to you like a successful flash?

Right now, my hopes are on the issue merely being something to do with jumping from t530-flash to a maximized board, but I'm not sure that that's the case and would value your input there. I would test immediately with a non-maximized board but I'm struggling to get those to build because of size issues. So before wasting my time with trying to get non-maximized boards to work, I figures I'd seek your thoughts on all this.

[pgera]

If you are still on the original lenovo bios (or can go back to it), you can try the wake on lan approach. That should be reliable. Details: https://old.reddit.com/r/coreboot/comments/9m9pna/lenovo_t530_issues_with_flashrom_and_pi/

For the resistor method, yes, you will need a way to connect the other chip's CS separately through a resistor to VCC. You will likely need an individual hook type device like the one listed here: https://github.com/merge/skulls/commit/57baa48cba72c4127f336d85da23d788c617ceed#diff-b218cfc34bc4ee89ac3e765bfb4cded4914fd757ee71bf03242c413aa374b28b

[pgera]

You can also try a different programmer, power supply etc. if you have them available.

[tlaurion]

https://doc.coreboot.org/mainboard/lenovo/ivb_internal_flashing.html?highlight=t530 Which Lenovo proprietary firmware version are you coming from? Which flashrom version? I cannot find information on t530 being 8mb total spi flash combined...

@tlaurion: it definitely is 12MB combined. When I run t530-flash I can run flashrom and it sees 12MB total spi flash space. Right now, I am having difficulty in successfully converting from t530-flash to t530-hotp-maximized, once I run flash.sh in Recovery Mode the system cannot post. And I'm a little trapped in trying to figure out the reason because there are three possibilities as I see it:

1. You cannot move from t530-flash straight to a maximized board: I know that I've been tripped up in the past with x230's by trying to go from non-maximized to maximized without a physical flash. Could this be the issue?

The laptop not booting after moving from a legacy board config to a maximized board config is due to flashrom not properly validating Intel Firmware Descriptor (IFD) and permitting to flash a BIOS region (--ifd --image bios) from the flash.sh script, taking its flashrom options from the legacy board's config and flashing a bigger BIOS region (11.5mb) that the IFD region defined (7Mb).

Consequently, the maximized BIOS region that is being flashed internally doesn't respect the available BIOS region space, and flashed 11.5Mb over the 7Mb region that is truly available since neither ME has been neutered (removing all the modules but BUP and ROMP, freeing 3.5Mb of space), neither the IFD has been adjusted to specify that the BIOS region is now of 11.5Mb and ME 98Kb. The BIOS region is consequently not starting nor ending where expected resulting in a brick. (Why flashrom permits to flash larger BIOS region that possible internally is still mystery to me?).

I repeat here, it is not possible to flash a maximized build over a legacy board config, unless the IFD is unlocked, originally OR flashing the 8Mb bottom image to the bottom flash chip, which contains the modified and unlocked IFD, neutered ME and the 3.5Mb BIOS region which spans over the 4Mb top flash bios image.

2. The t530 build isn't good: I would be surprised if this was the case. t530-flash works and I'm using much the same model (i.e. CONFIG_LENOVO_T530; but also CONFIG_TPM_MEASURED_BOOT). But it is surely a possibility.

Considering you can flash internally, as coreboot documentation states and confirmed with opaque chip detected being 12Mb, you could continue the legacy board path, and create a t530-hotp-verification board config (duplicate t430-hotp-verification, copy its coreboot config and start from there). As you can see comparing maximized and non-maximized coreboot configuration, CBFS defined regions (BIOS regions space) are different.

3. The block protection on and general strangeness with the bottom SPI1 chip is preventing a full 12MB flash: I am sharing screenshots of the results of running flash.sh after flashing t530-flash. You will see that it sees a 12MB chip and the flash is verified, but that it also highlights that some regions are write-protected. Does this look to you like a successful flash?

It does in theory. In practice, you overwritten part of the 8mb chip that should not be, resulting in a brick. You should revert to original bios and test other methods so you can read/write directly to the 8mb flash chip. Not sure what happened there. But from where you are, flashing from console a t530-hotp-verification build, internally, would use the whole IFD (locked) 7MB BIOS region and flash it with a defined in ROM BIOS region (baked) that is valid.

Right now, my hopes are on the issue merely being something to do with jumping from t530-flash to a maximized board, but I'm not sure that that's the case and would value your input there. I would test immediately with a non-maximized board but I'm struggling to get those to build because of size issues. So before wasting my time with trying to get non-maximized boards to work, I figures I'd seek your thoughts on all this.

[tlaurion]

@pgera You input in really appreciated.

When I read those documentation, mostly from doc.cooreboot.org for the T/W 530, I got that this was a trick to not disassemble the laptop completely.

I didn't understood that it was a requirement to hook the Bottom chip's CS to Top VCC to be able to read/write to the Bottom SPI chip. Is that what you are saying? Those instructions are still confusing to me, and quite not understand why those instructions are not clearer upstream; which explains why not so much users are flashing those boards with confidence.

[pgera]

Yes, the documentation is not very clear. The documentation is about a trick, but that's like an optimisation and not that helpful for new users. The main issue is that chips are not detected reliably due to the floating /CS. I learnt about it from nico on irc. So, in order to detect the chip reliably, the other chip's /CS needs to be connected to VCC with a pull-up resistor.

[eganonoa]

https://doc.coreboot.org/mainboard/lenovo/ivb_internal_flashing.html?highlight=t530 Which Lenovo proprietary firmware version are you coming from? Which flashrom version? I cannot find information on t530 being 8mb total spi flash combined...

@tlaurion: it definitely is 12MB combined. When I run t530-flash I can run flashrom and it sees 12MB total spi flash space. Right now, I am having difficulty in successfully converting from t530-flash to t530-hotp-maximized, once I run flash.sh in Recovery Mode the system cannot post. And I'm a little trapped in trying to figure out the reason because there are three possibilities as I see it: 1. You cannot move from t530-flash straight to a maximized board: I know that I've been tripped up in the past with x230's by trying to go from non-maximized to maximized without a physical flash. Could this be the issue?

The laptop not booting after moving from a legacy board config to a maximized board config is due to flashrom not properly validating Intel Firmware Descriptor (IFD) and permitting to flash a BIOS region (--ifd --image bios) from the flash.sh script, taking its flashrom options from the legacy board's config and flashing a bigger BIOS region (11.5mb) that the IFD region defined (7Mb).

Consequently, the maximized BIOS region that is being flashed internally doesn't respect the available BIOS region space, and flashed 11.5Mb over the 7Mb region that is truly available since neither ME has been neutered (removing all the modules but BUP and ROMP, freeing 3.5Mb of space), given to the BIOS region through modified IFD, which reduces ME region correctly and expends BIOS region accordingly.

I repeat here, it is not possible to flash a maximized build over a legacy board config, unless the IFD is unlocked, originally OR flashing the 8Mb bottom image to the bottom flash chip, which contains the modified and unlocked IFD, neutered ME and the 3.5Mb BIOS region which spans over the 4Mb top flash bios image.

2. The t530 build isn't good: I would be surprised if this was the case. t530-flash works and I'm using much the same model (i.e. CONFIG_LENOVO_T530; but also CONFIG_TPM_MEASURED_BOOT). But it is surely a possibility.

Considering you can flash internally, as coreboot documentation states and confirmed with opaque chip detected being 12Mb, you could continue the legacy board path, and create a t530-hotp-verification board config (duplicate t430-hotp-verification, copy its coreboot config and start from there). As you can see comparing maximized and non-maximized coreboot configuration, CBFS defined regions (BIOS regions space) are different.

3. The block protection on and general strangeness with the bottom SPI1 chip is preventing a full 12MB flash: I am sharing screenshots of the results of running flash.sh after flashing t530-flash. You will see that it sees a 12MB chip and the flash is verified, but that it also highlights that some regions are write-protected. Does this look to you like a successful flash?

It does in theory. In practice, you overwritten part of the 8mb chip that should not be, resulting in a brick. You should revert to original bios and test other methods so you can read/write directly to the 8mb flash chip. Not sure what happened there. But from where you are, flashing from console a t530-hotp-verification build, internally, would use the whole IFD (locked) 7MB BIOS region and flash it with a defined in ROM BIOS region (baked) that is valid.

Right now, my hopes are on the issue merely being something to do with jumping from t530-flash to a maximized board, but I'm not sure that that's the case and would value your input there. I would test immediately with a non-maximized board but I'm struggling to get those to build because of size issues. So before wasting my time with trying to get non-maximized boards to work, I figures I'd seek your thoughts on all this.

@tlaurion This is massively helpful. Thank you. I thought that that was the case we transition to a maximized board and it is good to know that this is the issue. Unlocking the ifd region is going to be a challenge given the weirdness with the bottom chip. But @pgera may have provided the solution.

I will also play around with the non-maximized board to get it right. The upside being once done I will have done all the boards for the t530, albeit I won't be able to test the maximized ones until I can find a way to unlock the IFD region.

Interestingly, the computer didn't completely brick after running the internal flash. I can just reflash either the original 4mb bios or t530 flash and be sorted, which at least allows me to experiment! Definitely something is up with that 8mb chip, despite the computer being fully functional even after messing around with it.

I'll keep persevering and will add a PR for t530 (once done) and t520.

[eganonoa]

If you are still on the original lenovo bios (or can go back to it), you can try the wake on lan approach. That should be reliable. Details: https://old.reddit.com/r/coreboot/comments/9m9pna/lenovo_t530_issues_with_flashrom_and_pi/

For the resistor method, yes, you will need a way to connect the other chip's CS separately through a resistor to VCC. You will likely need an individual hook type device like the one listed here: merge/skulls@57baa48#diff-b218cfc34bc4ee89ac3e765bfb4cded4914fd757ee71bf03242c413aa374b28b

@pgera Really helpful. I'm going to give it a bash. Thanks very much for your help here.

[eganonoa]

Yes, the documentation is not very clear. The documentation is about a trick, but that's like an optimisation and not that helpful for new users. The main issue is that chips are not detected reliably due to the floating /CS. I learnt about it from nico on irc. So, in order to detect the chip reliably, the other chip's /CS needs to be connected to VCC with a pull-up resistor.

@pgera This is so interesting. I thought I had a dodgy chip. But from what youve described it sounds normal! You've saved me a ton of time here.

[pgera]

Do you have a known-working 12 MB image ? If you do, I think the wake on lan method would be the safest approach to flash. Remember that in wake on lan, you DO NOT connect VCC. See ch1p's comments in the reddit thread above.

[tlaurion]

Yes, the documentation is not very clear. The documentation is about a trick, but that's like an optimisation and not that helpful for new users. The main issue is that chips are not detected reliably due to the floating /CS. I learnt about it from nico on irc. So, in order to detect the chip reliably, the other chip's /CS needs to be connected to VCC with a pull-up resistor.

@pgera there is no complete guide floating around on how to build such gadget for newcomers?

[tlaurion]

Do you have a known-working 12 MB image ? If you do, I think the wake on lan method would be the safest approach to flash. Remember that in wake on lan, you DO NOT connect VCC. See ch1p's comments in the reddit thread above.

@pgera Definitely, upstream documentation would benefit from that input. As for the WOL method, i'm not myself really clear on the whys the bottom 8Mb chip would be detected correctly while doing that.

[pgera]

Not that I know of. The hooks I linked above from the skulls repository should work though. There is also one additional optimisation possible with T530. There is a solder pad CN100 on the board that can be used for soldering wires which can that give you easier access to the SPI chips without opening the whole thing.

[pgera]

With WoL, the PCH would be powered on which I think would solve the issue. At least that's what I remember.

[tlaurion]

Crossposted https://github.com/merge/skulls/issues/197 which have the same goal in mind.

[pgera]

I am using vanilla coreboot on my T530. @eganonoa if you need a coreboot rom, I can build one for you if you give me your gbe.bin. You can also build coreboot yourself. The latest release works fine.

[eganonoa]

Do you have a known-working 12 MB image ? If you do, I think the wake on lan method would be the safest approach to flash. Remember that in wake on lan, you DO NOT connect VCC. See ch1p's comments in the reddit thread above.

Thank you. I don't yet have a known working image as I'm just now trying to get that sorted here. I'm pretty sure what I have will work, but not 100% It needs testing. One thing that I don't quite understand is how the WAL method flashes all 12MB. Am I still only connected to one chip?

[eganonoa]

I am using vanilla coreboot on my T530. @eganonoa if you need a coreboot rom, I can build one for you if you give me your gbe.bin. You can also build coreboot yourself. The latest release works fine.

That would be really useful. I appreciate that. I can build myself, but I won't know if it's working until I flash it. The point made in that reddit thread is a good one "Remember that you have one shot to write to the chips, as there's no WoL feature if you brick the laptop or if you flash bad coreboot build that doesn't boot, so double-check and triple-check everything." No being able to get a good read on that 8MB chip makes it risky for sure!

[tlaurion]

Not sure what that would change and what would be desired outcome. Maximized builds include minimized ME, IGB with fixed MAC and proper IFD for all xx30 series, IF IT CAN BE FLASHED WHOLLY EXTERNALLY.

[pgera]

@eganonoa For the WoL method, you will still select the chips individually, just that you should get a stable reading.

Yeah, building coreboot on its own is not too different from the maximized build here. The only benefit of having the coreboot rom would be to have one good copy if you are going back and forth between builds. But in order to go back and forth, you'll nead a reliable way of flashing if anything doesn't boot.

[tlaurion]

@eganonoa let's go back to the basics. Which external reprrogrammer you are using?

[eganonoa]

Not sure what that would change and what would be desired outcome. Maximized builds include minimized ME, IGB with fixed MAC and proper IFD for all xx30 series, IF IT CAN BE FLASHED WHOLLY EXTERNALLY.

Not sure what that would change and what would be desired outcome. Maximized builds include minimized ME, IGB with fixed MAC and proper IFD for all xx30 series, IF IT CAN BE FLASHED WHOLLY EXTERNALLY.

Only one thing: knowing that it's good. In the reddit post there is an important point re the WOL approach, that it is a one-time only deal. So the goal would be to flash a known working coreboot rather than rolling the dice with an unteated one. I'm almost certain mine from Heads is fine, and indeed I'd be confident that any coreboot build I'd make would be too. But you never know...

[eganonoa]

@eganonoa For the WoL method, you will still select the chips individually, just that you should get a stable reading.

Yeah, building coreboot on its own is not too different from the maximized build here. The only benefit of having the coreboot rom would be to have one good copy if you are going back and forth between builds. But in order to go back and forth, you'll nead a reliable way of flashing if anything doesn't boot.

Yep exactly.

[eganonoa]

@eganonoa let's go back to the basics. Which external reprrogrammer you are using?

RPI with a Pomona clip. I read lots of people pushing for the ch431a, but frankly I don't see it. Have had nothing but good experience with the RPI over multiple devices, but have wasted time and money on ch431a's never getting one with a stable 3.3V without having to resort to the silly hack people resort to. My preference is to stay with what's familiar. But if someone can point me to a ch431a on sale in Europe that is known to absolutely have 3.3v I would definitely roll that dice one more time.

T530's definitely present an interesting issue with all this. Contrast with the T520 is amazing: that was the easiest libreboot/coreboot/heads experience I've ever had (don't even need to peel back the protective film like in the x230) and the prices are excellent (in contrast to x230's which some 50% higher today than they were when I decked out my team with x230-heads in 2019).

[pgera]

Well, you should go back to the stock bios until you figure out a reliable way to read and write with a hardware programmer because you'll need that for any experimentation.

[eganonoa]

Well, you should go back to the stock bios until you figure out a reliable way to read and write with a hardware programmer because you'll need that for any experimentation.

Yep. I already have. This is all a bit of an experiment to see if there is a good alternative to the x230s for heads as we use it exclusively across our team. x230 prices are terrible now in Europe (some combo of all the big corporate selloff apparently being done in or before 2019, the covid crisis, and Nitrokey entering the market have raised the prices some 50% over what we got them at two years ago, whereas everything else is still pretty good). But the x230's aren't winning the Covid wars: thermals and fan noise with constant videoconferencing, small screens for those working from home without wanting an external monitor). T430's are pretty good but the screens are horrible and I don't fancy the mod. The sweat spot seems to be with the t520's and t530's with the 20's currently winning with ease of flashing!

[eganonoa]

@tlaurion @pgera I can confirm that the Wake on Land method works to properly read and write to the 8mb chip on the t530 and that I have a working t530-hotp-maximized board and coreboot config, as well as a t530-flash. I will raise the relevant t520 and t530 PR's this weekend (as soon as I can figure out how to do that!).

@pgera I can't overemphasize how important your intervention was. I'd done a bunch of searching around and while I'd found that you could use the 8mb chip to get to the 4mb chip, I had not once come across the fact that the 8mb chip isn't straightforward to read and was certain I had a faulty chip. I was close to pulling the trigger on a replacement motherboard. So thank you. Obviously you @tlaurion also!

Now, to figure out the coreboot build re the dGPU as the t530 I have has the NVIDIA GPU. I've done this before with a t440p and vanilla coreboot but never with a Heads built coreboot. Should be straightforward I imagine.

[eganonoa]

@tlaurion Done. Have created a PR for t520-maximized, t520-hotp-maximized, t530-flash, t530-maximized and t530-hotp-maximized, all built using Coreboot 4.13 and tested as working. @swaybar see https://github.com/osresearch/heads/pull/1059.

[eganonoa]

@tlaurion @pgera @swaybar, a couple of updates from my side here.

1. Wanted to confirm here that #1059 has now been tested on T530 boards for both dGPU and non-dGPU models and is working. The initial test was on a T530 with the dGPU. As such the T530 board does not appear to be impacted by the issue (see #1057) that appears to exist for the T430 with dGPU. [Edit 5 Dec 2021, this PR has been split into three, one each per board: #1073 #1072 #1071)
2. With regards to the difficulty in reading and writing to the 8MB bottom chip, I can confirm that the issue is not specific to the Raspberry Pi, but also impacts the ch431a. However, the issue only appears to exist if the CMOS battery is unplugged. When the CMOS battery is plugged in the board appears to get just enough additional power to enable a clean reading of the chip, much as happens with using the Wake-on-Lan method. This has been true both of the T530 (with or without dGPU) and for the W530, which I have now successfully built and flashed.

[tlaurion]

When the CMOS battery is plugged in the board appears to get just enough additional power to enable a clean reading of the chip, much as happens with using the Wake-on-Lan method. This has been true both of the T530 (with or without dGPU) and for the W530, which I have now successfully built and flashed.

That is definitely documentation material and would require a heads-wiki entry @eganonoa !!!!

[tlaurion]

As such the T530 board does not appear to be impacted by the issue (see Can't get heads to boot on t430 #1057) that appears to exist for the T430 with dGPU.

For clarity: the errors reported on the t430 were without dGPU (iGPU only) and reported by multiple people.

[tlaurion]

@swaybar can we close since t530 is now upstream for dgpu igpu boards? Please tag me to reopen.

[tlaurion]

There is also one additional optimisation possible with T530. There is a solder pad CN100 on the board that can be used for soldering wires which can that give you easier access to the SPI chips without opening the whole thing. SRC: https://github.com/osresearch/heads/issues/996#issuecomment-974225278

@pgera any references? Same applies to other boards like w530?

Edit: https://github.com/hamishcoleman/thinkpad-ec/issues/70#issuecomment-374564806 seems to be where that discussion originally happened