I documented it but I should update the page somehow it works without any but one of my extra patches but it has 1 small issue GNUtoo-irssi: do you need review on those? I think that sth like it could save me countless external reflashs phcoder-1creen: well, most of them are unnecessary now 1 patch is usefull only for improving code readability of existing coreboot code 1 patch is only changing the reboot count of the fallback mecanism beside that I see nothing remaining but I can check again I have to do it now The documentation is on the wiki caveats: 1) sometimes the x60 reboots twice, for instance if you run poweroff, then let it power down, and as soon as it seems powered down, you press the power button in that case it will do a reset 2) suspend/resume and userspace needs some handling, I've systemd units for booting only, but not for suspend/resume but you can do it by hand config MAX_REBOOT_CNT int default 1 that's what I added in src/mainboard/lenovo/x60/Kconfig before I had a patch to make it selectable it in Kconfig, that is to say the user enter the max reboot count he wants I think the global default is 3 Then I've some other interesting patches I wonder if they're acceptable one patch is for adding etc/grub.cfg from Kconfig Use case: the user builds once, he do ./build/cbfstool ./build/coreboot.rom add -n etc/grub.cfg -f grub.cfg -t raw but he re-do make and forgett to re-add grub.cfg it's just a convenience (he could do it with a script too) *he/she I guess the user is a she in english? en french it's a he I've also a flashrom patch to submit phcoder-1creen: "it could save me countless external reflashs" => that was exactly my use case There are some other interesting stuff that could extend the use case: there is a flash log for the chromebooks example use case: you go to a conference in the USA, you are in the plane you then continue developing there, you reflash etc... but then you need the log of the failed boot somehow the flash log (which is in coreboot but require CONFIG_CHROMEOS or something like that) could help with that second use case Else the logs in RAM + a watchdog could also do the trick *hardware watchdog so that second approach of the second use case would just require some modifications related to cbmem they may already be there, because I'm way out of the loop I'll make a list of the interesting patches I have locally and look at gerrit too btw, is there some easy infrastructure work to do? like something that can be done on the side * ttyS3 has quit (Ping timeout: 264 seconds) The x60[s/t], T60(with intel GPUs), are mostly complete, the main issue remaining is merging that improved GPU init code fallback/ is mostly merged but that one patch I was talking about then I guess the ACPI part was merged I'm unsure about the IRDA I mostly test on x60t nowadays (my t60 has a nasty bug with ctrl+d, probably ec related) I've also to look about the security of the I/Os (like what's on the dock connector) there is also the license issue of the microcodes inside the headers I'll add all that in the wiki GNUtoo-irssi: did you test digitizer? yes works well with libreboot 6 beta3 patches on top of coreboot git I use it often with xournal mainly I've been in a local shop and I've found a compatilble wacom pen: it has: touch, button(right click), eraser all do work the pen is not the x60 pen, but it does work fine digitizer patches are already in The screen's directional keys the its middle key work yes I'll update soon I'll probably sumarize the patch I've left in the wiki and update that fallback page phcoder-1creen: is the IRDA supposed to work? GNUtoo-irssi: 5243 T60, rght? * KidBeta has quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) x60 and x60t oops x60t and t60 I'll test them together, I was trying lirc instead directlyt 5242 for X60 ok thanks GNUtoo-irssi: did you see x200 port? yes what CPU is it? and what chipset? gm45. Intel GPU ok I've looked at your new ports and related, it probably cover the chipset I have in my N71JQ but I probably don't have time to do the port anytime soon gm45 was already covered by rk9 yes it's core 2 duo with the first AMT in the NICs, right? and 64bit? it's 64bit. I can't tell anything about AMT. so I guess that if someone unsolder his nic firmware flash, the AMT is gone? ok if so that's probably a good tradeoff you get more recent laptops at the cost of unsoldering or blanking the NIC's flash ME firmware is in the flash chip. There is information that on gm45 you can remove ME firmware without any consequences but I din't really try assuming it's like with the old i945 laptops ok, wow, nice how fast is it in between the T60's and the Nehalem's laptops(x201) roda rk9 runs without ME firmware AFACIT ok about roda and so on, there isn't a lot of infos on the rugged laptops I guess that nobody still test on them No. But the list of connectors they have is truly impressive. As is battery capacity and heaviness. indeed it probably has lot of interesting peripherals too, like GPS, 3g modem(how is it connected?) and so on for the heavyness, it's a way to make geeks become like rambo? s/geeks/geeks and nerds 3g modems are optional. I guess it's minipcie slot. BTW x200 has 3 minipcie slots wow (not counting exprecsscard) ok that permits to have 2 wifi cards... if driver can handle it, sure. When I tried with 2 intel cards, intel drivers and networkmanager got confused. (ath9k/ath5k have some difficulties when creating multiples interfaces when WPA is involved) ok 3rd minipcie was intended for UWB. well, I have multiples cards easily here I never had a problem with non-intel cards network manager will still get confused example: ath9k + ath9k_htc => both interfaces appear in kde's network manager GUI it was getting confused with intel cards and rfkill (and I lacked the fimrware of the intel cards...so that added to the confusion) Example use case: connect to 2 different AP on 2 different networks yes network manager and multiple cards and rfkill resultsin confusion my ath9k_htc is usb so no hardware rfkill btw, the mini-pcie connectors do export only pci? do they export usb, and sata? (and some other pins for rfkill, SIM card, and so on) ok well, I must update the instructions I was going trough the list of patches I had first yes but to a specific/personal page could you link me to the updated instructions? (when done) well, I'll update them first I was going trough my patches list before that so I'll do that now So I gather that you basically reset the counter yourself after you boot (after typing grub password) and so, if you boot and the counter is higher, you know if someone tried to use it yes, my systemd unit does it *resets it so it works like that: the bootblock switch from normal/ to fallback if the counter is > CONFIG_MAX_REBOOT_CNT if no normal/ is there it also switch to fallback/ and then it increments the counter (it's badly explained by me but you get the idea) then my systemd units reset the counter to 0 once it's fully booted that way if it fails, let's say at booting any linux kernel, then the user won't have bricked the laptop (and the developer will have saved lot of time) the issue is that I didn't reset the counter at resume I should look how but at least that makes it developer friendly if the user don't have suspend-resume covered yet testing images is then a lot faster and for "production", only fallback/ populated, but with the mecanism in place that way he can test normal/ easily