coreboot March 2018

coreboot@coreboot.org

62 participants
103 discussions

Re: [coreboot] ENE KB3940Q-A1 embedded controller custom firmware
by Youness Alaoui 06 Mar '18

06 Mar '18

An update on the use of Index I/O to access the SPI flash from software. I figured out the problem with coreboot. We weren't setting the LPC I/O decode range 0x380-0x383 in the LPC PCI config (gen1_dec config in devicetree) which would allow us to talk to the EC using Index I/O on port 0x380. Once I set that, I was able to access Index I/O on my coreboot-ed machine, and that opens up the software-based flashing support. On Mon, Mar 5, 2018 at 5:34 PM, Youness Alaoui <kakaroto(a)kakaroto.homelinux.net> wrote: > Thanks for the advice Mike, but I think you misunderstood the issue. I > wasn't talking about the internal memory of the EC, but rather about > accessing the EC firmware in SPI flash via an external SPI flasher. > The problem is that the SPI flash power rail is the same as the EC > chip, so as soon as we power the SPI flash to read it, it will also > power the EC chip, which will drive the SPI I/O pins high/low to read > its firmware, and since the EC executes the firmware from the flash, > that means that the SPI flash will constantly be accessed by the EC > and the external flasher can't take control of the I/O. > However, it looks like if the EC firmware crashes, it will stop using > the flash and will therefore 'release' the I/O pins for the external > flasher to use them. > If I short MISO with VCC, then the EC will read its firmware as being > all 0xFF (which is the same as when I corrupted the flash by erasing > its first sector), and that will cause it to crash and release the SPI > flash, then we can read it. No need to solder or enable debug mode or > anything like that. > > Anyways, my true purpose is to use software flashing only, I already > have read/write/sector_erase support written but it requires the use > of the Index I/O (LPC port 0x380) which I can only access when I flash > the machine with the AMI BIOS, but which becomes inaccessible if I > only have coreboot. I think it's because AMI will send EC > vendor-specific commands via LPC port 62h/66h to configure it and > enable the Index I/O access. I've suggested to Paul if we could a > reduced firmware that would only log to UART all the accesses to the > EC via the LPC port 62/66 (kind of like doing SerialICE for the EC) so > we could document the vendor specific commands AMI uses to enable > Index I/O. Once we know that, we should be able to read/write to the > EC flash using software only. > > > On Mon, Mar 5, 2018 at 4:04 PM, Mike Banon <mikebdp2(a)gmail.com> wrote: >>> otherwise, the EC prevents us from accessing it >> Maybe KB3940Q has the same protection as KB9012 : unless the EC's >> ground pin has been shortened with motherboard's ground _before_ you >> have powered a motherboard, you would not have any access; otherwise, >> EC will go into debug mode and you'll have the full access to its' >> internal memory. To avoid the soldering, you could look through the >> instructions described here - >> http://dangerousprototypes.com/docs/Flashing_KB9012_with_Bus_Pirate ; >> in short : use a keyboard flex cable to reach EC spi pins as well as >> its' ground, and a test hook clip to easily get a ground of your >> motherboard >> >> On Mon, Mar 5, 2018 at 11:00 PM, Youness Alaoui >> <kakaroto(a)kakaroto.homelinux.net> wrote: >>> On Sun, Mar 4, 2018 at 4:50 AM, Paul Kocialkowski <contact(a)paulk.fr> wrote: >>>> Hi, >>>> >>>> Le vendredi 16 février 2018 à 14:09 -0500, Youness Alaoui a écrit : >>>>> > > Sure, you can trust hardware flashing more than software flashing, >>>>> > > but >>>>> > > I really need software flashing. If it was just for me, yeah, I >>>>> > > could >>>>> > > fiddle with it to flash it by hardware for my personal needs, but >>>>> > > when >>>>> > > it's about deploying it to all our customer base, that's another >>>>> > > story, the only solution is software flashing. Obviously, it would >>>>> > > have to work in coreboot, so whatever coreboot is doing wrong (or >>>>> > > AMI >>>>> > > is doing right.. my guess is that it's probably something with the >>>>> > > EC >>>>> > > ACPI code), we'd have to figure that out first in order to get the >>>>> > > read/write support. >>>>> > >>>>> > Either way, since the EC firmware resides in the SPI flash, it'll be >>>>> > no >>>>> > issue to reflash it both by software and hardware. >>>>> >>>>> On the librems, the EC firmware resides in a separate 64KB SPI flash, >>>>> it's not shared with the bios, and I haven't found a way to access it. >>>> >>>> Is it really only 64 KiB? The chip definitely supports more and it seems >>>> a bit small to fit the whole firmware. >>>> >>> >>> Yes, it's a MX25L512. I can send you the firmwares that were on it if >>> you're curious (each machine revision had a different firmware, even >>> though it's the same ene chip in all of them, I don't know enough >>> about the EC to know if that's normal). >>> >>> The cool thing is that I was able to flash the chip externally, but >>> only when I corrupted the EC firmware (I erased the first page and the >>> laptop crashed before I finished re-programming it by software). I >>> reproduced it twice again, if the EC firmware has crashed, it stops >>> accessing the SPI flash and we can program it with an external >>> flasher, otherwise, the EC prevents us from accessing it. So I think >>> it might be possible to simply short the MOSI/MISO to VCC to cause the >>> firmware to be unreadable, so the EC doesn't boot, then we should be >>> able to read/write from the EC with a pomona clip.

