[coreboot] ECS 651-M V1.0 is supported?

[Olaf HB]

Hi. I would like to know if the ECS 651-M V1.0 motherboard is supported
in coreboot or could it be supported?

Specs:

Socket 478 for latest Intel Pentium 4 / Celeron processor

SiS® 650GX B0 & 962L
North Bridge: SiS® 650GX B0
South Bridge: SiS® 962L

SYSTEM BIOS 

Award BIOS with 2Mb Flash ROM  (soldered to board)
Supports Plug and Play 1.0A, APM 1.2, Multi Boot, DMI
Supports ACPI revision 1.0 specification


Super I/O chip: ITE it8705f

Link to product:
http://www.ecs.com.tw/ECSWebSite/Product/Product_SPEC.aspx?DetailID=362
=1=Feature=24=0

lspci and flashrom output is attached in email.


Greetings.


flashrom v0.9.8-r1888 on Linux 4.4.85 (i686)
flashrom is free software, get the source code at http://www.flashrom.org

flashrom was built with libpci 3.4.1, GCC 4.9.4, little endian
Command line (3 args): flashrom -p internal -V
Calibrating delay loop... OS timer resolution is 1 usecs, 2088M loops per 
second, 10 myus = 10 us, 100 myus = 99 us, 1000 myus = 994 us, 1 myus = 
9954 us, 4 myus = 4 us, OK.
Initializing internal programmer
No coreboot table found.
Using Internal DMI decoder.
DMI string chassis-type: "Desktop"
DMI string system-manufacturer: " "
DMI string system-product-name: " "
DMI string system-version: " "
DMI string baseboard-manufacturer: " "
DMI string baseboard-product-name: "SiS-650GX"
DMI string baseboard-version: " "
Found ITE Super I/O, ID 0x8705 on port 0x2e
Found ITE Super I/O, ID 0x8705 on port 0x4e
Found chipset "SiS 650" with PCI ID 1039:0650.
Enabling flash write... Found southbridge 1039:0962 at 00:02:0
OK.
Enabling IT8705F flash ROM interface write.
Maximum IT8705F parallel flash decode size is 524288.
Enabling IT8705F flash ROM interface write.
Maximum IT8705F parallel flash decode size is 524288.
The following protocols are supported: Parallel.
Probing for AMD Am29F010A/B, 128 kB: probe_jedec_common: id1 0x18, id2 0x97, 
id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for AMD Am29F002(N)BB, 256 kB: probe_jedec_common: id1 0x23, id2 0xe4, 
id1 is normal flash content, id2 is normal flash content
Probing for AMD Am29F002(N)BT, 256 kB: probe_jedec_common: id1 0x23, id2 0xe4, 
id1 is normal flash content, id2 is normal flash content
Probing for AMD Am29F016D, 2048 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 
parity violation, id1 is normal flash content, id2 is normal flash content
Probing for AMD Am29F040B, 512 kB: probe_jedec_common: id1 0x23, id2 0xe4, id1 
is normal flash content, id2 is normal flash content
Probing for AMD Am29F080B, 1024 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 
parity violation, id1 is normal flash content, id2 is normal flash content
Probing for AMD Am29LV001BB, 128 kB: probe_jedec_common: id1 0x18, id2 0x97, 
id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for AMD Am29LV001BT, 128 kB: probe_jedec_common: id1 0x18, id2 0x97, 
id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for AMD Am29LV002BB, 256 kB: probe_jedec_common: id1 0x23, id2 0xe4, 
id1 is normal flash content, id2 is normal flash content
Probing for AMD Am29LV002BT, 256 kB: probe_jedec_common: id1 0x23, id2 0xe4, 
id1 is normal flash content, id2 is normal flash content
Probing for AMD Am29LV004BB, 512 kB: probe_jedec_common: id1 0x23, id2 0xe4, 
id1 is normal flash content, id2 is normal flash content
Probing for AMD Am29LV004BT, 512 kB: probe_jedec_common: id1 0x23, id2 0xe4, 
id1 is normal flash content, id2 is normal flash content
Probing for AMD Am29LV008BB, 1024 kB: probe_jedec_common: id1 0xff, id2 0xff, 
id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for AMD Am29LV008BT, 1024 kB: probe_jedec_common: id1 0xff, id2 0xff, 
id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for AMD Am29LV040B, 512 kB: probe_jedec_common: id1 0x23, id2 0xe4, id1 
is normal flash content, id2 is normal flash content
Probing for AMD Am29LV081B, 1024 kB: probe_jedec_common: id1 0xff, id2 0xff, 
id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for AMIC A29002B, 256 kB: probe_jedec_common: id1 0x23, id2 0xe4, id1 
is normal flash content, id2 is normal flash content
Probing for AMIC A29002T, 256 kB: probe_jedec_common: id1 0x23, id2 0xe4, id1 
is normal flash content, id2 is normal flash content
Probing for AMIC A29040B, 512 kB: probe_jedec_common: id1 0x23, id2 0xe4, id1 
is normal flash content, id2 is normal flash content
Probing for Atmel AT29C512, 64 kB: probe_jedec_common: id1 0xda, id2 0x0b
Probing for Atmel AT29C010A, 128 kB: probe_jedec_common: id1 0xda, id2 0x0b
Probing for Atmel AT29C020, 256 kB: probe_jedec_common: id1 0xda, id2 0x0b
Probing for Atmel AT29C040A, 512 kB: probe_jedec_common: id1 0xda, id2 0x0b
Probing for Atmel AT49BV512, 64 kB: probe_jedec_common: id1 0xda, id2 0x0b
Probing for Atmel AT49F002(N), 256 kB: 

