Hi,
[ Please don't send an extra mail to me, I'm on the mailing list.
And try to avoid TOFU. Thank you. ]
* Kevin Wilson <wkevils(a)gmail.com> [2015-07-19 07:45]:
> Thanks for all the responses.
> Short questions:
> I saw. on my system::
> cat /sys/class/dmi/id/bios_vendor
> coreboot
>
> Is it equivalent to
> dmidecode -t bios | grep Vendor
> Vendor: coreboot
>
> What I mean is: does dmidecode in fact read the
> /sys/class/dmi/id/bios_vendor entry?
[...snip...]
Seems so:
ctvdr:~# cat /sys/class/dmi/id/bios_vendor
coreboot
Let's take a different example:
erwin:~# dmidecode -t bios | grep Vendor
Vendor: Award Software International, Inc.
erwin:~# cat /sys/class/dmi/id/bios_vendor
Award Software International, Inc.
If you want to be sure, verify with the dmidecode source code.
BTW: I found a shorter dmidecode command line:
ctvdr:~# dmidecode -s bios-vendor
coreboot
@ndy
Hi,
* Kevin Wilson <wkevils(a)gmail.com> [2015-07-18 10:03]:
> Is there a way, from a device running Linux, to which I have access
> to the command line, to know
> whether the BIOS is coreboot or not ? by some utility, or by some sysfs entry ?
Yes, if you have dmidecode present:
ctvdr:~# dmidecode -t bios | grep Vendor
Vendor: coreboot
Probably it might be possible to set it to something else, but that
seems to be the default.
@ndy
Hi,
* Kevin Wilson <wkevils(a)gmail.com> [2015-07-18 10:03]:
> Is there a way, from a device running Linux, to which I have access
> to the command line, to know
> whether the BIOS is coreboot or not ? by some utility, or by some sysfs entry ?
Yes, if you have dmidecode present:
ctvdr:~# dmidecode -t bios | grep Vendor
Vendor: coreboot
Probably it might be possible to set it to something else, but that
seems to be the default.
@ndy
My $.02 is to check dmidecode.
Marc
On Sat, Jul 18, 2015 at 10:11 AM ron minnich <rminnich(a)gmail.com> wrote:
> Could you also look for LBIO in the e and f segments?
>
> On Sat, Jul 18, 2015 at 12:34 AM Patrick Georgi <pgeorgi(a)google.com>
> wrote:
>
>> 2015-07-18 9:03 GMT+02:00 Kevin Wilson <wkevils(a)gmail.com>:
>> > Is there a way, from a device running Linux, to which I have access
>> > to the command line, to know
>> > whether the BIOS is coreboot or not ? by some utility, or by some sysfs
>> entry ?
>> We usually have coreboot related vendor names for ACPI tables (eg.
>> dsdt table id 'COREBOOT'). Those are visible early on in dmesg, I
>> think.
>> Also our cbmem utility (coreboot source tree, util/cbmem) can print a
>> coreboot specific table's content.
>>
>> Neither of these are guaranteed to be around (it would be possible to
>> cloak things thoroughly), but it's likely that they are on coreboot,
>> and pretty much non-existent otherwise.
>>
>>
>> Patrick
>> --
>> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
>> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
>> Hamburg
>> Geschäftsführer: Graham Law, Christine Elizabeth Flores
>>
>> --
>> coreboot mailing list: coreboot(a)coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
Could you also look for LBIO in the e and f segments?
On Sat, Jul 18, 2015 at 12:34 AM Patrick Georgi <pgeorgi(a)google.com> wrote:
> 2015-07-18 9:03 GMT+02:00 Kevin Wilson <wkevils(a)gmail.com>:
> > Is there a way, from a device running Linux, to which I have access
> > to the command line, to know
> > whether the BIOS is coreboot or not ? by some utility, or by some sysfs
> entry ?
> We usually have coreboot related vendor names for ACPI tables (eg.
> dsdt table id 'COREBOOT'). Those are visible early on in dmesg, I
> think.
> Also our cbmem utility (coreboot source tree, util/cbmem) can print a
> coreboot specific table's content.
>
> Neither of these are guaranteed to be around (it would be possible to
> cloak things thoroughly), but it's likely that they are on coreboot,
> and pretty much non-existent otherwise.
>
>
> Patrick
> --
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
> Hamburg
> Geschäftsführer: Graham Law, Christine Elizabeth Flores
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
On Mon, Jul 13, 2015 at 11:45 PM, Yu-Cheng Liu <peter90609(a)gmail.com> wrote:
> hello ,
>
> 1.I tried to trace coreboot, I followed the coreboot Debugging steps but
> there is no coreboot_ram.debug in my directory.
> I select GDB debugging support and Wait for a GDB connection rebuild
> coreboot already, what step is missing ?
>
There were some file name changes in the tree. coreboot_ram.debug
should now be ramstage.debug. It should be sitting in the
build/cbfs/fallback/ directory.
Hope that helps.
-Aaron
>
>
>
>
>
>
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
2015-07-18 9:03 GMT+02:00 Kevin Wilson <wkevils(a)gmail.com>:
> Is there a way, from a device running Linux, to which I have access
> to the command line, to know
> whether the BIOS is coreboot or not ? by some utility, or by some sysfs entry ?
We usually have coreboot related vendor names for ACPI tables (eg.
dsdt table id 'COREBOOT'). Those are visible early on in dmesg, I
think.
Also our cbmem utility (coreboot source tree, util/cbmem) can print a
coreboot specific table's content.
Neither of these are guaranteed to be around (it would be possible to
cloak things thoroughly), but it's likely that they are on coreboot,
and pretty much non-existent otherwise.
Patrick
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
Hello,
Is there a way, from a device running Linux, to which I have access
to the command line, to know
whether the BIOS is coreboot or not ? by some utility, or by some sysfs entry ?
Regards,
Kevin
On Fri, Jul 17, 2015 at 3:13 PM, ron minnich <rminnich(a)gmail.com> wrote:
> we're going to support unaligned accesses, they make it easy. I think it's
> silly that have data structs that are not 64-bit aligned, however :-)
Of course. Unfortunately they're usually embedded in age-old
specifications that are extremely hard or impossible to change. ;)
(USB is another prime example that comes to mind... they just *had* to
put those LE16s in the weirdest places for no reason.)
we're going to support unaligned accesses, they make it easy. I think it's
silly that have data structs that are not 64-bit aligned, however :-)
ron
On Fri, Jul 17, 2015 at 3:05 PM Julius Werner <jwerner(a)chromium.org> wrote:
> Is there no way to make RISCV support unaligned accesses? There's a
> bunch of things in coreboot (and especially libpayload) that depend on
> it. I think that it generally makes code look much simpler (and run
> faster) if you can assume that it's supported across the board.
>
> If we do need to make CBFS unaligned access aware, we should do it
> with some inline functions that fold into a simple read on the
> platforms that support them in hardware.
>
> (Depending on how many such accesses you have and what your context
> switch costs are, it might also be feasible to emulate it in an
> exception handler... that way you wouldn't need to hunt down every
> single occurrence we've accumulated over the years.)
>