1 0

Re: [coreboot] Real name policy
by mturney＠codeaurora.org 06 Mar '18

06 Mar '18

On 2018-03-05 17:50, David Hendricks wrote: > On Mon, Mar 5, 2018 at 1:13 PM, Taiidan(a)gmx.com <Taiidan(a)gmx.com> > wrote: > >> I can't understand as to why doing a git commit requires your "real" >> name > > SCO. > > Ref: https://lkml.org/lkml/2004/5/23/10 Wow, SCO, really? If anybody on list is interested, I gave a presentation on the SCO litigation to a local LUG in April.2005. http://recipes4linux.com/os-presentations/2005apr.pdf Cheers, T.mike

2 1

Re: [coreboot] Real name policy
by awokd 06 Mar '18

06 Mar '18

On Tue, March 6, 2018 1:58 am, Gregg Levine wrote: > Hello! > That's a great reason right there. Who knows how much they contributed > to the state of the art, and did not properly sign it. But in the end while > their world was collapsing around them, we knew who they were via Groklaw. > ----- > Gregg C Levine gregg.drwho8(a)gmail.com > "This signature fought the Time Wars, time and again." > > > > On Mon, Mar 5, 2018 at 8:50 PM, David Hendricks > <david.hendricks(a)gmail.com> wrote: > >> >> >> On Mon, Mar 5, 2018 at 1:13 PM, Taiidan(a)gmx.com <Taiidan(a)gmx.com> >> wrote: >> >>> >>> I can't understand as to why doing a git commit requires your "real" >>> name >> >> >> SCO. >> >> >> Ref: https://lkml.org/lkml/2004/5/23/10 Could some type of asset-less legal entity be set up (cheaply, anonymously) somewhere in the world to accept anonymous code donations and commit them on behalf of their submitter? Would shield open source projects from frivolous lawsuits and protect contributors' privacy. Apologies if this has already all been discussed thoroughly somewhere else...

2 2

Re: [coreboot] ARM Veyron Speedy - Replacing 11.6 inch display for 15 inch
by Mark Wylde 06 Mar '18

06 Mar '18

