Please don't forget to CC the coreboot mailing list. You could
determine the chip's layout by looking on it: it has a dot near CS
pin. As for cable/clip and programmer, check "Flashing BIOS chip with
Bus Pirate" article at dangerous prototypes forums: it has a good
review of SOIC8 test clips and
Hello
On Wed, Jan 23, 2019, 18:11 Ivan Ivanov Please don't forget to CC the coreboot mailing list. You could
> determine the chip's layout by looking on it: it has a dot near CS
> pin.
>
Worth mentioning: this dot is not painted, it is a physical crater on the
chip. The painted dots are never a
On Tue, Jan 22, 2019 at 6:21 PM Julius Werner wrote:
> > FWIW, it's my opinion I think we'll need to start splitting cbfs into
> smaller ones. This isn't specific to this situation, but splitting slots
> into multiple cbfses (rw-a-1, rw-a-2, etc) allows one to chain/group
> resources as they
The tools impalements the mei state machine in the user space so it will
conflict with the driver, you can try to unbind the driver if you need such
functionality,
Second the protocol is evolving and we are update the driver but I cannot
update it in a tool I don't know about.
I suggest you
On 17.12.2018 15:28, Arthur Heymans wrote:
> Carl-Daniel Hailfinger writes:
>> * FOSDEM 2-3 February 2019
>> * We have a coreboot/LinuxBoot/flashrom stand! Need people for the stand
>> (2 days, 1 table).
> I Live in Antwerp, so reasonably close by, so I will certainly be there
> and can lend a
> For 1, this is attempting to protect physical attack. Obviously this
> particular problem can't be solved in isolation, but it's something to think
> about.
But isn't this something that per-file hashing would probably make
easier to protect against, not harder? I mean, right now we just hash
Hey everyone,
just 9 days until FOSDEM in Brussels (2+3 February)!
There are a couple of talks about coreboot and LinuxBoot and we have a
coreboot/LinuxBoot/flashrom stand (building AW). Plus, there is a
hardware enablement devroom.
- Who's coming?
- Are you volunteering for a shift at the
Currently with the one CBFS containing all files it is easy and simple to
access every file in every stage.
Wouldn't this be harder if we chose to split the CBFS into several, stand-alone
CBFSes?
Or, on the other hand, wouldn't we end up in duplicating CBFS files just to
have them around handy?
8 matches
Mail list logo
