as the highest
other message in that area, to always note that the reset is intentional.
Someone needs to go through all those printk() and decide which level is
appropriate for each message.
If they're all BIOS_INFO then there's no problem :-)
Acked-by: Torsten Duwe [EMAIL PROTECTED]
Thanks
, but that's a matter of taste. Besides
that
Acked-by: Torsten Duwe [EMAIL PROTECTED]
Torsten
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
On Saturday 12 January 2008, ron minnich wrote:
Acked-by: Ronald G. Minnich [EMAIL PROTECTED]
[BIOS_INFO vs. BIOS_EMERG]
Think about it this way: whichever log level is set, the information that a
repeating log is intentional should be there.
Torsten
--
linuxbios mailing list
On Thursday 10 January 2008, Andon Tschauschev wrote:
I extract some memory through /dev/mem:
'dd if=/dev/mem of=./dump_1.dat bs=1 count=708K'
Then I can look at the extracted memory using hexdump:
'hexdump -vC dump_1.dat | less'
But reading machine code is not very comfortable...
With
On Thursday 10 January 2008, Martin Marcher wrote:
the BIOS just can't handle disks that are larger than 2TB, in
In theory a legacy BIOS should be able to at least access the first 2TB. The
limit stems from 512 bytes block size and counting blocks in 32-bit integers,
which is done in a
On Thursday 10 January 2008, Bernhard Walle wrote:
This patch removes '\n' from the help output since this looks a bit
strange:
[...]
After the patch:
[...]
The line length is still below 80 characters.
Indeed.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
Acked-by: Torsten Duwe [EMAIL
On Sunday 06 January 2008, Carl-Daniel Hailfinger wrote:
This is a much needed simplification and readability improvement. Thanks!
Generated code seems to be unchanged.
If you drop the #undef lines (or explain why we absolutely need them),
you can take the ack from below.
I consider it good
all that
redundant blurb also makes room for meaningful comments 8-)
Signed-off-by: Torsten Duwe [EMAIL PROTECTED]
--- CVS/LinuxBIOSv2/src/mainboard/gigabyte/m57sli/mptable.c 2007-12-29 17:12:33.0 +0100
+++ tmp/LinuxBIOSv2/src/mainboard/gigabyte/m57sli/mptable.c 2008-01-06 13:56:50.0
, they had to also
specify PCI_ROM_RUN, so this new option only offers 2 new opportunities which
didn't work before or were impossible to specify, respectively.
This part combines Luc's and Ron's patches, and adds the new option to
clarify.
Signed-off-by: Torsten Duwe [EMAIL PROTECTED]
diff
Mailers...
diff -BNurbp LinuxBIOSv2.orig/src/config/linuxbios_ram.ld LinuxBIOSv2/src/config/linuxbios_ram.ld
--- LinuxBIOSv2.orig/src/config/linuxbios_ram.ld 2007-07-25 18:26:10.0 +0200
+++ LinuxBIOSv2/src/config/linuxbios_ram.ld 2008-01-05 17:14:27.0 +0100
@@ -92,8 +92,8 @@
On Sunday 06 January 2008, Peter Stuge wrote:
On Sun, Jan 06, 2008 at 02:10:54AM +0100, [EMAIL PROTECTED] wrote:
Author: duwe
Date: 2008-01-06 02:10:54 +0100 (Sun, 06 Jan 2008)
New Revision: 3034
What about all the boards that this affects?
All boards that might have CONSOLE_VGA and not
On Saturday 05 January 2008, Luc Verhaegen wrote:
On Sat, Jan 05, 2008 at 10:59:14PM +0100, Luc Verhaegen wrote:
Agreed. How about an additional CONFIG_NONVGA_ROM_RUN?
This is a good start. I assume you have tested it with abuild. Please
Since I don't touch any board specifics, I
On Thursday 03 January 2008, Luc Verhaegen wrote:
It was considered. I think there is a bigger picture than you might
have realised. Torsten also pointed out a secondary issue.
CONFIG_CONSOLE_VGA is not the right solution in that case. Maybe
CONFIG_VGA_ROM_RUN should be trivially
On Thursday 03 January 2008, ron minnich wrote:
This is a resend from yesterday, I am hoping for an ack :-)
Not yet. This fixes the problem Luc found along the way, and which nobody has
cared about for a while.
How do we want to express now that the console is on a VGA-compatible device
On Friday 04 January 2008, ron minnich wrote:
There's a harder problem. What if we're on a a system with a unichrome
and, for whatever reason, somebody drops in a different graphics card
and wants that to be the console? Of the set of devices that *could*
be the console, which one *should* be
On Friday 04 January 2008, ron minnich wrote:
On Jan 3, 2008 3:49 PM, Torsten Duwe [EMAIL PROTECTED] wrote:
My main concern is that console on VGA and ROM emulators are orthogonal,
and one should not pull in the other, for design reasons. But if there is
no hardware, I'll be quiet.
I
Hi Luc, welcome to the List!
On Wednesday 02 January 2008, Luc Verhaegen wrote:
The CONFIG_CONSOLE_VGA and CONFIG_PCI_ROM_RUN logic in
src/devices/pci_device.c:pci_dev_init is messed up.
Well, it's not as clear as it could be, but I see no flaw so far.
Keep in mind the logic:
On Wednesday 02 January 2008, I wrote:
Your patch admittedly improves readability, but breaks the logic above.
I'd like to apply the beautifying part. What do you think?
[ trivial by Russ' definition, BTW ;-]
Torsten
--- src/devices/pci_device.c.orig 2007-10-03 00:13:15.0
-by: Torsten Duwe [EMAIL PROTECTED]
--- CVS/LinuxBIOSv2/src/mainboard/gigabyte/m57sli/mptable.c 2007-11-06 00:49:23.0 +0100
+++ tmp/LinuxBIOSv2/src/mainboard/gigabyte/m57sli/mptable.c 2007-12-17 15:40:01.0 +0100
@@ -137,7 +137,7 @@
for(i=0;i4;i
On Thursday 20 December 2007, Ron Minnich wrote:
Hi Torsten, why not add the comments and readable indentation right
now? once it is committed, it won't happen :-)
I wanted to keep semantical change and readability improvements separate.
Maybe I should have improved readablity first :) I'll
an interrupt entry for the onboard firewire controller,
Bus 1, device 10, function 0 only, routed to IO-APIC pin 18
(verified on an v1.0 board).
TODO: add some comments and readable indentation!
Signed-off-by: Torsten Duwe [EMAIL PROTECTED]
--- CVS/LinuxBIOSv2/src/mainboard/gigabyte/m57sli/mptable.c
On Sunday 09 December 2007, Oliver McFadden wrote:
I believe the parser in radeonhd is also compiled into the BIOS flashed to
the card. I guessed this from some left over preprocessor defines, etc.
Not quite,
As far as I know, the AtomBIOS on the card consists of an interpreter in
x86 code,
On Wednesday 05 December 2007, Carl-Daniel Hailfinger wrote:
Change wrong LAR: NO FILE FOUND! message to LAR: File not found!.
My first self-acked patch. Flame away!
Here you go: how is an automated checkin hook to tell the difference between
this obviously trivial (sic!) change and a printf
On Wednesday 05 December 2007, Carl-Daniel Hailfinger wrote:
To track this down, I need:
* superiotool dump of proprietary BIOS for board revisions 1.0, 1.1,
2.0, 2.x
* the exact BIOS version of the proprietary BIOS.
Here's my 1.0, BIOS rev 11b
superiotool r
Found ITE IT8716F (id=0x8716,
On Saturday 24 November 2007, Carl-Daniel Hailfinger wrote:
On 21.11.2007 00:30, Torsten Duwe wrote:
Seconded. A trivial patch must _never_ break anything. Leave that
basically to each committer's judgement. If it does break something,
flame at will; we all make mistakes, but the blame must
On Saturday 24 November 2007, Carl-Daniel Hailfinger wrote:
I produce two classes of patches:
* Patches where I'm not sure they will work [...]
* Patches which are IMO obviously correct. They can involve pretty large
code changes or rewriting fragile (and long-time unchanged) code
everybody
On Wednesday 21 November 2007, Andreas B. Mundt wrote:
On Wed, Nov 21, 2007 at 11:19:01PM +0100, Harald Gutmann wrote:
did you use flashrom -E befor writing the new file to the chip?
tried that:
$ sudo flashrom -E
Erasing flash chip
$ sudo flashrom -V --verify --write
On Tuesday 20 November 2007, Uwe Hermann wrote:
On Tue, Nov 20, 2007 at 07:40:26PM +0100, Carl-Daniel Hailfinger wrote:
OK, can we decide on what should be (not) allowed, preferably as regexp
for the diff?
Please don't over-engineer this. It's fine to just flame the committer
who did a
On Saturday 17 November 2007, Andreas B. Mundt wrote:
SST49LF040B found at physical address 0xfff8.
Flash part is SST49LF040B (512 KB).
Which means you have LPC ROM(s), PLCC socket.
Can I use a larger chip and if yes which one? Any experience appreciated.
Consequently, all you need to
On Monday 12 November 2007, Corey Osgood wrote:
Still need a signed-off-by line, please. Thanks, good to hear this is
somewhat working! Does write work as well?
Writing always worked for me, in a sense that I could zero single bits;
this much I verified from the read-back broken image. Then I
reliably. Now it works!
Acked-by: Torsten Duwe [EMAIL PROTECTED]
---
Index: LinuxBIOSv2/src/mainboard/gigabyte/m57sli/Config.lb
===
--- LinuxBIOSv2/src/mainboard/gigabyte/m57sli/Config.lb (Revision 2953)
+++ LinuxBIOSv2/src
Obviously needed to get the initial patch working.
Acked-by: Torsten Duwe [EMAIL PROTECTED]
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
On Tuesday 06 November 2007, yhlu wrote:
On 11/5/07, Torsten Duwe [EMAIL PROTECTED] wrote:
Yinghai, where did you
get the routing info from?
these are all belonging to MCP internal devices esp pcie.
Documented where?
when set the pci irq routing in pci conf space carefully, the mptable
:-)
--
Fix the M57SLI routing table, as apparently set up from LinuxBIOS on that
board. Shift PCIe pin numbers downwards, and PCI int pins upwards. This puts
both PCI slots' int A and PCIe 16x int A into the right position.
Signed-off-by: Torsten Duwe
On Monday 05 November 2007, Peter Stuge wrote:
On Mon, Nov 05, 2007 at 11:35:02PM +0100, [EMAIL PROTECTED] wrote:
Log:
Fix the M57SLI routing table,
Is this correct for all revisions of the board?
Good question. is there any revision for which the old code worked?
Hint: lspci will surely
On Monday 05 November 2007, Carl-Daniel Hailfinger wrote:
What issues remain for the board now that this has been checked in?
* the MTRR problem
* my ATI atom BIOS still does not init the GFX card, X startup slow
* other INTs (B, C, D) mostly untested
* FireWire untested
* assumed write protect
On Tuesday 06 November 2007 00:40, Torsten Duwe wrote:
On Monday 05 November 2007, Carl-Daniel Hailfinger wrote:
Do you still need irqpoll?
Rebuilding and rebooting right after this mail ... :-)
...now posting from it.
No more irqpoll, glxgears at full performance, both PCI slots' INT
On Tuesday 06 November 2007 00:51, Carl-Daniel Hailfinger wrote:
On 06.11.2007 00:40, Torsten Duwe wrote:
On Monday 05 November 2007, Carl-Daniel Hailfinger wrote:
What issues remain for the board now that this has been checked in?
[...]
* assumed write protect lines to the flash chips
irqpoll rulez !-)
With this kernel option I get full performance from glxgears, but the
interrupts show up under the driver for the only working PCI slot, not the
primary PCIe! Looking at the board layout I see that this one is exactly 4
slots further -- maybe Gigabyte did the classic INT
On Saturday 27 October 2007, Carl-Daniel Hailfinger wrote:
Besides that, there are still unexplained differences between vendor
BIOS and LinuxBIOS in the PCI configuration.
http://linuxbios.org/pipermail/linuxbios/2007-May/021538.html and the
followup
Oh, and io_dump.c is here:
http://linuxbios.org/pipermail/linuxbios/2007-October/025630.html
Thanks!
I'll now reboot to get a diff, and test NoDDC2...
Diff attached, s/^ 2/ 1/ on the LB dump. That board has both PCI slots
populated, in case it matters. Also, the base address was
:08.0 (closer to the board edge) appears, but no interrupts
* PCI 01:0a.0 (FireWire) untested
Since none of these was even present without the patch I suggest to apply it.
Signed-off-by: Torsten Duwe [EMAIL PROTECTED]
--- tmp/LinuxBIOSv2/src/mainboard/gigabyte/m57sli/cache_as_ram_auto.c.orig 2007-07
Hi all,
trying to get my machine into productive use with LinuxBIOSv2 I just found
major issues with the bridge configuration. The primary PCIe cannot generate
interrupts, the other PCIe bridges are configured although the slots are
empty (the legacy BIOS does not do that), and the non-express
Found chipset ICH7M: Enabling flash write... OK.
No EEPROM/flash device found.
Wild guess: a SPI flash not enabled for writing?
Torsten
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
console to hyperterminal output) and I am then back at the grub prompt.
Not too bad. You basically need 3 pieces of information: kernel file, initrd
file and command line. There's probably an isolinux boot loader on the CD.
Look for isolinux.cnf and cat it. Look for the installation entry. The
On Thursday 11 October 2007, ron minnich wrote:
On 10/11/07, Torsten Duwe [EMAIL PROTECTED] wrote:
Found chipset ICH7M: Enabling flash write... OK.
No EEPROM/flash device found.
Wild guess: a SPI flash not enabled for writing?
can you get a look at the board?
Sorry, by replying
Hi all!
Working a little on $SUBJECT, I found a few patches to be necessary to get it
all running. It's far from perfect yet, but I wanted to share with you what
I found so far.
I had to make the config change to Open Firmware similar to that on the
openbios wiki, and change 4 things in the
Open Firmware is a little larger than 256k, so building a LBv2 with normal and
fallback is out of the question with 512k ROMs. This config just builds one
big image. The patch is less useful, the result is much more readable.
Recommendation: supply as alternative config
diff -Burb
A trivial one-liner for the CPU I happen to have. The sales docs said it's
a G1 revision, but the Rev F code works just fine.
Recommendation: please apply.
diff -Burb --exclude=.svn CVS/LinuxBIOSv2/src/cpu/amd/model_fxx/model_fxx_init.c tmp/LinuxBIOSv2/src/cpu/amd/model_fxx/model_fxx_init.c
---
This may look right, but it is a bad kludge. Open Firmware, when biosloaded,
expects a top-of-RAM at physical address 0x1004 ( mem-info-pa 4 + ) , as a
little endian pointer. LinuxBIOS however only provides its tables. There's
currently code in the queue from Jens Freimann to parse the LB
I found qemu to be tremendously accurate and thus time-saving. This patch adds
the add-on/VGA ROM options and increases the image size. A real VGA is not yet
working, no mode is set after power-on but qemu shows exactly the same
behaviour. Requires qemu patches like on
A trivial one-liner for the CPU I happen to have. The sales docs said it's
a G1 revision, but the Rev F code works just fine.
Signed-off-by: Torsten Duwe [EMAIL PROTECTED]
Recommendation: please apply.
diff -Burb --exclude=.svn CVS/LinuxBIOSv2/src/cpu/amd/model_fxx/model_fxx_init.c tmp
Open Firmware is a little larger than 256k, so building a LBv2 with normal and
fallback is out of the question with 512k ROMs. This config just builds one
big image. The patch is less useful, the result is much more readable.
Signed-off-by: Torsten Duwe [EMAIL PROTECTED]
Recommendation: supply
is created, use this evil hack. The
memory map is parsed anyway to find a RAM buffer for the payload, so I just
hook in here to find a 32-bit pointer to the top of RAM, clipped to 3GB, to
not confuse the payload :)
Signed-off-by: Torsten Duwe [EMAIL PROTECTED]
Recommendation: do _NOT_ apply!
I
/Open_Firmware
Signed-off-by: Torsten Duwe [EMAIL PROTECTED]
Recommendation: maybe apply after some testing.
diff -Burb --exclude=.svn CVS/LinuxBIOSv2/src/mainboard/emulation/qemu-i386/Options.lb tmp/LinuxBIOSv2/src/mainboard/emulation/qemu-i386/Options.lb
--- CVS/LinuxBIOSv2/src/mainboard
55 matches
Mail list logo