Re: [coreboot] Need help implementing romstage CBMEM

[Kyösti Mälkki]

On Wed, Aug 30, 2017 at 11:39 PM, Keith Hui  wrote:
> Hi guys,
>
> I'm still hard at work over the venerable (even "almighty" at the
> time) 440BX and Slot 1 boards.
>
> [1] https://review.coreboot.org/c/20977/
>
> And now I'm stuck and thoroughly confused.
>
> My current state is:
> 1. cbmem_initialize_empty() failed to even start allocating the root
> CBMEM entry. No indication why. I tried tracing the code path in the
> sources and still could not find out where exactly it failed. With
> enough fiddling I did get it to complain the way Aaron expected [1].

Please update your work in gerrit, showing all the actual code changes
you try to boot with. This includes changes under mainboard/.

> 2. Using the common Intel CPU cache_as_ram.inc, I can get through
> mainboard romstage and memory init. If I just return a fixed
> CONFIG_TOPMEM in setup_stack_and_mtrrs() like what was done in
> cpu/intel/nehalem, it got past the point of POST_PREPARE_RAMSTAGE and
> then nothing.

All that setup_stack_and_mtrrs() is not really required for
EARLY_CBMEM_INIT, leave all that as followup work. Use unmodified
car/romstage_legacy.c and car/cache_as_ram.inc with that
DCACHE_RAM_BASE fixed.

Disable CBMEM console and timestamps for the time being, as those eat
a lot of your CAR allocation. Those may have smashed your stack in CAR
to the extent of breaking raminit.

> 3. Porting the postcar frame assembly from
> cpu/intel/car/cache_as_ram_ht.inc results in a failure somewhere
> before loading ramstage and after

Push your modified source to gerrit if you want comments on that.

> 4. If I try to run this build under QEMU, it fails with "Trying to
> execute code outside RAM or ROM at 0x000a" in 440BX RAM init code
> after dumping the "before" northbridge config, so I can't correctly
> debug it this way either.

Just forget about using QEMU for the task at hand.

Kyösti

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[taii...@gmx.com]

On 08/30/2017 03:28 PM, Timothy Pearson wrote:


POWER9 workstations are already coming on the market:

https://raptorcs.com/TALOSII/

Note that IBM selling similar machines directly would likely be more
expensive, not less, based on POWER8 price comparisons between IBM and
other vendors.  People purchase IBM branded products for extreme
reliability, not to get cheap equipment...
Damn that is sick as hell! you guys actually pulled it off! how did you 
get the funding? how have I not heard about this before?


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Need help implementing romstage CBMEM

[Keith Hui]

Hi guys,

I'm still hard at work over the venerable (even "almighty" at the
time) 440BX and Slot 1 boards.

[1] https://review.coreboot.org/c/20977/

And now I'm stuck and thoroughly confused.

