I completely agree with Ron (Ron, don't say that I in some cases do not
agree with you ;-] ).
My ad-hoc very rough estimations will be that you'll shrink around 30/40%
of code, but introducing two (virtual) levels of abstraction with (about)
three levels of inheritance for real classes will slow down boot time for
at least 30%.
Not to mention effort to do this. Not even worth thinking... The rule of
thumb is that system SW is written in low level languages (ASM, C).
Let us leave C++ to application guys. ;-)
Zoran
On Sat, Jan 28, 2017 at 5:59 PM, ron minnich <rminnich(a)gmail.com> wrote:
>
>
> On Sat, Jan 28, 2017 at 6:14 AM Philipp Stanner <stanner(a)posteo.de> wrote:
>
>> Could coreboot (or parts of it) be written in C++?
>>
>
> I hope not.
>
>
>>
>> What would be the advantages and disadvantages?
>>
>>
>
> I can't think of a single one, and I see a lot of C++.
>
> Note that there are parts of coreboot written in Ada. I don't like Ada
> that much, but it's a better language for safe software than C++.
>
> ron
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
On Sat, 28 Jan 2017 17:01:05 +0100
Zoran Stojsavljevic <zoran.stojsavljevic(a)gmail.com> wrote:
> Hello Stefan,
>
> Let me ask you for some other stuff, since I would like to put what I wrote
> initially to hold (sleep state, for now).
>
> You wrote: *The official specs are not trustworthy IMHO and cpuid(1) and
> /proc/cpuinfo **show the same physical address width of 36 bits (which
> would indicate a **maximum of 64 GB).*
>
> Question to you: are you dealing with i686 kernel, (32 bit)? It seems to me
> that you have Nehalem which complies in IA32 with PAE HW extension, don't
> you?!
>
> This is very important -> *Enabling PAE (by setting bit 5, PAE, of the
> system register CR4) causes major changes to this scheme...*
>
Both CPUs have PAE support, yes, but I think I have never even tried to
boot a 32-bit kernel on them :) However, cpuid with an x86_64 kernel shows
(assumably via the cpuid op and edx):
physical address extensions = true
But that does only indicate support not use of PAE... I don't see how
this would be relevant to memtest or the 64-bit kernels anyway.
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
Hello everyone,
we are currently planning to host a coreboot conference in Germany with 2 days
of talks and an additional 2 days of hacking.
The date will probably either be October 19-22 or October 26-29, i.e. directly
before or after Embedded Linux Conference Europe and LinuxCon Europe.
Ticket prices haven't been decided yet and depend on the location and venue
availability.
The location will be either in Bonn or Bochum. Both Bochum and Bonn offer a
variety of interesting activities for conference participants.
Bochum is reachable by public transport from Frankfurt Airport within 120
minutes, from Dusseldorf Airport within 40 minutes and from Cologne Airport
within 80 minutes.
Bonn is reachable by public transport from Frankfurt Airport within 70
minutes, from Dusseldorf Airport within 70 minutes and from Cologne Airport
within 30 minutes.
YOUR ACTION NEEDED!
Please fill out the application and subscribe to the newsletter if you are
planning to join us!
https://www.coreboot.org/events/ecc2017
Sincerely,
--
Hailfinger, Carl-Daniel
_________________________________________
Section CK 14 - Cyber Security in Operating Systems and Applications
Federal Office for Information Security (BSI)
Godesberger Allee 185-189
53175 Bonn, Germany
phone: +49 (0)228 9582-5939
fax: +49 (0)228 9582-5400
e-mail: coreboot-conference(a)bsi.bund.de
internet: www.bsi.bund.de
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/25/2017 11:26 AM, Aaron Durbin wrote:
> On Wed, Jan 25, 2017 at 11:24 AM, Timothy Pearson
> <tpearson(a)raptorengineering.com> wrote:
> On 01/24/2017 10:55 PM, Taiidan(a)gmx.com wrote:
>>>> I know the 63xx has a very fatal NMI exploit, but according to the
>>>> libreboot (oh no) website the 62xx works safely out of the box without
>>>> microcode however I would like to confirm if this is actually true.
>>>>
>>>> I looked at the errata .pdf from the AMD website but I didn't see
>>>> anything that seemed significant.
>>>>
>>>>
>
> As far as we have been able to determine it does, again with the caveat
> that this is without microcode _updates_, not without microcode. There
> is still the off chance that these CPUs ship with a backdoor inside the
> burnt microcode ROM that is patched out with an update. Unlike POWER
> and ARM we are solely dependent on the vendor being trustworthy enough
> to disclose issues in their errata document; outside of that, there is
> simply no feasible way to know for certain what bugs are lurking inside
> the CPU.
>
>> POWER and ARM parts can have microcode too. That's up to the
>> implementation. I'm not sure how you can distinguish the difference.
>> Because one posts an update vs others never indicating there is an
>> update? Even if parts have no microcode, there's a possibility of
>> backdoors baked into the silicon. In all situations one needs to trust
>> the vendor.
I am definitely aware of that; the difference is that with POWER the
microcode is open (though documentation is lacking), and most of the
mainstream ARM implementations lack microcode.
In general our policy is to update the microcode for exactly the reason
given above -- at some point you do have to trust the hardware created
by the manufacturer, and microcode (traditional horizontal microcode,
anyway) is highly unlikely to contain the types of security flaws (or
even intentional backdoors) that have become so common in closed
firmware binaries. No one* is going to take the time to create a
meaningful microcode-based backdoor that can only target one CPU line
when you can create a platform agnostic backdoor with remote access
functionality using the boot or secondary engine firmware instead.
Just my $0.02. :-)
* No one outside of a high level state actor, at any rate!
- --
coreboot mailing list: coreboot(a)coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot
- --
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJYiOEtAAoJEK+E3vEXDOFbdZ8IALnb0ZSzZDHUmfFlEBfOfj4d
MLk2X9tQPs4MyOVPMOpkp6EIQe6NvmC9mgs/+ly6QhhoB7WkaX2cZBtN5GvvUaS4
zZRVv9HSJhMDN63fe6GR3tYxwrU6K8HdxpFVRrvZMqnPhwiS8g+RmsD3RuA3+rWH
tVvuAAQdZB7+sqbqa8Kp+HnqEGpGaApc9TLoduQTgstJCN4oaYx1x5TntdtW7qaZ
2jxrnykW7drEDRQ0UtmF1rxEOsRWebhd8Ex4mgjM7YWv5ZMvVEG4mHPpFMNcobqU
UfRw7RI2kCaEmBD9c4HaRoIt6PyDU1PG53wbM80g9agXF/v/VeXWas0bzqy2UXw=
=hCLy
-----END PGP SIGNATURE-----
On Sat, 28 Jan 2017 17:01:09 +0300
Andrey Korolyov <andrey(a)xdel.ru> wrote:
> > The chipset in the (QC version of the) W510 is actually exactly the same as
> > in the X201 and T410s: Ibex Peak.
> >
>
> But CPUs we are looking at *are* actually different
Of course - I did not bring up chipsets ;) I am also not implying that
it should work on Arrandale but I'd like to know why it doesn't and the
usual "it doesnt support it" as seen around the internet (and
apparently even here) does not cut it :)
> - scale-down could
> mean an exposure of a previously unaccounted design issue which
> actually prevented 32nm CPU 'upgrade' to work reliably with >8G of
> RAM... And AFAIR nobody ever reported to break official memory limits
> within an entire family, I`ll be happy to know that this is not true.
Not sure if I interpret "within an entire family" correctly, but the
online specs for the 820QM are clearly wrong:
https://ark.intel.com/products/43124/Intel-Core-i7-820QM-Processor-8M-Cache…
The datasheet (320765) is a bit more correct because it leaves room
for interpretation:
* Using 2-Gb device technologies, the largest memory capacity possible
is 8 GB, assuming dual-channel mode with two x8, double-sided,
un-buffered, non-ECC, SO-DIMM memory configuration."
* Up to 32 simultaneous open pages, 16 per channel (assuming 4 Ranks
of 8 Bank Devices)
The ICs on my 8 GB DIMMs are 4 Gb (Hynix H5TC4G83BFR and whatever
Kingston uses on their KVR16LS11/8 DIMMs but clearly specified as 4 Gb
chips).
Now... guess what the datasheet of corresponding to the i5-520m (322812)
states. Exactly the same as above. I can see some other memory-related
differences (e.g., regarding support for 1333 MT/s that's only
available on the i7) though but nothing related to memory organization,
addressing or the like (but the datasheets are very superficial
regarding the memory controller as all corebooters know).
So of course the CPUs are not equal and of course the manufacturing
process or small changes in the design *could* make the difference but
it is all but clear from the public documentation what the true maximum
is - at least for me. And I don't yet accept that it is an
architectural/digital design problem.
> Just to add .02c - DDR3 interposers from tek/futureplus are appearing
> on ebay relatively frequently and for moderate price, so if someone
> has will to spend some effort on this task, the analyzer coupled with
> interposer could provide great help, with regard to unstable behavior
> with a single 8G DIMM.
Definitely not worth it for this 7+ year old hardware (unless someone
has a suitable scope and the knowledge already... the best scope I have
access to is an Agilent MSO6104A but no idea where to even start - and
no interposer obviously) but you seem to imply that the 8GB problem is
an analogous one... do you think about the 16 GB problem as well?
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
On Sun, 22 Jan 2017 12:33:08 +0100
Zoran Stojsavljevic <zoran.stojsavljevic(a)gmail.com> wrote:
> Hello Stefan,
>
> In addition what Charlotte wrote to you, I would advise you the following
> (as general approach for mem problems):
> [1] Please, for testing the memory, use secondary Coreboot payload called
> MEMTEST:
> [user@localhost coreboot]$ cat .config | grep MEMTEST
> CONFIG_MEMTEST_SECONDARY_PAYLOAD=y
> CONFIG_MEMTEST_STABLE=y
> # CONFIG_MEMTEST_MASTER is not set
>
> Instead going to SeaBIOS or GRUB2 as payloads. This memtest86+ could (my
> best guess) show to you what is wrong with your memory configuration.
>
> [2] You can also (since you are able to in some cases go to Linux) stop in
> GRUB2, after installing from Linux memtest86+ package into the GRUB2 boot
> options (this can also help too, my best guess).
>
> (extra advise: if you use legacy/CSM ON, which is in Coreboot in 99.999%
> cases used, it would be much easier for you to deal with memtest86+)
Hi Zoran,
I am not exactly sure what you are trying to convey. I mentioned
that memtest did lock up after some seconds with the vendor firmware in
my previous mail. Of course it's the first thing to try when memory
problems arise - I just tried to boot Linux to retrieve the e820 map
because Nico requested it on IRC. I presume that using memtest as
primary or secondary payload or booted from GRUB2 would not produce
different results (unless the binaries are different of course), no?
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
On Sat, 21 Jan 2017 18:46:00 -0500
Charlotte Plusplus <pluspluscharlotte(a)gmail.com> wrote:
> Addressing over 8G is not supported by the chipset used on nehalem thinkpad
> laptops (X201)
>
> Stupid limitation, but it is not the CPU fault.
Please don't spread FUD if you don't know what you are talking about.
Neither the RAM in the T410s nor the one in the X201 is even connected
to what remains of the "chipset" i.e. the southbridge in form of the
PCH/southbridge but directly to the memory controller in the CPU. The
chipset in the (QC version of the) W510 is actually exactly the same as
in the X201 and T410s: Ibex Peak.
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
2017-01-26 16:12 GMT+01:00 ron minnich <rminnich(a)gmail.com>:
>
> A decade later? You should buy a new computer.
Core 2 duo is more than a decade old and I think that it should be
good enough for a lot of tasks.
Andrés
I'm not really sure what's going on, and without a debug console, it's
kind of hard to tell.
Here are some random thoughts to give you ideas for what you might
want to try next:
Does the system boot up otherwise? Is it possible to ssh into it to
get the log out with the cbmem utility? That would definitely help.
You might try a different payload to see if a different USB stack
works better for you. Since I'm not sure what the problem is, I'm not
sure why this might help.
You could also try downloading and building SeaBIOS separately, then
including the binary as an elf. This would allow you to play with the
configuration a bit more. You can copy the .config out of
coreboot/payloads/external/SeaBIOS/seabios.
Also, in your coreboot config, you might try turning off the "Serial
Port on SuperIO" under "Generic drivers". It's still trying to send
data out to the serial port even though you don't have one. This
probably won't change much else, but it will speed up your boot times.
Having it on tells SeaBIOS to send the the boot log out of serial as
well.
Martin
On Thu, Jan 26, 2017 at 3:11 AM, Maxim Gusev <mail(a)maximgusev.com> wrote:
> It is very strange, but my keyboard doesn't work.
> I have tried to connect another keyboard - LEDs blinked 20 percent of cases
> and also diesn't work.
>
> I took your advice Martin and increased the delay (200, 500, 5000) - didn't
> help.
> cbfstool coreboot.rom add-int -i 200 -n "etc/usb-time-sigatt"
> Unfortunately I don't have the PS/2 keyboard:(
>
> Regards
> Maxim
>
>
> -------- Original Message --------
> Subject: Re: [coreboot] Coreboot binary for ASUS F2A85-M
> Local Time: 24 Января 2017 г. 10:17 вечера
> UTC Time: 24 Января 2017 г. 19:17
> From: gaumless(a)gmail.com
> To: Maxim Gusev <mail(a)maximgusev.com>
> Daniel Kulesz <daniel.ina1(a)googlemail.com>, Kyösti Mälkki
> <kyosti.malkki(a)gmail.com>, hackurx(a)opensec.fr <hackurx(a)opensec.fr>,
> coreboot(a)coreboot.org <coreboot(a)coreboot.org>
>
> Using your ROM, I'm getting USB keyboard in both grub and linux.
>
> You might try setting SeaBIOS's usb-time-sigatt to something higher
> than 100: https://www.seabios.org/Runtime_config
>
> "The USB2 specification requires devices to signal that they are
> attached within 100ms of the USB port being powered on. Some USB
> devices are known to require more time. Prior to receiving an
> attachment signal there is no way to know if a USB port is empty or if
> it has a device attached. One may specify an amount of time here (in
> milliseconds, default 100) to wait for a USB device attachment signal.
> Increasing this value will also increase the overall machine bootup
> time."
>
> Here's the command to add a 200ms wait to your rom:
> cbfstool coreboot.rom add-int -i 200 -n "etc/usb-time-sigatt"
>
> Martin
>
> On Tue, Jan 24, 2017 at 9:55 AM, Maxim Gusev <mail(a)maximgusev.com> wrote:
>> Hi, Martin, Daniel, Kyösti, Loic,
>> Hi, friends
>>
>> The problem was in the programmer which programmed incorrectly.
>> Now I see the post codes and SeaBIOS works.
>> Also as you mentioned, it is important to put the memory in the slot
>> furthest away from the processor,
>> I have only one memory module and otherwise the system doesn't work.
>>
>> "As was mentioned by Daniel, you don't need the external
>> card's VBIOS built into the rom. If you're using SeaBIOS, it will
>> read the vbios directly from the card."
>>
>> You are right, in this case all is working, otherwise - doesn't (shouldn't
>> use VGAbios from the Internet in my case).
>>
>> Now my keyboard does not work (Logitech Y-UL76). I have tried in all slots
>> (even using 10 pin to usb adapter).
>> The power seems to be there, because the mouse once blinked when it was
>> connected-disconnected.
>> Usb settings enabled in config, as I understand. Please help to fix.
>>
>> Here is my config and binary (attached to the e-mail).
>> Config: http://pastebin.com/BYgiLabA
>>
>> Thank you very much!
>> Maxim
>> Tried in all slots (even using adapter 10 pin usb)
>>
>> -------- Original Message --------
>> Subject: Re: [coreboot] Coreboot binary for ASUS F2A85-M
>> Local Time: 24 Января 2017 г. 3:29 ночи
>> UTC Time: 24 Января 2017 г. 00:29
>> From: gaumless(a)gmail.com
>> To: Maxim Gusev <mail(a)maximgusev.com>
>> Daniel Kulesz <daniel.ina1(a)googlemail.com>, coreboot(a)coreboot.org
>> <coreboot(a)coreboot.org>
>>
>> Hi Maxim,
>> Try this: Remove all of the memory in the board except for one DIMM
>> in the slot furthest away from the processor. AGESA on this chip has
>> a requirement (that some vendors apparently worked around) that DIMMs
>> be populated from the furthest slot to the closest.
>>
>> It looks like the code to route Port 80h to PCI isn't in that
>> chipset. That's something we should check before giving that option.
>>
>> As was mentioned by Daniel, you don't need (or want) the external
>> card's VBIOS built into the rom. If you're using SeaBIOS, it will
>> read the vbios directly from the card.
>>
>> If these steps don't help, I'll work with you to get a rom that boots for
>> you.
>>
>> Martin
>>
>> On Mon, Jan 23, 2017 at 3:12 PM, Maxim Gusev via coreboot
>> <coreboot(a)coreboot.org> wrote:
>>> Thank you for advise about pc speaker console! I will try it today.
>>> I am using CH341A programmer and its soft of 1.18 version. Also i am
>>> using
>>> the original WINBOND W25Q64BV 8mb chip.
>>> Yes, if I flash back the original UEFI ROM onto the chip - the system
>>> start
>>> up again.
>>>
>>> Maxim
>>>
>>>
>>> -------- Original Message --------
>>> Subject: Re: [coreboot] Coreboot binary for ASUS F2A85-M
>>> Local Time: 23 Января 2017 г. 11:03 вечера
>>> UTC Time: 23 Января 2017 г. 20:03
>>> From: daniel.ina1(a)googlemail.com
>>> To: Maxim Gusev <mail(a)maximgusev.com>
>>> coreboot(a)coreboot.org <coreboot(a)coreboot.org>
>>>
>>> My F2A85-M is currently down, so I can't test it with your config - sorry
>>> (but maybe in two days or so). But one more thing you could try is the pc
>>> speaker console:
>>>
>>> https://www.coreboot.org/Spkmodem
>>>
>>> At least, if it starts beeping this would be already a good sign.
>>>
>>> Btw.: How did you actually flash coreboot onto the chip? And did you use
>>> the
>>> original BIOS chip? If not, did you make sure your other chip is also 8M
>>> in
>>> size? If you flash back the original ROM onto the chip - does the system
>>> start up again?
>>>
>>> Cheers, Daniel
>>>
>>>
>>> On Mon, 23 Jan 2017 14:16:25 -0500
>>> Maxim Gusev <mail(a)maximgusev.com> wrote:
>>>
>>>> I tried different ways to initialize the VGA card - does not work.
>>>> I also tried with your config file - did not work (as I remember, it was
>>>> further suggested in the manual mode to complete the configuration).
>>>> Here is my config file: http://pastebin.com/RVLcGku8
>>>> I have a feeling that coreboot is programmed or read (from the spi
>>>> flash)
>>>> to the wrong address,
>>>> although it is unlikely because it is, as I understand it, is written in
>>>> the mainboard sources, and I never touched them.
>>>>
>>>>
>>>>
>>>>
>>>> -------- Original Message --------
>>>> Subject: Re: [coreboot] Coreboot binary for ASUS F2A85-M
>>>> Local Time: 23 Января 2017 г. 10:01 вечера
>>>> UTC Time: 23 Января 2017 г. 19:01
>>>> From: daniel.ina1(a)googlemail.com
>>>> To: Maxim Gusev <mail(a)maximgusev.com>
>>>> Kyösti Mälkki <kyosti.malkki(a)gmail.com>, coreboot(a)coreboot.org
>>>> <coreboot(a)coreboot.org>
>>>>
>>>> On Mon, 23 Jan 2017 15:51:16 +0200
>>>> Kyösti Mälkki <kyosti.malkki(a)gmail.com> wrote:
>>>>
>>>> > On Mon, Jan 23, 2017 at 2:41 PM, Maxim Gusev via coreboot <
>>>> > coreboot(a)coreboot.org> wrote:
>>>> >
>>>> > > Hi Daniel,
>>>> > >
>>>> > > Now I have compiled coreboot 4.5 with the SeaBIOS 1.9.3 as a payload
>>>> > > and
>>>> > > the VGAbios:
>>>> > > I am using the Asus EN8600GT as a videocard (PCIe) and I took out
>>>> > > the
>>>> > > binary here:
>>>> > > https://www.techpowerup.com/vgabios/?architecture=&
>>>> > > manufacturer=Asus&model=8600+GT&interface=PCI-E&memType=&
>>>> > > memSize=256&since=
>>>> > >
>>>>
>>>> To my understanding, when using an external graphics card you don't need
>>>> to extract or put any VGA blobs in. But you need to initialize the PCIe
>>>> video. Can you provide us with the full config you are using, please? Or
>>>> did
>>>> you try my config which I linked in my initial answer? (There, it should
>>>> be
>>>> already enabled as far as I remember)
>>>>
>>>> > > Also I have turned on in console settings "Show POST codes...", but
>>>> > > there
>>>> > > is nothing works:(
>>>> > >
>>>> >
>>>> > You probably also need POST_DEVICE_PCI_PCIE set in your .config. In
>>>> > menuconfig: "Device to send POST codes to" -> "PCI/PCIe".
>>>> >
>>>> > As for the serial port: I think this mainboard is not a retail
>>>> > version,
>>>> > but
>>>> > came from ASUS Essentio Desktop PC CM1745.
>>>> >
>>>> >
>>>> >
>>>> > http://www.ascendtech.us/asus-f2a85-m-cm1745-dp-motherboard_i_mb90mibiw5g0x…
>>>> >
>>>> > Looks like RS232 level translator ICs are also missing and some other
>>>> > differences on BOM too.
>>>> >
>>>>
>>>> Indeed, there seem to be different versions of the board then. I have
>>>> the
>>>> retail version, and mine has the connectors soldered. Can someone update
>>>> the
>>>> wiki, please?
>>>>
>>>> Cheers, Daniel
>>>
>>>
>>>
>>> --
>>> coreboot mailing list: coreboot(a)coreboot.org
>>> https://www.coreboot.org/mailman/listinfo/coreboot
>>
>>
>
>