Typical luck, just as I sent my last message my new monitor arrives. I've just hooked it up and it actually worked. Unfortunately it's not a 15'' monitor, but a 14'' one. Not sure how it works on only 1 lane, but not going to complain. For anyone else interested the monitor specs are here: http://www.bvslcd.cn/uploads/2016/11/261508375971.pdf ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On March 6, 2018 8:55 AM, Mark Wylde <me(a)markwylde.co.uk> wrote: > Hi Julius. > > Thanks so much for your message it was a great help. > > So looking at the specs for the display that comes with the ASUS Chromebook C201 I can see the following PIN structure [1] is required on the display end. Also my new monitor [2] has the exact same PIN structure for the display, but unfortunately uses the ML1 lane. > > ------------------ eDP Pins for C201 Display ------------------ > 1 = NC No Connection (Reserved for LCD test) > 2 = H_GND High Speed Ground > 3 = NC No Connection ( Reserved for ML1 - ) > 4 = NC No Connection (Reserved for ML1+) > 5 = H_GND High Speed Ground > 6 = ML0 - Complement Signal - Lane 0 > 7 = ML0+ True Signal - Main Lane 0 > 8 = H_GND High Speed Ground > 9 = AUX+ True Signal - Auxiliary Channel > 10 = AUX - Complement Signal - Auxiliary Channel > 11 = H_GND High Speed Ground > 12 = VCCS Power Supply +3.3 V (typical) > 13 = VCCS Power Supply +3.3 V (typical) > 14 = NC No Connection (Reserved for LCD test) > 15 = GND Ground > 16 = GND Ground > 17 = HPD Hot Plug Detect > 18 = BL_GND BL Ground > 19 = BL_GND BL Ground > 20 = BL_GND BL Ground > 21 = BL_GND BL Ground > 22 = LED_EN BL_Enable Signal of LED Converter > 23 = LED_PWM PWM Dimming Control Signal of LED Converter > 24 = NC No Connection (Reserved for LCD test) > 25 = NC No Connection (Reserved for LCD test) > 26 = LED_VCCS BL Power > 27 = LED_VCCS BL Power > 28 = LED_VCCS BL Power > 29 = LED_VCCS BL Power > 30 = NC No Connection (Reserved for LCD test) > -------------------------------------------------- > > I think I understand by your response that ASUS has used a 20 pin connector on the motherboard part. Therefore they haven't connected up the the ML1 lane. It also looks like with only 1 lane you can only have a resolution of 1680×1050 (18 bit color depth) [3] which would be a waste of the 15'' display. Although even if they did have the lane exposes it looks like your helpful advice on the coreboot function would be a bit out of my depth. > > So I think we can conclude it's impossible to get a bigger monitor (or at least one with a bigger resolution) through the eDP port. I guess one could get a controller board and hook the monitor up via the HDMI mini port, but I think I'll pass on that. It was interesting to learn more about eDP though. > > Thanks Julius and Nico for all your help. > > 1. http://www.szdengyi.com/upload/web/lcdspec/N116BGE-EB2-LR-Asus-notebook-pc.… > 2. http://www.yslcd.com.tw/docs/product/N156HGE-EAB.pdf > 3. https://forums.lenovo.com/t5/Lenovo-U-and-S-Series-Notebooks/Lenovo-U430p-s… > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On March 5, 2018 11:50 PM, Julius Werner <jwerner(a)chromium.org> wrote: > >> I have access to the schematics for Speedy... I'm not allowed to share them, but I'm happy to look up something specific for you if it helps. >> >> Nico is right, only one of the four DP lanes coming out of the SoC is routed to the connector. If your panel requires more than that, you're probably SOL. Although I'm not even sure where they would go on that connector... there's only 20 pins, and they all seem to be used already. (I'm not really sure how standardized those connectors are, tbh... if you buy a panel with a different pinout, obviously nothing will work and it might even damage the panel and/or the mainboard.) >> >> I also remember that RK3288 PLLs often had some issues with jitter (at least they had for HDMI, not sure if it applies to DP). The code we implemented (clock.c:pll_para_config) does whatever it can to meet the pixel clock as exactly as possible, but maybe that wasn't actually the best way to do it. In your case you end up with a very large input divisor (NR = 59), so you're essentially dividing the 24MHz oscillator down to 407KHz and then multiplying it back up (thus amplifying noise). Maybe try hacking that function to hardcode the result to NR = 1, NF = 23, NO = 4 (leading to VCO = 552000KHz, output = 138000KHz) or NR = 4, NF = 91, NO = 4 (leading to VCO = 546000KHz, output = 136500KHz) and see if that helps. (In fact, that latter configuration is closer to the target frequency of 136620KHz than the one you get... what you're seeing is sort of a freak accident resulting from a compounding of rounding errors during the calculation. You're welcome to try to fix the code if you want, but it's kinda difficult to get all the different requirements right at once... for example, you'd have less errors if it were calculating in Hz, but we went with KHz since we were afraid it could overflow in some situations.)

1 0

Re: [coreboot] ARM Veyron Speedy - Replacing 11.6 inch display for 15 inch
by Mark Wylde 06 Mar '18

06 Mar '18