My current state is:
1. cbmem_initialize_empty() failed to even start allocating the root
CBMEM entry. No indication why. I tried tracing the code path in the
sources and still could not find out where exactly it failed. With
enough fiddling I did get it to complain the way Aaron expected [1].
2. Using the common Intel CPU cache_as_ram.inc, I can get through
mainboard romstage and memory init. If I just return a fixed
CONFIG_TOPMEM in setup_stack_and_mtrrs() like what was done in
cpu/intel/nehalem, it got past the point of POST_PREPARE_RAMSTAGE and
then nothing.
3. Porting the postcar frame assembly from
cpu/intel/car/cache_as_ram_ht.inc results in a failure somewhere
before loading ramstage and after
4. If I try to run this build under QEMU, it fails with "Trying to
execute code outside RAM or ROM at 0x000a" in 440BX RAM init code
after dumping the "before" northbridge config, so I can't correctly
debug it this way either.

I think there's still not clear enough description on how this dynamic
CBMEM allocation works. Below is my take and I'll stand readily to be
corrected:

1. Reset vector -> protected mode -> southbridge bootblock init for
ROM -> bootblock walks CBFS to find romstage.
2. CAR setup in cpu/intel/car/cache_as_ram.inc
3. romstage_main() -> sets up a stack guard ->
mainboard_romstage_entry() -> check for overunning of said stack guard
4. romstage calls cbmem_initialize_empty()
5. Somewhere along the cbmem_initialize() path cbmem_top() is called
to find out where top of RAM is. It is supposed to allocate memory so
that it grows down from here.
6. setup_stack_and_mtrrs() -> allocates a 20KB postcar stack on CBMEM
and adds MTRR settings as appropriate. These gets pushed onto the
postcar stack in order of popping:

maximum number of supported variable MTRRs <- bottom of stack
number of actual used MTRRs
MTRR 0 base, low 32 bits
MTRR 0 base, high 32 bits
MTRR 0 mask, low 32 bits
MTRR 0 mask, high 32 bits
...

And this stack should be in RAM, supposedly in an area allocated within CBMEM.

7. This postcar stack pointer is returned via romstage_main(). It gets
loaded into %esp, effectively switching the code into a RAM stack with
all the MTRRs info on it.
8. Tear down CAR.
9. Wipes all the MTRRs.
10. MTRR values are popped off the stack and loaded into the variable MTRRs.
11. Now the CPU should be at the top of the allocated RAM stack and
can move on to load the ramstage.

The sources say for step 5 "the number of entries depends on the size
between down-aligned (by 4k) version and the actual top of memory. I
thought cbmem_top() should return the actual bytes of available memory
and is already aligned and I'd end up with room for zero entries? And
if I just return the actual top of memory cbmem_top() for use a the
romstage stack, would it not overwrite the cbmem area?

Also how much room is there to consolidate the CAR setup and teardown
code and/or move more of it into C?

All the Slot 1 CPUs are in the P6 family and have 16KB L1 data cache
that is 4-way set associative. Can I use a full 16K range for CAR or I
can only use 4K (16K/4) of it? cache_as_ram.inc use a fixed MTRR that
tops out at address 0xD while cache_as_ram_ht.inc uses variable
MTRR 0 for this range. Variable MTRR 1 is used in both to cache the
ROM. But when I tried to port the latter approach over the code dies
doing it. Some Slot 1 CPUs have a very complicated L2 enable code
which is better left where it is so I'd like to limit myself to L1
cache at this stage.

Sorry if I am not making sense, because this is not making sense to me
either, so any help is appreciated.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Felipe Sanches]

Try this backup copy from the Internet Archive:

https://web.archive.org/web/20121211162830/fm.csl.sri.com/LAW/2009/dobry-law09-HAP-Challenges.pdf

2017-08-30 1:00 GMT-03:00 taii...@gmx.com :

