On 09/24/2007 03:41 PM, Ward Vandewege wrote:
Any thoughts?
I have s2892 and Sun Ultra40, which have ck804 too. Linux can only detect
one hard drive per SATA controller. The second drive is either undetected or
times out. On s2892, some HD types, presumably all SATA-II, (Hitachi
HDS7280SA for
On 09/24/2007 07:42 PM, ron minnich wrote:
On 9/24/07, Roman Kononov [EMAIL PROTECTED] wrote:
I have s2892 and Sun Ultra40, which have ck804 too. Linux can only detect
one hard drive per SATA controller. The second drive is either undetected or
times out. On s2892, some HD types, presumably all
Darmawan Salihun wrote:
I might have made a wrong assumption previously. I thought that a DPC
object that has the same Deferred Routine won't be queued twice in the
system's DPC queue. Nonetheless, this might not be the case for
multiprocessor machine because every processor has its own DPC
On 08/20/2007 10:05 AM, Darmawan Salihun wrote:
According to the official documentation, DPC is running at
IRQL_DISPATCH_LEVEL. Nonetheless, I think there is still problem because
only one DPC object of one type can exist in the system at one
instance.
What do you mean by type?
If you have N
On 08/14/2007 07:56 AM, Peter Stuge wrote:
Roman did make a good point about IRQL but that does not eliminate
the problem, we will still be changing hardware state underneath the
OS and that is ALWAYS a bad idea.
The CF8/CFC sequence can preserve CF8 port value. What other hardware state
On 08/14/2007 02:47 PM, Peter Stuge wrote:
The CF8/CFC sequence can preserve CF8 port value. What other
hardware state would be changed?
The bits that are changed in the device config space.
I cannot imagine why the OS would care about a couple of configuration bits
in the SB.
Yup. Are
Peter Stuge wrote:
But PCI config accesses are not atomic operations. Is there a
guarantee that the other CPUs are not in the middle of doing a PCI
access already?
And even if they are actually doing something else, perhaps they
(erroneously? but we don't want to break them anyway) rely on
Darmawan Salihun wrote:
As I couldn't find any better replacement to the PCI direct I/O
function at the moment (which is needed in chipset_enable and
board_enable), I will try to implement them using a quite old kernel
mode API, i.e. HalGetBusData and HalSetBusData. I hope the kernel
On 06/13/2007 09:39 AM, Myles Watson wrote:
I’m using LinuxBIOS on my Tyan s2892. I have a device that maps a lot
of the memory space, but I’m struggling trying to get the Opteron to
read and write to my device in larger blocks. I have set the variable
MTRRs in the device driver to
On 06/14/2007 03:59 PM, ron minnich wrote:
On 6/14/07, Marc Jones [EMAIL PROTECTED] wrote:
Now that I think about it, it makes sense that you can't set writeback
to noncoherent (nonsystem) memory space. What if another device wants to
write to that memory. There is no way for the cache to
On 04/10/2007 12:16 AM, Peter Stuge wrote:
What happens if the same object or dir is included multiple times?
Does the config tool handle that automatically?
From what I observe, the config tool issues warnings, the repeated files
are compiled exactly once and archived into linuxbios.a, which
LinuxBIOS information wrote:
The developer stepan checked in revision 2600 to
the LinuxBIOS source repository and caused the following
changes:
Build Log:
Compilation of arima:hdama is still broken
Compilation of technologic:ts5300 is still broken
Stefan,
You need to add the following
__COMPRESSION__ undefined (missing use command?)
for both r2586 and r2587.
I conclude that it brakes for unrelated reasons.
Regargs,
Roman
This patch corrects r2587. It makes sure that the VGA is initialized
when CONFIG_CONSOLE_VGA==0 and CONFIG_PCI_ROM_RUN==1
Signed-off-by: Roman Kononov [EMAIL
Roman Kononov wrote:
LinuxBIOS information wrote:
Compilation of artecgroup:dbe61 has been broken
Compilation of technologic:ts5300 has been broken
I tried to build the broken compilations using the default procedure
buildtarget make -C directory and I am confused:
I think I've figured
/mac_address.h
mainboardinit southbridge/nvidia/ck804/romstrap.inc
ldscript /southbridge/nvidia/ck804/romstrap.lds
end
The location of mac_address.h can be different. The file is
generated by the build process or edited manually.
Signed-off-by: Roman Kononov [EMAIL PROTECTED]
---
Index: src
address instead like s2895.
It is not my case. Sun Ultra40 has AT24C64, which has no MAC in
it. This EEPROM looks smbus-unfriendly for it needs 13-bit data
words. In any case, the original BIOSes contain MACs, serial
numbers and other tags.
-Original Message-
From: Roman Kononov [mailto
On 02/07/2007 01:09 PM, Lu, Yinghai wrote:
The romstrap.inc is only want to have the fixed postion for MAC in
flash.
You have own romstrap.inc in your MB dir, and update MB Config.lb to
point to it.
This will work too. My objection is that the other magic things from
romstrap.inc would be
On 02/04/2007 12:33 PM, Eric W. Biederman wrote:
Which means we want to either delete the System ROM reservation,
perform the System ROM reservation after other reservations from
the e820 map, or improve the error handling.
What is the point in making reservation of a ROM which does not
exist
, The VGA option rom will be executed if either
CONFIG_PCI_ROM_RUN=1 or CONFIG_CONSOLE_VGA=1.
Signed-off-by: Roman Kononov [EMAIL PROTECTED]
Signed-off-by: Stefan Reinauer [EMAIL PROTECTED]
Index: src/devices/pci_rom.c
===
--- src
On 02/02/2007 11:58 AM, Uwe Hermann wrote:
On Fri, Feb 02, 2007 at 05:50:04PM +0100, Stefan Reinauer wrote:
Could you please rediff with -w ? Something terribly broke the indenting.
I guess this was intended. It looks like Roman fixed the coding style(?)
E.g. replaced spaces with tabs in a
On 02/02/2007 12:08 PM, Carl-Daniel Hailfinger wrote:
IIRC the C99 standard is the first C standard to allow // comments.
I vote for allowing // comments since:
1. they are a C standard
2. they do not clutter so much
3. they make life easier for many people
4. the current code has too many
,
Signed-off-by: Roman Kononov [EMAIL PROTECTED]
Index: src/stream/rom_stream.c
===
--- src/stream/rom_stream.c (revision 2542)
+++ src/stream/rom_stream.c (working copy)
@@ -116,7 +116,7 @@ byte_offset_t stream_skip(byte_offset_t
HostControllerReset bit in HcCommandStatus Register.
It is enablead by using 'register usb1_hc_reset=1' in 'chip
southbridge/nvidia/ck804' section of the mainboard's Config.lb.
Signed-off-by: Roman Kononov [EMAIL PROTECTED]
Index: src/southbridge/nvidia/ck804/ck804_usb.c
On 02/01/2007 01:54 PM, Carl-Daniel Hailfinger wrote:
Ed Swierk wrote:
static int set_bits(uint8_t *port, uint32_t mask, uint32_t val)
@@ -228,7 +229,7 @@ static void aza_init(struct device *dev)
if(!res)
return;
- base =(uint8_t *) res-base;
+ base =(uint8_t
On 01/23/2007 12:20 PM, ron minnich wrote:
I would like to hear reports of building and running linuxbios on
ubuntu and FC6.
I've just built working linuxbios. A lot of warnings; no errors.
~uname -a
Linux xd1000 2.6.18-1.2869.fc6 #1 SMP Wed Dec 20 14:51:34 EST 2006 x86_64
x86_64 x86_64
On 01/17/2007 05:56 PM, Roman Kononov wrote:
In the original code vga_inited is set, then run_bios() is
called, which does printk(), which is allowed using the VGA.
The patch puts vga_inited=1 and run_bios() in the right order.
For me, this bug resulted in linuxbios hanged.
When console log
On 01/31/2007 12:48 PM, Stefan Reinauer wrote:
Can you try the attached patch? It's a little less intrusive
It will not compile when CONFIG_CONSOLE_VGA=0.
Are you comfortable with more #ifdefs?
--
linuxbios mailing list
linuxbios@linuxbios.org
Related question:
If I say CONFIG_PCI_ROM_RUN=1 and CONFIG_CONSOLE_VGA=0,
why does it skip VGA initialization?
The rational here is that I may need a lot of debugging
output, but I do not want it to be directed to the VGA,
because it is almost useless on the VGA and the users are
scared. In the
On 01/31/2007 01:52 PM, Stefan Reinauer wrote:
Is it enough to not set vga_inited if
CONFIG_CONSOLE_VGA=0 ?
Yes, it is. If CONFIG_CONSOLE_VGA=0, vga_inited is undefined,
else vga_inited is defined and should be set.
--
linuxbios mailing list
linuxbios@linuxbios.org
Hello,
I have this situation:
Linuxbios boots an Opteron motherboard with 1GB memory.
Linuxbios directly loads a recent linux kernel.
The memory layout is like this:
BIOS-provided physical RAM map:
BIOS-e820: - 0e18 (reserved)
BIOS-e820: 0e18 -
Hello,
This fixes a small typo.
Regards, Roman
diff -uBbrpP LinuxBIOSv2-2510.orig/src/include/cpu/amd/amdk8_sysconf.h LinuxBIOSv2-2510/src/include/cpu/amd/amdk8_sysconf.h
--- LinuxBIOSv2-2510.orig/src/include/cpu/amd/amdk8_sysconf.h 2006-10-04 17:56:21.0 -0500
+++
This fixes a small typo.
Signed-off-by: Roman Kononov [EMAIL PROTECTED]
---
On 01/31/2007 03:19 PM, Peter Stuge wrote:
Please have a look at http://linuxbios.org/Development_Guidelines
Thank you
Index: src/include/cpu/amd/amdk8_sysconf.h
f6103000-f6103fff : sata_nv
f6104000-f6104fff : :00:08.0
f6104000-f6104fff : sata_nv
f6105000-f6105fff : :00:0a.0
f6106000-f61060ff : :00:02.1
f620-f620 : :40:01.0
Kexec is happier with the patch.
Regards,
Signed-off-by: Roman Kononov [EMAIL PROTECTED]
---
Index: src
This eliminates an illegal and annoying warning.
'rom' is the current read pointer.
'rom_end' points to last valid byte of the stream.
Regards,
Signed-off-by: Roman Kononov [EMAIL PROTECTED]
---
Index: src/stream/rom_stream.c
This patch makes sure that VGA is initialized before it is used.
Additionally, VGA will be initialized if either CONFIG_PCI_ROM_RUN=1
or CONFIG_CONSOLE_VGA=1.
Signed-off-by: Roman Kononov [EMAIL PROTECTED]
---
Index: src/devices/pci_rom.c
On 01/31/2007 05:53 PM, Peter Stuge wrote:
+#if CONFIG_PCI_ROM_RUN == 1 || CONFIG_CONSOLE_VGA=1
One or two = ? Which is it?
None.
Index: src/devices/pci_rom.c
===
--- src/devices/pci_rom.c (revision 2539)
+++
Using v2451, I've got an infinite ht reset - loop because of one of these two:
/src/southbridge/nvidia/ck804/ck804_early_setup.c:10: warning: no return
statement in function returning non-void
/src/southbridge/nvidia/ck804/ck804_early_setup_car.c:12: warning: no return
statement in function
Hello,
The first patch changes chip erase method from JEDEC Chip Erase to JEDEC Sector
Erase for
each sector. See the comment in util/flashrom/sst49lf040.c, line #40. Verified
on a real
SST49LF080A chip, for which JEDEC Chip Erase did not work as well.
The second patch makes printf working [as
Hello,
I have LinuxBIOSv2-2228 on Tyan s2892 working fine. Recently, I tried v2434.
The system dies badly when an HT device (other than nVidia - unverified)
sends an HT Read Request Packet. The CPU never replies. Proven with a logic
analyzer. It was found that the newer LinuxBIOS misconfigures
On 10/10/2006 01:15 PM, Lu, Yinghai wrote:
There is some setting in the MB Options.lb
default HT_CHAIN_UNITID_BASE=0x0
default SB_HT_CHAIN_UNITID_OFFSET_ONLY=0
you can comment out them, if you like.
Thank you for the answer.
What are the options for?
Why did you put them in if they break
On 10/10/2006 01:46 PM, Lu, Yinghai wrote:
The option are used to put HT device on specific bus num and device
logic.
How?
Are you testing new HT device on socket?
Yes, I am. And the code in get_bus_conf.c does not allow me to do
so unless I modify it to expect the PCI-X bridge on another
Hello,
The first patch changes chip erase method from JEDEC Chip Erase to JEDEC Sector
Erase for
each sector. See the comment in util/flashrom/sst49lf040.c, line #40. Verified
on a real
SST49LF080A chip, for which JEDEC Chip Erase did not work as well.
The second patch makes printf working [as
On 10/02/2006 05:34 PM, Ronald G Minnich wrote:
it's something like 20 chars per byte write, so for 1 MB part, you're
talking 20 M chars. It will take 20 minutes to print at 9600.
I see.
But in this case, before the patch, it printfs once per 4096 sectors,
which is never. After the patch, it
On 09/20/2006 02:12 PM, Ronald G Minnich wrote:
can someone suggest other things to bring?
we WILL be hacking.
Flash emulators
Roman
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
Maybe this will help:
http://sourceforge.net/mailarchive/forum.php?thread_id=10216054forum_id=48022
Roman
On 09/04/2006 13:22, Ed Swierk wrote:
Hello,
I'm trying to boot Linux on qemu (0.8.2) with LinuxBIOSv2 (svn 2394)
and FILO (0.5). I built filo.elf, ran buildtarget emulation/qemu-i386,
45 matches
Mail list logo
