streamline first-time flashing about skulls

[nemanjan00]

2. pawn seems to dump some more data after 12MB.
   First 12MB is the same as from flashrom. (on unlocker x230)

[nemanjan00]

I am more than ok with doing all of that, in 2 weeks when my exams pass. I am just noting it here to help engeneer it better... I will document couple of ways of flashing it.

…

On Sun, Apr 15, 2018, 08:49 Martin Kepplinger ***@***.***> wrote: Right now the script is even called "flashrom_rpi_write", so in that case it should be fine :) But in case we rename it to "flashrom_write" and add a flasher-option, I'd invent a new option that translates to the actual flashrom parameters. I don't want people to worry about setting "spispeed" for example: -f rpi would set what we currently have. What do you think? I won't myself directly add a flashrom command I never tesed though: So *you* would have to add your hardware-option to the script, so people know who they can ask. (Have you flashed multiple x230 devices successfully?) And you'd have to add a "flashing example" section in README. Don't underestimate that work :) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAbWlz62VOBD7XvwokzKZVGJ6U6QENsXks5tou2BgaJpZM4TTT2V> .

[merge]

first Test:

• pawn reads 16M
• flashrom -p internal -r reads 12M
• dd if=pawn_read.rom of=bios_image_full_12m bs=1M skip=0 count=12 produces what flashrom reads.

Also I tested on an already unlocked flash image.

[nemanjan00]

This is result when I try to read rom on locked T430.

[merge]

ok. are you sure you try to read "online"? I think we can only use flashrom -p internal here...

[nemanjan00]

Figured it out and changed screenshot...

[nemanjan00]

pawn on locked T430:

I can not reboot that computer right now so I can not tell if changing kernel params changes anything...

[merge]

ok. you don't seem to boot with iomem=relaxed kernel cmdline parameter (for example set in GRUB, if you use that). Without that it cannot work.

[nemanjan00]

I can not reboot that computer right now, it is in use...

[nemanjan00]

It might not be that bad idea to also let people specify different flasher...

I for example do not use RPi...

[merge]

Right now the script is even called "flashrom_rpi_write", so in that case it should be fine :)

But in case we rename it to "flashrom_write" and add a flasher-option, I'd invent a new option that translates to the actual flashrom parameters. I don't want people to worry about setting "spispeed" for example: -f rpi would set what we currently have. What do you think? I won't myself directly add a flashrom command I never tesed though:

So you would have to add your hardware-option to the script, so people know who they can ask. (Have you flashed multiple x230 devices successfully?) And you'd have to add a "flashing example" section in README. Don't underestimate that work :)

[merge]

I'll be able to test internal-reading on a locked flash image next week, hopefully.

If that won't work, we should add a script that reads, pulls coreboot (for ifdtool) and optionally me_cleaner and applies everything and flashes back the result, all-in-one.

For this, we'd need our flashrom wrapper read-only mode too. Maybe I should simply call the script flashrom_wrapper.sh.

[merge]

Test on a fresh X230, never flashed before, original Lenovo BIOS and everything:

• flashrom -p internal doesn't read the locked regions
  • I have seen discussions upstream though on this topic, and the HEADS project seems to have patches... I haven't further tested. Support may or may not come someday. for writing too
• pawn does read the 16M without an issue!
  • As mentioned above, I simply split out the 4M and 8M with dd
  • I then read the chips seperately, externally (RPi in my case) and compared:
    the 8M differ. substantually. pawn clearly reads less. probably also no locked region.

For my part, I won't further dig in about why this is, and how, because really it doesn't matter that much as long as we still have to disassemble the device for some reason. Let's keep an eye on flashrom though. It looks like we'll focus on creating 2 scripts:

• flashrom_rpi_top_write.sh we (almost) already have, for the 4M release-image (first-time flashing)
• flashrom_rpi_bottom_unlock.sh for the 8M first-time stuff:
  • we could ship and build ifdtool directly. it's tiny. (document archive extraction too...)
  • we could ship me_cleaner.py too (run it optionally)

I'll create an "external" or "util" directory, similar to coreboot, only really tiny, and go from there.

[merge]

Just to follow-up: "unlocking" is only writing 0xff to 4 bytes:

--- low_locked1.rom
+++ low_locked1.rom.new
@@ -1,14 +1,14 @@
 00000000: ffff ffff ffff ffff ffff ffff ffff ffff  ................
 00000010: 5aa5 f00f 0301 0403 0602 1012 2001 2100  Z........... .!.
 00000020: 2500 0000 ffff ffff ffff ffff ffff ffff  %...............
 00000030: 1c00 9049 0000 0000 0000 0000 ffff ffff  ...I............
 00000040: 0000 0000 0005 ff0b 0300 ff04 0100 0200  ................
 00000050: ff1f 0000 ffff ffff ffff ffff ffff ffff  ................
-00000060: 0000 0b0a 0000 0d0c 1801 0808 ffff ffff  ................
+00000060: 0000 ffff 0000 ffff 1801 0808 ffff ffff  ................
 00000070: ffff ffff ffff ffff ffff ffff ffff ffff  ................
 00000080: ffff ffff ffff ffff ffff ffff ffff ffff  ................
 00000090: ffff ffff ffff ffff ffff ffff ffff ffff  ................
 000000a0: ffff ffff ffff ffff ffff ffff ffff ffff  ................

and this address is read by pawn. if it would be possible to write only this address, we'd win.

[merge]

I forgot to close this in one of the commits around today's 0.0.5 release (mainly it's a SeaBIOS update).

Anyways, I tested the new process and flashed a "new" X230 using the included scripts now. I like it a lot. It's really painless now to "bootstrap" a device; almost just "wait til it's done" compared to before :)

And see how small our release files have become :) 500k instead of 12M.

Supporting a different hardware SPI flasher you use and test, is a different issue.