> I can't download the .pdf file for some reason (maybe the tla's got to it?)
> http://fm.csl.sri.com/LAW/2009/dobry-law09-HAP-Challenges.pdf
> can someone send it to me?
> Thanks
>
>
> Thoughts:
> Sad this is still not an actual method of disablement, but it doesn't
> really matter as anyone who buys *new* x86 hardware is still supporting
> wintel's development of newer and better anti-features, DRM and
> surveillance technology - one that can't even be me-cleaner/hap/etc nerfed
> will be released some day. I wish people spent their energy popularizing
> owner controlled arches instead of beating a dead horse.
>
> While IBM also makes surveillance tech they make POWER which as the last
> performance owner controlled arch that sells for attainable prices goes a
> long way to offset that. Heres to hoping IBM starts selling POWER
> workstations...
>
> I find it hard to believe that the NSA uses made in china intel stuff with
> ME chips present for their high security stuff (hap nerfed or not), I
> imagine top secret things are done on POWER (which has a USA cpu fab and no
> black boxes).
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/29/2017 11:00 PM, taii...@gmx.com wrote:
> I can't download the .pdf file for some reason (maybe the tla's got to it?)
> http://fm.csl.sri.com/LAW/2009/dobry-law09-HAP-Challenges.pdf
> can someone send it to me?
> Thanks
> 
> 
> Thoughts:
> Sad this is still not an actual method of disablement, but it doesn't
> really matter as anyone who buys *new* x86 hardware is still supporting
> wintel's development of newer and better anti-features, DRM and
> surveillance technology - one that can't even be me-cleaner/hap/etc
> nerfed will be released some day. I wish people spent their energy
> popularizing owner controlled arches instead of beating a dead horse.
> 
> While IBM also makes surveillance tech they make POWER which as the last
> performance owner controlled arch that sells for attainable prices goes
> a long way to offset that. Heres to hoping IBM starts selling POWER
> workstations...

POWER9 workstations are already coming on the market:

https://raptorcs.com/TALOSII/

Note that IBM selling similar machines directly would likely be more
expensive, not less, based on POWER8 price comparisons between IBM and
other vendors.  People purchase IBM branded products for extreme
reliability, not to get cheap equipment...

> I find it hard to believe that the NSA uses made in china intel stuff
> with ME chips present for their high security stuff (hap nerfed or not),
> I imagine top secret things are done on POWER (which has a USA cpu fab
> and no black boxes).
> 


- -- 
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/

iQEcBAEBAgAGBQJZpxHDAAoJEK+E3vEXDOFbTGAH/2U1dDPoJiCIomYsD0RFox9F
O9voeIPARbsbobv6Yvl/VmAI40D81w5u/7vdk6mO//zFJXpeEpLTgytBqZlDORRV
CfnTG/etE/i8ShGgcvWCf6uqEiVdko4ng+gwh5oeQJ/WFdGlVFmeZbQ+WUwWSbr0
v6icL1SHD3EuCdNbMZimV7tcdglDEULzPHVEHSkhdMGtldWHyBvTuvp6rGAO47O4
lMM5SDXFa9S+ookTuSdLV6F3v4s4GLsmqkyPfNEWdh4iXqA72sZWAsYeyrBBn4fR
dp92uQuqgdeDr6r28YAAA8mkHD/7jbzDcDnmGiMqVyKU0ugDIlqGTvg3OsPiY24=
=C5ac
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Libre KCMA-D8's are going for around $260 on newegg

[Gregg Levine]

Hello!
Suffice to say, I've been elsewhere as well. If anything, I only
bought one thing from that firm. The comments on that page you brought
us is rather critical of that decision.

For my part I also buy the majority of my computer directed
electronics at Micro Center,(A US based firm with many stores in many
states.).  and almost everything else from two other firms, three if
I'd count Adafruit.

For those of us in the US the board prices at Micro Center happen to
be reasonable.
-
Gregg C Levine gregg.drw...@gmail.com
"This signature fought the Time Wars, time and again."


On Wed, Aug 30, 2017 at 9:14 AM, Rene Shuster  wrote:
> I must be living under a rock; totally missed that story:
> https://www.techpowerup.com/226777/newegg-now-owned-by-chinese-company
> (2016-09)
>
> On Wed, Aug 30, 2017 at 1:11 AM, taii...@gmx.com  wrote:
>>
>> NOTE: I have no idea as to how trustworthy these companies are.
>>
>>
>> http://www.officespecialties.com/asus_computer_international_kcma_d8_server_motherboard_217195_prd1.htm?pSearchQueryId=420212
>> Ah even better, $250 and now one doesn't have to support a chinese owned
>> newegg.
>>
>> http://www.unitedoffice.com/pn/KCMAD8/Asus_46/
>> $270 another option
>>
>>
>> http://www.compsource.com/pn/KCMAD8/Asus-46/KcmaD8-Server-Motherboard-KCMAD8/
>> $260
>>
>>

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 BMC port

