I'm not sure why it would be breaking anything, but it just doesn't
make sense. From Volume 3:
Because all internal cache lines are invalid following reset
initialization, it is not necessary to invalidate the cache before
enabling caching.
It is pretty weird, I downloaded one random Sandybridge
The open-graphics people had this question a while back, I think I
took a look at some different platforms and BIOSes:
http://lists.duskglow.com/open-graphics/2007-August/010402.html
Turning on the decoders for only one of each type of legacy device sounds right.
On Mon, Dec 19, 2011 at 6:13 PM,
If you want to browse around a bit, there is an LXR cross reference of
coreboot available here:
http://lxr.linux.no/coreboot
Tom
On Mon, Sep 12, 2011 at 8:48 AM, Jianmin Pan dsp...@gmail.com wrote:
I am a newbie to coreboot, I am wondering is there an easy approach to
understand the functions.
Hello Andrew,
AMD SB800-ish southbridges will only selectively fetch BIOS from LPC or SPI
based on straps. Your board won't fetch from LPC unless you change the strap
(which are unknown resistors on your board).
Your best option is SPI in-system programming, and you can just use the SPI
header
Hello Andreas,
Your ideas sound pretty good, but here are a couple of ideas that
might make your life easier (and cheaper).
I found some high-res pictures of your board on the web, and it looks
like that board has a footprint for a SPI programming header (labelled
SPI1, between USB1 and the SPI
but it seems to be a very good board in
general.
Marek
On 16.4.2011, at 11:12, Tom Sylla tsy...@gmail.com wrote:
Hi Marek,
I do own this board, and it is probably one of the more painful to get
ported. There is no SPI header, no serial port, and it has the
gigabyte dual-BIOS mechanism to deal
Hi Marek,
I do own this board, and it is probably one of the more painful to get
ported. There is no SPI header, no serial port, and it has the
gigabyte dual-BIOS mechanism to deal with. I also have an MSI e350
mini-ITX board, without any of those problems, and maybe someday I
will try to make a
Your address is in I/O address space, not memory address space. Take a
look at io_rw.c in iotools, you need to be using inb/outb (not just
reading/writing memory).
Tom
On Thu, Apr 14, 2011 at 4:12 PM, Jeremy Moles jer...@emperorlinux.com wrote:
Hey guys, me again. :)
So, my device is working
Central Computers has a couple in stock also, the GA-E350N-USB3 (dual
BIOS pain) and I believe the E35M1-M Pro (microATX)
On Fri, Mar 11, 2011 at 6:29 PM, David Hendricks dhend...@google.com wrote:
Hey everyone,
Stefan and I are going to be @ Google in Mountain View hacking on Coreboot
this
This is all a bit fuzzy now, but this is what I recall: The HT1000
SATA controller can also be configured as a PATA/IDE device. It will
show up as 024B instead of 024A when it is configured that way:
http://pci-ids.ucw.cz/read/PC/1166/024b
The mechanism to do the switch is in the HT1000
This looks like it was an interesting task. I had some questions and
comments from previous fast-POST exercises:
On Mon, Dec 21, 2009 at 12:44 AM, Kevin O'Connor ke...@koconnor.net wrote:
* cpu appears to start running around 350ms
Do you have a scope at all?. The only way to know this number
Sorry, I don't understand this mail. AMD VSA is for Geode PCI
configuration space emulation and AGESA is for FamF and Fam10
initialization. They are unrelated.
On Wed, Nov 18, 2009 at 8:26 AM, Stefan Reinauer ste...@coresystems.de wrote:
On 11/18/09 7:50 AM, Darmawan Salihun wrote:
Hello all,
On Fri, Oct 2, 2009 at 4:07 PM, ron minnich rminn...@gmail.com wrote:
Maybe it is a difference in view. The address is 7 bits in all the
docs. How it is laid out in the register and on the bits on the wire
is really a different concern.
Sorry for the dead horse revival, but I was just looking
Peter Stuge wrote:
Patrick Georgi wrote:
What I don't know is, do we require any chipset setup to _reach_
CMOS?
It's not generally in the CPU, so some setup may be needed. On the
other hand, maybe 70/71 are decoded correctly on power up, just like
flash access?
It's not like there is a spec
On Fri, Oct 2, 2009 at 12:53 PM, ron minnich rminn...@gmail.com wrote:
On Fri, Oct 2, 2009 at 4:53 AM, Carl-Daniel Hailfinger
The lm_sensors tools are handy when everything is working fine.
They're not when things are not. In my case, things are not and,
sadly, the tools are largely useless --
On Wed, Sep 23, 2009 at 1:10 PM, Daniel Mack dan...@caiaq.de wrote:
Could you outline which steps would need to be taken in order to find
out the correct address to use? Any maybe a way to sany detect the
precence of that function on the board? I might go ahead and send a
patch for the driver
On Sat, Aug 15, 2009 at 12:00 AM, Chris Kindtchriski...@umbc.edu wrote:
+static union u64_u32_u lx_msrRead(u32 msrAddr)
+{
+ union u64_u32_u val;
+ asm __volatile__ (
+ movw $0x0AC1C, %%dx \n
+ movl $0xFC530007, %%eax \n
+ outl %%eax, %%dx
On Wed, Jun 24, 2009 at 8:43 AM, Thomas JOURDANthomas.jour...@gmail.com wrote:
I forgot to mention that on the IRC, someone suspected a missing timer
setup leading to a division by zero. This might help.
In the past, when trying to figure out a VGA ROM execution hang or
errors, it has been very
On Wed, May 13, 2009 at 10:26 PM, Peter Stuge pe...@stuge.se wrote:
If MMCONFIG is the term that applies, then better use that instead:
MMCONFIG_BAR_BASE and _SIZE
One note, BAR might be a little bit confusing. BAR has a pretty
strong tie to an actual register in a PCI config header. I think
On Tue, May 12, 2009 at 11:09 AM, ron minnich rminn...@gmail.com wrote:
The next big step in my view is setting a flash-friendly value of zero.
Do you mean flashrom-friendly value of 0xFF?
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On Tue, May 12, 2009 at 7:44 AM, samuel samuel.verstra...@gmail.com wrote:
Because SeaBIOS does not support AHCI SATA it can not start the
bootable drive of the machine so i had to add filo to seabios to
manage booting:
./cbfstool coreboot.rom add-payload filo.elf img/FILO
I think you may
On Tue, May 12, 2009 at 12:46 PM, Myles Watson myle...@gmail.com wrote:
I think you may still be able to get this part working without FILO,
but I am not sure how. The HT1000 SATA is not AHCI, so support for
AHCI won't actually help. The controller has normal PATA emulation
mode, as well as
On Wed, Apr 22, 2009 at 8:00 AM, samuel samuel.verstra...@gmail.com wrote:
2. VGA output is still not working. I have tried both YABEL and
X86BIOS to load the vga rom but i get errors...
X86BIOS: http://merlin.ugent.be/~samuel/dl145g3/vgarom/corebootx86bios.log
relevant part:
On mainboard,
On Tue, Mar 31, 2009 at 12:56 PM, Stefan Reinauer ste...@coresystems.de wrote:
thank you very much for your patch. Do you happen to know if the component's
name is HT2100 or HT21000? Just to make sure we have it in the repository
correctly.
The naming in the patch looks right. Broadcom
2009/1/30 Peter Stuge pe...@stuge.se:
Peter Stuge wrote:
Can someone please review these register definitions? Thank you!
Attaching latest version also available at
http://stuge.se/mt.cs5536_pic_divil3.patch
const struct msrdef cs5536_msrs[] = {
+ /* 0x5148-0x514f per 33238G
Do most normal motherboards supply +5V on pin 7 of their SATA
connectors to make this work?
Are you using them on an off-the-shelf motherboard?
This looks like something intended for an embedded design, where you
make your connector a non-standard pinout to support it.
On Mon, Jan 12, 2009 at
This will definitely work, a couple of years ago, we researched this
exact setup. Our plan was to put headers on the motherboards were we
deisnging, to have an easy de-bricking mechanism. A co-worker wrote a
windows SPI flasher in a day or so. I have seen that exact device used
to program SPI
On Sat, Nov 15, 2008 at 2:29 PM, Joseph Smith [EMAIL PROTECTED] wrote:
Anyone know if USB ports have power feedback protection. What I mean by
that is if I use the LPCflasher as a inline flasher with a PLCC32 socket
plug, flash the chip and then power up the motherboard, I don't want the
VCC's
On Fri, Oct 24, 2008 at 8:24 PM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
Would you mind posting lspci -tvnn for that 5-processor board as well?
It would help me a lot to understand this issue better.
Here they are, if you are still interested. There is a 5-node, and
8-node, and a 2-node
On Fri, Oct 24, 2008 at 8:24 PM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
AGESA has a default discovery method (I think
breadth first, lowest link number first) but it has options to
over-ride the discovery mechanism to change the order of nodes in a
system. All that matters is that the
On Fri, Oct 24, 2008 at 11:13 AM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
Note the warning about Possibly incomplete decoding which stems from
the fact that the processor mentions HT revision 1.02 which is the last
non-public revision. Every revision from 1.03 and beyond seems to be
The HT topology is not really directly reflected in PCI config space.
They are obviously linked, but there is not really a way to map a HT
topology of Opteron nodes to a graphical view of config space, it just
doesn't exist. The Opterons just are where they are.
All of the processor PCI devices
On Wed, Oct 15, 2008 at 3:56 PM, Myles Watson [EMAIL PROTECTED] wrote:
C000:3241 B802B1 mov ax,b102
C000:3244 CD1A int 1a
: FF
Yep, b102 is not a common signature.
I'm looking for the place where the interrupt vector was supposed to have
been set.
I am
On Thu, Jul 17, 2008 at 12:40 PM, Myles Watson [EMAIL PROTECTED] wrote:
Here are the two logs for the Windows XP install CD. I'm wondering if
we should make SeaBIOS pretend to be an older BIOS and see what
happens. It seems like there was some structure that is returned on a
BIOS call that
Here is a dump for the wiki:
superiotool r3361
Found NSC PC87427 (sid=0xf2, srid=0x04) at 0x2e
Register dump:
idx 10 12 13 1d 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
val 00 00 00 00 f2 19 a0 40 20 00 02 04 00 14 00 04 12 00 00 00
def 00 00 00 00 f2 11 a0 MM MM MM 02 NA 00 MM 00 00
On Wed, Jul 9, 2008 at 12:05 PM, ron minnich [EMAIL PROTECTED] wrote:
This does not fix the problem with the memory errors. We've still got
something wrong in memory, and it is not clear what.
Does DBE62 have an unterminated memory interface? Can you compare MSR
0x4c0f from coreboot to a
On Thu, Jul 3, 2008 at 8:45 AM, Joseph Smith [EMAIL PROTECTED] wrote:
Well it looks like in the pdf presentation above they have a Serial-USB
debugger. It looks like a development board though because there are a
bunch of unnecessary stuff on it. I'm thinking a Serial-USB debugger is
the way
Others have pretty much replied with what I was trying to point out,
but here are a couple more comments:
On Thu, Jul 3, 2008 at 12:28 PM, Joseph Smith [EMAIL PROTECTED] wrote:
I guess you don't get it. I am not doing it to mass produce and sell at a
lower cost. I don't really care about any
Busy wait is a loop of some number of NOP instructions, as opposed to
relying on some CPU peripheral such as a timer to signal elapsed
time. The number of NOP instructions has to be calculated from the
current CPU frequency.
That seems more complicated than it needs to be. Here is what I am
The dump tool is the way to go now, but just to answer a couple of your
questions:
[EMAIL PROTECTED] wrote:
OK, so lets clarify?
GPIOBASE?GPIO Base Address (LPC I/F?D31:F0)
31:16 Reserved
15:6 Base Address ? R/W. Provides the 64 bytes of I/O space for GPIO.
5:1 Reserved
0 Resource
If you want to look at the GPIOs, from the 82801DB datasheet, it looks
like you should look at:
9.1.14 GPIOBASE—GPIO Base Address (LPC I/F—D31:F0)
and
9.1.15 GPIO_CNTL—GPIO Control (LPC I/F—D31:F0)
(offsets 58 and 5c in D31:f0, lspci -xxx as root is one way to dump)
What value is in those
ron minnich wrote:
On Thu, Feb 14, 2008 at 2:32 PM, Carl-Daniel Hailfinger
Indeed. That would solve the problem very nicely without putting hacks
into the dts.
OK, so we put nodes under the 5536, and specify 'disabled', and the
5536 code knows to actually call VSA when it sees that they
On Feb 8, 2008 3:05 PM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
Within the tarball there is a file modification_notes.txt that
highlights what I have done. I'm hoping to foster some discussion on a
testing approach that lays somewhere between manual inspection and
slapping the
It has confusion:
L1 Cache: Unknown | Test #6 [Moving inversions, 32 bit pattern]
L2 Cache: Unknown | Testing: 120K - 256M 255M
See if you can make sure this is not another memtest bug. For a long
time, memtest did not know that Geode LX CPUID meant to read the cache
[EMAIL PROTECTED] wrote:
Here is what I think the PCI rom does with the original bios:
1. powers on and enables device
2. sets up PHY registers
3. sets up it PCI config registers
4. and requests use of the PCI bridge
If I could figure out how to do #1 the rest would be fairly simple to
Looking at one of your old logs, it looks like the VSA init code is
*running* in the 0x1000 segment:
http://www.coreboot.org/pipermail/coreboot/2008-January/029736.html
(cs 0x1000)
That is probably smashing the region. The int18s are certainly bad,
you should just have the normal two int15s,
Marc Jones wrote:
Tom is right, something funny is going on here. We see the VSA
decompressed to buf 0x0006 which is a good place for VSA. Then we
don't see an error that VSA isn't found. That means that it found the
first post code as expected.
Yep, I checked with FS2, things look
ron minnich wrote:
here's an interesting bug in
/home/rminnich/src/bios/coreboot-v3/util/x86emu/vm86.c
/* Dump zeros in the other segment registers */
mov %ax, %es\n
mov %ax, %fs\n
mov
ron minnich wrote:
I thought that even without VSA, a pci config read of 0:1.0 would give
me something reasonable back. But the devices that are found without
VSA are 0:c.0, 0:d.0, and then 0:f.0 etc.
Without VSA, the only thing you are going to see south of LX are the
real hardware PCI
49 matches
Mail list logo