Hi Julius. Thanks so much for your message it was a great help. So looking at the specs for the display that comes with the ASUS Chromebook C201 I can see the following PIN structure [1] is required on the display end. Also my new monitor [2] has the exact same PIN structure for the display, but unfortunately uses the ML1 lane. ------------------ eDP Pins for C201 Display ------------------ 1 = NC No Connection (Reserved for LCD test) 2 = H_GND High Speed Ground 3 = NC No Connection ( Reserved for ML1 - ) 4 = NC No Connection (Reserved for ML1+) 5 = H_GND High Speed Ground 6 = ML0 - Complement Signal - Lane 0 7 = ML0+ True Signal - Main Lane 0 8 = H_GND High Speed Ground 9 = AUX+ True Signal - Auxiliary Channel 10 = AUX - Complement Signal - Auxiliary Channel 11 = H_GND High Speed Ground 12 = VCCS Power Supply +3.3 V (typical) 13 = VCCS Power Supply +3.3 V (typical) 14 = NC No Connection (Reserved for LCD test) 15 = GND Ground 16 = GND Ground 17 = HPD Hot Plug Detect 18 = BL_GND BL Ground 19 = BL_GND BL Ground 20 = BL_GND BL Ground 21 = BL_GND BL Ground 22 = LED_EN BL_Enable Signal of LED Converter 23 = LED_PWM PWM Dimming Control Signal of LED Converter 24 = NC No Connection (Reserved for LCD test) 25 = NC No Connection (Reserved for LCD test) 26 = LED_VCCS BL Power 27 = LED_VCCS BL Power 28 = LED_VCCS BL Power 29 = LED_VCCS BL Power 30 = NC No Connection (Reserved for LCD test) -------------------------------------------------- I think I understand by your response that ASUS has used a 20 pin connector on the motherboard part. Therefore they haven't connected up the the ML1 lane. It also looks like with only 1 lane you can only have a resolution of 1680×1050 (18 bit color depth) [3] which would be a waste of the 15'' display. Although even if they did have the lane exposes it looks like your helpful advice on the coreboot function would be a bit out of my depth. So I think we can conclude it's impossible to get a bigger monitor (or at least one with a bigger resolution) through the eDP port. I guess one could get a controller board and hook the monitor up via the HDMI mini port, but I think I'll pass on that. It was interesting to learn more about eDP though. Thanks Julius and Nico for all your help. 1. http://www.szdengyi.com/upload/web/lcdspec/N116BGE-EB2-LR-Asus-notebook-pc.… 2. http://www.yslcd.com.tw/docs/product/N156HGE-EAB.pdf 3. https://forums.lenovo.com/t5/Lenovo-U-and-S-Series-Notebooks/Lenovo-U430p-s… ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On March 5, 2018 11:50 PM, Julius Werner <jwerner(a)chromium.org> wrote: > I have access to the schematics for Speedy... I'm not allowed to share them, but I'm happy to look up something specific for you if it helps. > > Nico is right, only one of the four DP lanes coming out of the SoC is routed to the connector. If your panel requires more than that, you're probably SOL. Although I'm not even sure where they would go on that connector... there's only 20 pins, and they all seem to be used already. (I'm not really sure how standardized those connectors are, tbh... if you buy a panel with a different pinout, obviously nothing will work and it might even damage the panel and/or the mainboard.) > > I also remember that RK3288 PLLs often had some issues with jitter (at least they had for HDMI, not sure if it applies to DP). The code we implemented (clock.c:pll_para_config) does whatever it can to meet the pixel clock as exactly as possible, but maybe that wasn't actually the best way to do it. In your case you end up with a very large input divisor (NR = 59), so you're essentially dividing the 24MHz oscillator down to 407KHz and then multiplying it back up (thus amplifying noise). Maybe try hacking that function to hardcode the result to NR = 1, NF = 23, NO = 4 (leading to VCO = 552000KHz, output = 138000KHz) or NR = 4, NF = 91, NO = 4 (leading to VCO = 546000KHz, output = 136500KHz) and see if that helps. (In fact, that latter configuration is closer to the target frequency of 136620KHz than the one you get... what you're seeing is sort of a freak accident resulting from a compounding of rounding errors during the calculation. You're welcome to try to fix the code if you want, but it's kinda difficult to get all the different requirements right at once... for example, you'd have less errors if it were calculating in Hz, but we went with KHz since we were afraid it could overflow in some situations.)

1 0

Re: [coreboot] Real name policy
by Gregg Levine 06 Mar '18

06 Mar '18

Hello! That's a great reason right there. Who knows how much they contributed to the state of the art, and did not properly sign it. But in the end while their world was collapsing around them, we knew who they were via Groklaw. ----- Gregg C Levine gregg.drwho8(a)gmail.com "This signature fought the Time Wars, time and again." On Mon, Mar 5, 2018 at 8:50 PM, David Hendricks <david.hendricks(a)gmail.com> wrote: > > > On Mon, Mar 5, 2018 at 1:13 PM, Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote: >> >> I can't understand as to why doing a git commit requires your "real" name > > > SCO. > > Ref: https://lkml.org/lkml/2004/5/23/10 > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Real name policy
by Taiidan＠gmx.com 06 Mar '18

06 Mar '18

I can't understand as to why doing a git commit requires your "real" name and while I could simply make something up I instead I wish to protest this policy and hear out a justification for it. This is a project with a main goal of improving security however having your name on the internet is almost always going to be bad security.

3 2

Re: [coreboot] ARM Veyron Speedy - Replacing 11.6 inch display for 15 inch
by Nico Huber 06 Mar '18

06 Mar '18

On 05.03.2018 12:02, Mark Wylde wrote: > Thanks Nico for taking your valuable time to answer my questions. I > really appreciate it, and knowing that it should be possible makes me > feel better about continuing the project. > > I've ordered another display that has better matching specifications. > I'll reply here to let others know if it works or not although I agree > this is probably not a coreboot issue. > Well that though might have come too hasty. There is some board specific information that coreboot might miss, e.g. how many lanes are actually implemented. If the original display needed only a single DP lane, maybe they omitted the traces for the other lanes (in your log, coreboot tries to train 2 lanes). And maybe there is more that I didn't consider. A log of the successful training with the original display might give more clues. In case you haven't tried yet, you can probably also let Linux do the DP training. And last but not least, there is a edp_debug() definition at the top of `soc/rockchip/common/edp.c`. Nico

2 1

Re: [coreboot] ENE KB3940Q-A1 embedded controller custom firmware
by Youness Alaoui 05 Mar '18

05 Mar '18

Thanks for the advice Mike, but I think you misunderstood the issue. I wasn't talking about the internal memory of the EC, but rather about accessing the EC firmware in SPI flash via an external SPI flasher. The problem is that the SPI flash power rail is the same as the EC chip, so as soon as we power the SPI flash to read it, it will also power the EC chip, which will drive the SPI I/O pins high/low to read its firmware, and since the EC executes the firmware from the flash, that means that the SPI flash will constantly be accessed by the EC and the external flasher can't take control of the I/O. However, it looks like if the EC firmware crashes, it will stop using the flash and will therefore 'release' the I/O pins for the external flasher to use them. If I short MISO with VCC, then the EC will read its firmware as being all 0xFF (which is the same as when I corrupted the flash by erasing its first sector), and that will cause it to crash and release the SPI flash, then we can read it. No need to solder or enable debug mode or anything like that. Anyways, my true purpose is to use software flashing only, I already have read/write/sector_erase support written but it requires the use of the Index I/O (LPC port 0x380) which I can only access when I flash the machine with the AMI BIOS, but which becomes inaccessible if I only have coreboot. I think it's because AMI will send EC vendor-specific commands via LPC port 62h/66h to configure it and enable the Index I/O access. I've suggested to Paul if we could a reduced firmware that would only log to UART all the accesses to the EC via the LPC port 62/66 (kind of like doing SerialICE for the EC) so we could document the vendor specific commands AMI uses to enable Index I/O. Once we know that, we should be able to read/write to the EC flash using software only. On Mon, Mar 5, 2018 at 4:04 PM, Mike Banon <mikebdp2(a)gmail.com> wrote: >> otherwise, the EC prevents us from accessing it > Maybe KB3940Q has the same protection as KB9012 : unless the EC's > ground pin has been shortened with motherboard's ground _before_ you > have powered a motherboard, you would not have any access; otherwise, > EC will go into debug mode and you'll have the full access to its' > internal memory. To avoid the soldering, you could look through the > instructions described here - > http://dangerousprototypes.com/docs/Flashing_KB9012_with_Bus_Pirate ; > in short : use a keyboard flex cable to reach EC spi pins as well as > its' ground, and a test hook clip to easily get a ground of your > motherboard > > On Mon, Mar 5, 2018 at 11:00 PM, Youness Alaoui > <kakaroto(a)kakaroto.homelinux.net> wrote: >> On Sun, Mar 4, 2018 at 4:50 AM, Paul Kocialkowski <contact(a)paulk.fr> wrote: >>> Hi, >>> >>> Le vendredi 16 février 2018 à 14:09 -0500, Youness Alaoui a écrit : >>>> > > Sure, you can trust hardware flashing more than software flashing, >>>> > > but >>>> > > I really need software flashing. If it was just for me, yeah, I >>>> > > could >>>> > > fiddle with it to flash it by hardware for my personal needs, but >>>> > > when >>>> > > it's about deploying it to all our customer base, that's another >>>> > > story, the only solution is software flashing. Obviously, it would >>>> > > have to work in coreboot, so whatever coreboot is doing wrong (or >>>> > > AMI >>>> > > is doing right.. my guess is that it's probably something with the >>>> > > EC >>>> > > ACPI code), we'd have to figure that out first in order to get the >>>> > > read/write support. >>>> > >>>> > Either way, since the EC firmware resides in the SPI flash, it'll be >>>> > no >>>> > issue to reflash it both by software and hardware. >>>> >>>> On the librems, the EC firmware resides in a separate 64KB SPI flash, >>>> it's not shared with the bios, and I haven't found a way to access it. >>> >>> Is it really only 64 KiB? The chip definitely supports more and it seems >>> a bit small to fit the whole firmware. >>> >> >> Yes, it's a MX25L512. I can send you the firmwares that were on it if >> you're curious (each machine revision had a different firmware, even >> though it's the same ene chip in all of them, I don't know enough >> about the EC to know if that's normal). >> >> The cool thing is that I was able to flash the chip externally, but >> only when I corrupted the EC firmware (I erased the first page and the >> laptop crashed before I finished re-programming it by software). I >> reproduced it twice again, if the EC firmware has crashed, it stops >> accessing the SPI flash and we can program it with an external >> flasher, otherwise, the EC prevents us from accessing it. So I think >> it might be possible to simply short the MOSI/MISO to VCC to cause the >> firmware to be unreadable, so the EC doesn't boot, then we should be >> able to read/write from the EC with a pomona clip.

1 0

Re: [coreboot] ENE KB3940Q-A1 embedded controller custom firmware
by Mike Banon 05 Mar '18

05 Mar '18

> otherwise, the EC prevents us from accessing it Maybe KB3940Q has the same protection as KB9012 : unless the EC's ground pin has been shortened with motherboard's ground _before_ you have powered a motherboard, you would not have any access; otherwise, EC will go into debug mode and you'll have the full access to its' internal memory. To avoid the soldering, you could look through the instructions described here - http://dangerousprototypes.com/docs/Flashing_KB9012_with_Bus_Pirate ; in short : use a keyboard flex cable to reach EC spi pins as well as its' ground, and a test hook clip to easily get a ground of your motherboard On Mon, Mar 5, 2018 at 11:00 PM, Youness Alaoui <kakaroto(a)kakaroto.homelinux.net> wrote: > On Sun, Mar 4, 2018 at 4:50 AM, Paul Kocialkowski <contact(a)paulk.fr> wrote: >> Hi, >> >> Le vendredi 16 février 2018 à 14:09 -0500, Youness Alaoui a écrit : >>> > > Sure, you can trust hardware flashing more than software flashing, >>> > > but >>> > > I really need software flashing. If it was just for me, yeah, I >>> > > could >>> > > fiddle with it to flash it by hardware for my personal needs, but >>> > > when >>> > > it's about deploying it to all our customer base, that's another >>> > > story, the only solution is software flashing. Obviously, it would >>> > > have to work in coreboot, so whatever coreboot is doing wrong (or >>> > > AMI >>> > > is doing right.. my guess is that it's probably something with the >>> > > EC >>> > > ACPI code), we'd have to figure that out first in order to get the >>> > > read/write support. >>> > >>> > Either way, since the EC firmware resides in the SPI flash, it'll be >>> > no >>> > issue to reflash it both by software and hardware. >>> >>> On the librems, the EC firmware resides in a separate 64KB SPI flash, >>> it's not shared with the bios, and I haven't found a way to access it. >> >> Is it really only 64 KiB? The chip definitely supports more and it seems >> a bit small to fit the whole firmware. >> > > Yes, it's a MX25L512. I can send you the firmwares that were on it if > you're curious (each machine revision had a different firmware, even > though it's the same ene chip in all of them, I don't know enough > about the EC to know if that's normal). > > The cool thing is that I was able to flash the chip externally, but > only when I corrupted the EC firmware (I erased the first page and the > laptop crashed before I finished re-programming it by software). I > reproduced it twice again, if the EC firmware has crashed, it stops > accessing the SPI flash and we can program it with an external > flasher, otherwise, the EC prevents us from accessing it. So I think > it might be possible to simply short the MOSI/MISO to VCC to cause the > firmware to be unreadable, so the EC doesn't boot, then we should be > able to read/write from the EC with a pomona clip.

1 0

← Newer
1
...
5
6
7
8
9
10
11
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot March 2018