[Rene Shuster]

Q Who has Self-hosting option?
A
https://en.wikipedia.org/wiki/Comparison_of_source_code_hosting_facilities#Features

On Wed, Aug 30, 2017 at 1:18 AM, taii...@gmx.com  wrote:

> On 08/29/2017 02:24 PM, Timothy Pearson wrote:
>
>> Let me know what you think of the OpenBMC system.  We're considering
>> allowing bugs to be tracked on GitHub; is this something the community
>> wants to see or would a separate Bugzilla type install be preferred?  We
>> want to provide the infrastructure needed for the community to start
>> working with and enhancing this port, so suggestions and comments are
>> welcome!
>>
>> I don't like that nearly everything these days is on too-big-to-fail
> github so I always prefer a self hosted option.
> "Don't put all your eggs in one basket" was forgotten by the massive
> amounts of projects who think that git should = github - at least coreboot
> developers don't think that :D
>
> It is truly excellent to see the rare successful crowdfunding project
> bearing fruit, raptor is making history!
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>



-- 
Tech III * AppControl * Endpoint Protection * Server Maintenance
Buncombe County Schools Technology Department Network Group
ComicSans Awareness Campaign 
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Libre KCMA-D8's are going for around $260 on newegg

[Rene Shuster]

I must be living under a rock; totally missed that story:
https://www.techpowerup.com/226777/newegg-now-owned-by-chinese-company​
(2016-09)

On Wed, Aug 30, 2017 at 1:11 AM, taii...@gmx.com  wrote:

> NOTE: I have no idea as to how trustworthy these companies are.
>
> http://www.officespecialties.com/asus_computer_international
> _kcma_d8_server_motherboard_217195_prd1.htm?pSearchQueryId=420212
> Ah even better, $250 and now one doesn't have to support a chinese owned
> newegg.
>
> http://www.unitedoffice.com/pn/KCMAD8/Asus_46/
> $270 another option
>
> http://www.compsource.com/pn/KCMAD8/Asus-46/KcmaD8-Server-Mo
> therboard-KCMAD8/
> $260
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>



-- 
Tech III * AppControl * Endpoint Protection * Server Maintenance
Buncombe County Schools Technology Department Network Group
ComicSans Awareness Campaign 
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] REPLY: INT 13H

[Peter Stuge]

Zoran, Vincenzo,

BIOS and UEFI have higher privilege in the system than the OS kernel,
which has higher privilege than userland processes, which have higher
privilege than the user.

Any component with higher privilege can override, circumvent or
contradict parts of the system and users with lower privilege levels.

BIOS is x86-specific.

UEFI is arguably not technically superior to BIOS.

UEFI has sadly infected other platforms than x86.

Interrupt services were introduced with the BIOS, and will continue
to always be available on x86 platforms, for compatibility.
Compatibility is the only actual value of x86.

UEFI on x86 does not neccessarily have to, but in practice generally
does include a CSM, which provides BIOS-compatible interrupt services
also on systems with UEFI.

Regardless of whether that's a 32 or 64 bit UEFI, the CSM always
provides the legacy 16 bit interface.


Vincenzo, if you are creating a secure system, you must first establish
what is secure *enough* for your use case. Risk assessment and a threat
model are essential, or you will never reach a working reliable system,
because they define your goal.

Security issues can exist pretty much everywhere, so an "ideal" secure
system is not very practical.


//Peter

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Raphael Jacquot]

On 08/30/2017 07:06 AM, taii...@gmx.com wrote:

> Yes it is called AMD-PSP and present in the newer stuff such as AM4 and
> FM2+, although they did entertain the idea of providing a method to
> disable it in a reddit thread which a PR guy claims the CEO paid
> attention to so I suppose a corporate customer that purchases sufficient
> volume could convince them to actually do it. much better than intel's
> ignoring of the issue.

sounds more like intel designed the thing to be disabled by the NSA for
their use, but hiding the fact very well so that the same NSA are able
to use some possibly yet unknown integrated backdoor to hack into
everybody's else machines

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot