Good day! We are debugging a custom config of G505S coreboot which
currently can't boot beyond SeaBIOS to any Linux: kernel gets stuck at
the early booting stages regardless of its' parameters. So we can't
access cbmem console, and are exploring the alternative console output
options. One of them
This elf file is position-independent and can be loaded to any location. We can
add a simple script to handle it.
1. Convert vmlinux to binary by objcopy, the binary file name is flat_file
2. Write a simple assembly file (tmp.S), convert binary to object, the file
name is obj_file
```
.section
I am reading the "flash security recommendation" from PCH BIOS writer
guide now, it did say strongly recommend to take those actions. The EISS
feature to ensure BIOS region can only get modfiyed from SMM.
On Wed, Sep 26, 2018 at 7:01 AM Nico Huber wrote:
> Am 26.09.18 um 10:50 schrieb Patrick
In my local tree I just added the ram address in selfboot.
Doing this beforehand with cbfstool would be even better. (E.g. only when
choosing linux payload)
The FIT probably needs to be created by distro tools: assembling kernel, dt
and initramfs.
On Wed, Sep 26, 2018, 17:42 ron minnich wrote:
Hello Ron,
I do not have such chip, but I am aware there are three patches
regarding the S25FL256S: [1]
Best regards,
Angel Pons
[1]: https://review.coreboot.org/q/topic:"s25fl256s;
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
we're trying to use a 32 MiB part with flashrom and failing, I just wanted
to see if anyone else has had good luck here.
It reads back as all FF, but there is no indication of trouble.
ron
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
You are right Nico,
I just forgot the troubles this caused me.
I am sorry Vika... My mistake.
I can confirm with Nico:
ROM chip size = 8MB (your case)
CBFS_SIZE = 2 to 5MB (your specific case)
My recommended approach is using the original Intel FW with already included
the FD, TXE.
I never
On 9/23/18 6:38 PM, Patrick Rudolph wrote:
> On 2018-09-23 12:22 PM, Nico Huber wrote:
>> Hi Lynxis,
>>
>> TLDR; I would prefer NVRAM settings and reading (but not writing) NVRAM
>> from ASL code directly.
>>
>> On 9/15/18 10:05 PM, Alexander Couzens wrote:
>>> I would like to merge
But the kernel can start anywhere. I don't see a reason to do this complex
objcopy step when all that is needed is to have cbfstool set some entries
in the SELF or just have selfboot use "0" to mean "somewhere useful"? Did I
miss something?
On Tue, Sep 25, 2018 at 10:32 PM 王翔 wrote:
> This elf
Hi Zvika,
On 9/25/18 10:59 PM, Zvi Vered wrote:
> Thank you very much for the detail information.
> The output of ifdtool in layout.txt is:
> :0fff fd
> 0030:007f bios
> 1000:002f me
>
> So the original bios size is 0x50 = 5MB
>
> You wrote:
> if the size of the
Hi,
On 9/26/18 9:19 AM, Jose Trujillo via coreboot wrote:
> No, don't change it, you change the size of coreboot only if during the
> building process "make" complain that there is not enough space but in
> your case your build was already successful leave it like that.
this advice seems very
Am 26.09.18 um 10:50 schrieb Patrick Rudolph:
> Hi Youness,
> On 2018-09-26 01:30 AM, Youness Alaoui wrote:
>> Hi,
>>
>> I'm trying to add a way to lock the SPI flash to be read-only via
>> software *after* coreboot boots. The scenario is basically with using
>> Heads, you could authenticate to it
Hi Youness,
Am 26.09.18 um 01:30 schrieb Youness Alaoui:
> There's a couple of things happening here :
> First, the FLOCKDN bit is set which prevents us from enabling the
> write protection. the BIOS Interface lock down is controlled by the
> chipset_lockdown config variable, but the FLOCKDN is
Hi Youness,
On 2018-09-26 01:30 AM, Youness Alaoui wrote:
> Hi,
>
> I'm trying to add a way to lock the SPI flash to be read-only via
> software *after* coreboot boots. The scenario is basically with using
> Heads, you could authenticate to it (with a yubikey/nitrokey/librem
> key) then be able
You are welcome,
No, don't change it, you change the size of coreboot only if during the
building process "make" complain that there is not enough space but in your
case your build was already successful leave it like that.
In the rare circumstance that more space is required you can increase
Hi,
I have a quick question. Is there any code in Coreboot to extend the payload to
be loaded in the PCR0 if
the TPM is enabled? I've been able to see the startup command executed but I
don't know if anything else
is implemented. Maybe is this implemented in some staging Coreboot branch?
16 matches
Mail list logo
