On 04/03/13 20:46, Andrew Basterfield wrote:
On 03/03/13 16:48, Andrew Goodbody wrote:
You say it is stable with one CPU using the Tyan BIOS so it is at least
possible to use the board as is.
There is certainly code in the S2895 devtree and mptable to allow for
the missing devices caused by a
On 03/03/13 14:28, Andrew Basterfield wrote:
Hi Andrew
The lack of 2nd PCIe and ethernet is expected behavior when the 2nd
socket is empty - please see the following
ftp://ftp.tyan.com/manuals/m_s2895_101.pdf
Please see 2nd 'NOTE' section 2.4 page 18
Looking at the system architecture section
On 03/03/13 14:04, Andrew Basterfield wrote:
Due to the lack of CPU in socket #2 the board becomes a little crippled;
2nd PCIe slot and 2nd ethernet no are longer available; maybe coreboot
would work OK with both sockets populated but the single socket
configuration has not been encountered?
--A
On 05/01/13 08:26, Patrick Georgi wrote:
Am 2013-01-05 01:03, schrieb Andrew Goodbody:
coreboot can never be "the Solution to the Secure
Boot Fiasco" until it can offer better security than Secure Boot.
We do. Same level of verifiable boot (by doing signature checks on
loaded code) w
On 05/01/13 02:11, David Hubbard wrote:
Hi Andrew,
On Fri, Jan 4, 2013 at 5:09 PM, Andrew Goodbody mailto:ajg4tadp...@gmail.com>> wrote:
Enrol your own key. Sign your own kernel. Seems to scale linearly
per user to me.
Security is not free. There will always be a cost.
On 05/01/13 00:10, ron minnich wrote:
Andrew, so far, I don't find your arguments very convincing.
Can you explain to me why Intel would want to control what OS is run on
their chipsets? Intel are an active contributor to the Linux kernel for
their display drivers.
Andrew
--
coreboot maili
On 04/01/13 02:54, David Hubbard wrote:
I personally use
Gentoo Linux which means my kernels are compiled right on my own box.
Secure Boot will never work for that (specifically, getting each kernel
signed for each user would never scale).
Enrol your own key. Sign your own kernel. Seems to scal
On 03/01/13 23:23, gary sheppard wrote:
Numerous security experts have already said it is anything but secure,
and it will never be secure. They have only said this quietly, and that
"voice" has been minimalized, while "PROGRESS" is shouted to the
heavens. Hey, look at android and how phone make
On 03/01/13 18:40, ron minnich wrote:
OK, after further thought, here's my take.
Two companies have defined a secure boot standard in such a way that
they can closely control what boots on future systems using the one
company's chips. This is a sea change from the original IBM PC design,
which e
On 02/01/13 19:28, David Hubbard wrote:
Andrew, Ron, what's your take on http://mjg59.dreamwidth.org/20916.html ?
Specifically:
"This is part of Windows 8's fast boot support - the keyboard may not be
initialised until after the OS has started."
OK, the feature is deferred initialisation of US
On 02/01/13 17:08, ron minnich wrote:
On Mon, Dec 31, 2012 at 11:23 AM, David Hubbard
wrote:
Andrew has good points. Technically there's nothing about Secure Boot that
can be proven to exclude alternative OS's such as Linux.
While that is technically true, I am starting to see reports of
sys
On 30/12/12 17:26, Rex Djere wrote:
I did a lot of research for the article, and I feel that I got a
pretty good picture regarding what happened with AMD, coreboot, and
UEFI/secure boot. I am looking for 2 things please:
-feedback on whether I got anything egregiously wrong.
-help if you agree w
On 09/11/12 06:29, Milo Hoffmann wrote:
The datasheet does not include the /CE pin from the quick and dirty
explanation. I interpret it to mean the WE# (Write Enable) pin but am
seeking confirmation from more informed folks.
Can anyone on the list confirm I could hook up two identical
SST49LF004
On 14/10/12 05:12, WANG Siyuan wrote:
hi, Andrew
thank you. this issue has been solved by updating the acpi routing
The ACPI routing tables are a description of the underlying hardware
configuration. If you have not also changed the hardware configuration
then you may well have an invalid ACP
On 10/10/12 12:11, WANG Siyuan wrote:
hi,
i am debugging a mainboard with an external pci network adapter.
the adapter share irq with usb. it seems not correct, so i want to assign
an irq for this adapter.
how to do that?
thank you.
1) PCI interrupts can be shared. It is OK and usual for this t
To be honest I don't see the difference between having binary blobs in a
separate repo and having them in the main coreboot repo. Apart that is
from the slightly meaningless saying that the whole coreboot tree is GPL
compatible. It seems more relevant to be able to say that about a
particular p
On 09/04/12 04:24, Bao, Zheng wrote:
Hi,
It is unstable. In most cases, it hangs at this wbinvd. Once it pass that
instruction, it will hang at when AP cores are launched.
Try invd instead of wbinvd. There should be no need to preserve anything
from the cache so the write back is not needed.
On 11/03/12 05:04, Scott Duplichan wrote:
I know of two ways to extract the legacy video option rom:
a) Download the image from the manufacture's web site:
1. ftp://174.142.97.10/bios/CPU/E350M1(1.50)ROM.zip
2. Extract the 4MB UEFI image (E350M11.50)
3. Use 7-zip (version 9.21 beta)
On 07/03/12 12:37, Jonathan A. Kollasch wrote:
First of all, INITIAL_EBDA_SEGMENT has been 0xF600 prior to this change.
OK, I guess it works then. At least most of the time anyway.
I believe loading a SeaBIOS payload will obliterate the coreboot EBDA at
this location. SeaBIOS almost certainl
On 07/03/12 01:06, Stefan Reinauer (stefan.reina...@coreboot.org) wrote:
NEW/FIXED now reads consistent values:
ebda_addr=0xf6000 lowmem=0x10
OK, now this worries me. Any time you move away from the classic PC
memory map you are risking problems.
0xe-0xf would normally
On 07/13/11 22:25, Pete Batard wrote:
On 2011.07.13 12:03, Andrew Goodbody wrote:
I'll start with the aside, that if "failing" means instantly supporting
more than 90% of Intel based motherboards produced in the last 10 years
Yes, universal means everything. If you do not sup
On 07/11/11 18:02, Pete Batard wrote:
Comments? Questions? Shoot away...
Instead of attempting (and failing) to achieve universal support I would
rather see a framework that could easily be configured with the
appropriate SIO support and allow for board specific configuration if
necessary. T
Sorry but my replies are having problems getting to the list.
Greylisting is not supported by the company mail system.
On 07/12/11 18:42, Pete Batard wrote:
On 2011.07.12 07:15, Andrew Goodbody wrote:
Instead of attempting (and failing) to achieve universal support
I'll start with the
Andrew Morgan wrote:
On 06/07/11 12:23, Andreas Galauner wrote:
Also the pinout is kind of "weird":
1#CS
2#CS
3SI
4NC
5SO
6VCC
7SCK
8GND
Why is CS# connected to two pins? The resistance between those two pins
is 1 Ohm, so they are connected directly. Interestingl
Vikram Narayanan wrote:
On Sat, May 14, 2011 at 8:35 AM, Gregg Levine wrote:
On Thu, May 12, 2011 at 6:28 AM, Andrew Goodbody
wrote:
Vikram Narayanan wrote:
ok. I am planning to buy one. Please share your thoughs on which one to buy.
NET20DC, it is the simplest, the cheapest by far and
Vikram Narayanan wrote:
I have an USB port that has debug capabilities (according to the lspci output)
Should I buy the one mentioned in this page
http://www.coreboot.org/EHCI_Debug_Port
Yes
or can I use a normal cable to debug?
There is no normal cable to connect two host ports together an
Joseph Smith wrote:
Also, one could always use serialice on a 4 slot system with factory bios
to see how they deterime it
The factory BIOS does not have to determine it. It knows the
configuration of the board it is running on. It can use a build time
setting.
Andrew
--
coreboot mailin
Joseph Smith wrote:
That's easy... so you do something like this:
As I understand it that only works if there is a DIMM in the 4th slot.
Otherwise you'll set a four slot system with the 3 slot configuration
leading to incorrect routing of clocks.
Andrew
--
coreboot mailing list: coreboot@c
Sorry, neglected to send original reply to list.
Knut Kujat wrote:
Andrew Goodbody escribió:
Knut Kujat wrote:
Any suggestions ?
The vendor BIOS is doing some initialisation that coreboot is not.
This init survives a short shutdown but is lost after a longer period
without power.
Yes
Stefan Reinauer wrote:
On 3/5/10 10:29 AM, Bao, Zheng wrote:
Don't load verb in BIOS stage. It is not BIOS's responsibility.
Who is responsible for that, then?
Those verbs are motherboard specific as they describe the actual
external connections so they should not be in southbridge code.
Luc Verhaegen wrote:
We have 892 bytes to our disposal in cmos. We can reserve 128 for
board/cmos versioning, and reserve even 256 for the bootloader, and
still have 512bytes left for coreboot options, which is tons when bits
are used properly and when strings are not used.
Most boards I have
Peter Stuge wrote:
Patrick Georgi wrote:
It might be sufficient to keep a static array around with a valid
preset of CMOS values (the cmos.layout format would have to be
extended to store defaults for that), and just overwrite CMOS if
it's found to be invalid
I think this is too violent as a g
Stefan Reinauer wrote:
I noticed that century byte is happily ignored - need to check if it
really
collides.
Is that good for anything? Does the BIOS need to care? I thought hwclock
--sys-to-hc does that ;-)
Some implementations of the RTC will auto increment the century byte on
a century rol
Magnus Christensson wrote:
Specifically, what does the pci_slot_get_pirq function do? It looks like
it assigns different interrupt numbers to devices depending on their
device number.
I haven't looked at the code or the context but this is the behaviour
you need to determine the interrupt lin
If anyone does want to work on the D945GCLF board then you need to
update the sdram_enable_memory_clocks in
northbridge/intel/i945/raminit.c in a way that does not break the mobile
version. The desktop version of the chipset has more clocks and so uses
more bits in C0DCLKDIS and C1DCLKDIS to co
Myles Watson wrote:
I was hoping for a PCI POST card that buffered codes so that they could
be read from another computer by USB. Then it wouldn't depend on
working USB or serial, just port 0x80.
The USB debug port requires much less support than full blown USB and so
can be used in restrict
Peter Stuge wrote:
The only Debug Class device I know of is the little blue NET20DC from
PLX.
AMI Debug Rx, info on the AMI site, direct links don't work. You're
supposed to be able to buy it without the enhanced debug transport
enabled so you just get the generic debug class device when in tha
greg wrote:
Now Andrew if we could track down a collection of Tadpole VME bus based
boards wearing the M68K family of processors..
(Ignore that remark fellow Coreboot participants, that's a side-remark to
Andrew G.
Now if I could only find a spare VME chasis to put this here TP43M in,
I cou
ron minnich wrote:
On Fri, Aug 28, 2009 at 8:34 AM, Marc Jones wrote:
http://www.bizjournals.com/seattle/stories/2008/09/01/daily3.html?ana=from_rss
http://en.wikipedia.org/wiki/Phoenix_Technologies
interesting, the consolidation continues. Do you think they killed the
product or are still re
Marc Jones wrote:
It is
legitimate to disable the first function and expect the others to
work.
No, I don't think so. You need function 0 in order to read the
multi-function flag.
Andrew
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Uwe Hermann wrote:
Hi,
On Fri, May 08, 2009 at 08:37:15AM +0200, Andy Jakobs wrote:
I also have this board and a NVIDIA 7600GT PCI-E card.
I tested the latest revision a few days ago. Unfortunately there was
still no output on the screen after a power-off. So it is no real
alternative/repl
Joseph Smith wrote:
FYI, here is what the ICH4 data sheet says about these 0x3d registers.
Looks like the PIRQ is internally specific.
The ICH4 is a southbridge and contains many different PCI devices and
legacy devices including the PIC and the PIRQ routing hardware to map
the PIRQs to PIC i
Kevin O'Connor wrote:
On Wed, Mar 04, 2009 at 10:15:21AM +, wei yang wrote:
When I use the seabios as the payload, I got a strange issue.
In the seabios flow:
Post->timer_setup->rtc_updating->inb_cmos function
when run the inb_cmos, it will reboot on the inb operation.
inb_cmos disassemab
43 matches
Mail list logo
