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
> > try to get another ack from Ron or Luc as well.
> >
>
additional CONFIG_NONVGA_ROM_RUN?
>
> This is a good start. I assume you have tested it with abuild. Please
> try to get another ack from Ron or Luc as well.
>
> Acked-by: Carl-Daniel Hailfinger <[EMAIL PROTECTED]>
It looks very good from an initial glance, but i will take a m
option to the
Config.lb with a comment beforehand explaining that, when desired, this
should be enabled. It should not be enabled per default, as those
building an image should at least read and alter the target Config.lb
file.
I do hope that this will finally satisfy you so that i can finally
On Wed, Jan 02, 2008 at 05:31:27PM -0800, ron minnich wrote:
> On Jan 2, 2008 5:03 PM, Luc Verhaegen <[EMAIL PROTECTED]> wrote:
>
> > What i am trying to do is implement native VGA bring-up for unichrome. I
> > have had userspace code doing this on top of a clean linux
as well-known as the epia-m already?
I really do not see what you continue to keep having against this
trivial and rather sane fix.
Luc Verhaegen.
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
On Wed, Jan 02, 2008 at 01:26:10PM -0800, ron minnich wrote:
> On Jan 2, 2008 1:16 AM, Luc Verhaegen <[EMAIL PROTECTED]> wrote:
> > The CONFIG_CONSOLE_VGA and CONFIG_PCI_ROM_RUN logic in
> > src/devices/pci_device.c:pci_dev_init is messed up.
>
> It may be hard to read,
On Wed, Jan 02, 2008 at 03:46:15PM -0800, ron minnich wrote:
> you need a signed-off by ...
>
> Acked-by: Ronald G. Minnich <[EMAIL PROTECTED]>
>
> beautifying is always a good idea.
>
> ron
How bloody insulting.
Luc Verhaegen.
--
linuxbios mailing list
l
done by the relevant
init function of possible (future) VGA setup drivers.
Signed-off-by: Luc Verhaegen <[EMAIL PROTECTED]>
Index: src/devices/pci_device.c
===
--- src/devices/pci_device.c(revision 3031)
+++ src/d
Luc Verhaegen.
flashrom: Add board enable for the EPOX EP-BX3.
Signed-off-by: Luc Verhaegen <[EMAIL PROTECTED]>
Index: README
===
--- README (revision 2742)
+++ README (working copy)
@@ -54,8 +54,8 @@
* Agami Aruma:
On Fri, Aug 10, 2007 at 11:02:42PM +0200, Luc Verhaegen wrote:
> Luc Verhaegen.
Hrm,
This version has some comments :)
Luc Verhaegen.
flashrom: Add board enable for the EPOX EP-BX3.
Signed-off-by: Luc Verhaegen <[EMAIL PROTECTED]>
Inde
s its uses outside linuxbios too. It's quite a few
orders of magnitude harder to provide linuxbios support than it is to
provide flashrom support for any board out there.
Luc Verhaegen.
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Luc Verhaegen.
Flashrom: Add support for Tyan Tomcat K7M.
Same board enable as Asus A7V8-MX. Tested by Reinhard Max.
Signed-off-by: Luc Verhaegen <[EMAIL PROTECTED]>
Index: board_enable.c
===
--- board_enable.c (revisio
On Tue, Jul 03, 2007 at 01:32:36AM +0200, Uwe Hermann wrote:
> On Sun, Jul 01, 2007 at 08:00:57PM +0200, Luc Verhaegen wrote:
> > I fully agree with the earlier stuff, but is there any reason to keep
> > this in the v3 tree? People will not be that unhappy if they're required
independent life.
> The transition should be painless (a simple 'svn up' should do), but
> just in case there are problems, please make sure you save all pending
> flashrom patches/modifications you may have. If there are problems
> please let us know (try a fresh checkout b
his can be retrieved by reverse engineering the bios (although not
all reverse engineering attempts are succesful - you need to find out
where this code lives). For this, the lower 0x400 (6400) bytes, and
0x000E - 0x0010 of memory are needed (on x86).
Not that i have much time c
uld scan all pci devices and list the ones it can
use and list the rom id.
When using -w, a pci tag argument should be required to avoid mistakes.
-r with -p can happen if only one possible device is found.
Luc Verhaegen.
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
7;t fun any more :)
Also, implementation wise, we might want flashrom to take in a pcitag
for this sort of flashing to be enabled. This is a reasonably idiot
proof solution as to not accidentally flash the wrong rom to the wrong
place.
Luc Verhaegen.
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
nvert this to C routines for flashrom. I will be very happy to do
this when i have the time, which is, at the earliest, somewhere next
week.
Luc Verhaegen.
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
award bios.
> Is there a hidden switch to assure awdflash to write the image ?
>
>
> --
> Gruß
>
> Dieter
Which board is this?
Luc Verhaegen.
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
s based on the CLE266 + C3, they
usually carry those same ids. Ain't that cute?
Luc Verhaegen.
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
On Sat, May 26, 2007 at 07:26:54PM -0700, Russ Whitaker wrote:
>
>
> On Sun, 27 May 2007, Luc Verhaegen wrote:
>
> > On Sat, May 26, 2007 at 05:29:28PM +0200, Stefan Reinauer wrote:
> >>>
> >>> No, this is purely to get 640x480 textmode to work on the C
currently doing though,
i will need to make it possible to use textmode on DVI or a panel on the
CLE266. That way all basic needs are taken care of.
Luc Verhaegen.
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
itors.
But then, i prefer to spend time on a full featured FB driver instead.
Luc Verhaegen.
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
course insert a full modesetting system, but that will mean
doing things like EDID parsing and cvt modeline generation in linuxbios.
And this will all be getting rather big rather quickly.
[EMAIL PROTECTED] is somewhat safe, as most devices on the CRT connection
will be able to handle this, a
On Fri, May 25, 2007 at 10:38:48PM +0200, Peter Stuge wrote:
> On Fri, May 25, 2007 at 06:39:20PM +0200, Luc Verhaegen wrote:
> > > an EPIA/-M/-MII workshop on Saturday 2/6
> >
> > Hrm, makes me wish i had already finished the direct unichrome
> > support for it.
&
s, that it runs np from userspace,
but that it needs further work integrating in linuxbios. I'm pretty much
stuck until halfway june, though.
Luc Verhaegen.
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
On Tue, May 15, 2007 at 12:34:12PM +0200, Peter Stuge wrote:
> On Tue, May 15, 2007 at 12:11:26PM +0200, Luc Verhaegen wrote:
> > The Asus P5A also seriously messes up pci-ids, there is nothing
> > dependable there, so people who want to use flashrom on this board
> > s
sses up pci-ids, there is nothing
dependable there, so people who want to use flashrom on this board
should use -m asus:p5a
but it works :)
This is a board i own myself and this has been tested successfully.
Luc Verhaegen.
flashrom: add support for asus p5a (Socket7, ALI based)
* Add support fo
ime, which makes the willem _extremely_ slow.
To be honest, i haven't needed it yet, hotswapping is much much faster
anyway and hasn't gone wrong yet.
So don't bother. You're only throwing money away. Just buy some roms.
Luc Verhaegen.
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Uwe.
Nope. Nothing here for the time being.
Luc Verhaegen.
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
On Fri, May 04, 2007 at 06:47:14AM +0200, Peter Stuge wrote:
> On Fri, May 04, 2007 at 06:10:29AM +0200, Luc Verhaegen wrote:
> > You can take this sort of thing very far
> > A single bitwise clear is:
> > wbsio_mask(reg, 0x00, 0x10);
> >
> > A single bitwi
On Fri, May 04, 2007 at 04:39:30AM +0200, Peter Stuge wrote:
> On Fri, May 04, 2007 at 12:50:47AM +0200, Luc Verhaegen wrote:
> > Add WinBond Super IO helpers.
>
> Looks very good except for one small thing..
>
>
> > +wbsio_mask(unsigned char index, unsigned char data
some things from the old iwill code.
* Moved all board functions name argument to const.
(warning breaks build)
* Moved iwill entry in board_pciid_enables.
Signed-off-by: Luc Verhaegen <[EMAIL PROTECTED]>
Index: board_en
there, that's what counts.
New patch will be sent in shortly.
Luc Verhaegen.
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
ith just some comments added.
I will look into writing
static int W83627HFGPIORaise(int Port);
which handles the raising of GPIO20-27 on this very superIO.
This would reduce the two relevant board enables and stop mistakes like
this from happening ever again.
Luc Verhaegen.
Add Winbond SuperIO
>
> > X.org driver developer.
>
> Please tell me I'm not the only one who finds this ironic :p
>
> -Corey
I've been fighting VBE for years. Which is why my driver was so happy
with plain linuxbios. I'm not about to start a direct VBE replacement,
it only makes driver developers lazy.
Luc Verhaegen.
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
On Wed, May 02, 2007 at 10:36:00PM +0200, Peter Stuge wrote:
> On Wed, May 02, 2007 at 10:10:33PM +0200, Luc Verhaegen wrote:
> > On Wed, May 02, 2007 at 11:49:53AM -0700, Vlad wrote:
> > > 1) Bootsplash in both LinuxBIOS and bootloader, with a message
> > > along the
the functions,
and you'll see that it really makes a lot of difference, even on such a
small file. 3 out of 4 board enables make use of it though.
Luc Verhaegen.
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
be wrong with a curses utility? ( For those who prefer a
bit of bling that is)
Really, what is this drive for GUIs. What's wrong with a nice command
line utility.
If you need a gui to configure and flash your bios, then maybe you
shouldn't be touching your bios at all.
Luc Verhaege
On Sat, Apr 28, 2007 at 02:00:42AM +0200, Uwe Hermann wrote:
> On Fri, Apr 27, 2007 at 10:33:53PM +0200, Luc Verhaegen wrote:
> > On Fri, Apr 27, 2007 at 04:44:10PM +0200, Mondrian Nuessle wrote:
> > > Actually you do not need to set the index reg twice. I just used the
> >
_mask(0x2B, 0xD0, 0xD0); /* Set GPIO regs... */
I don't think that these functions need to live outside board_enable.c
The size of them will already largely be made up for by the code we
save with this.
Luc Verhaegen.
PS: Mondrian, there is no need for your patch to also implement this.
On Fri, Apr 27, 2007 at 01:17:27PM +0200, Luc Verhaegen wrote:
> On Fri, Apr 27, 2007 at 01:01:19PM +0200, Mondrian Nuessle wrote:
> > The attached patch enables flashing on the Iwill DK8-HTX board.
> > Basically, it configures the SuperIO to set the right GPIO pins, so
> >
for tabs setting, removed now. I had assumed that this
was handled earlier, when stepan committed my code when i was too busy
to fix things then. Sorry for that.
It will probably still exist in other places of flashrom too, nothing
you should worry about though.
Luc Verhaegen.
--
linuxbi
be touched as well. You might want to
add the AGAMI:ARUMA.
This name matching is rather safe now, as you have to match at least one
set of main pci-ids. This will stop joe simple from simply running down
the list of board enables.
Luc Verhaegen.
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
er no matching
> board could be found. Just to be safe :-)
>
> Regards,
> Mondrian
Many boards often are happy with just the chip enable, so warning about
unknown board there would just be intrusive.
Luc Verhaegen.
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
e a
> warning message if the board could not be identified should be printed.
> I could provide a patch in that direction. What do you think?
>
> Mondrian
>
Provide linuxbios name and only main ids and the matcher will not try to
match on pci-ids.
Luc Verhaegen.
--
linuxbios mailing
igns are going to be a problem. Vendors should
imho just be more responsible about these things. As it's pure stupidity
that stop this neat functionality to be universally useful. This mess
happens everywhere though, DDC/EDID (monitors) is pretty much the same
story.
Luc Verhaegen.
--
lin
bsystem: 0e55:2928
>
> 01:06.0 0300: 1002:4752 (rev 27)
> Subsystem: 1002:
>
> 02:03.0 0200: 8086:1076
> Subsystem: 8086:1076
>
> 02:04.0 0200: 8086:1076
> Subsystem: 8086:1076
>
> 02:05.0 0180: 1095:3114 (rev 02)
> Subsystem: 1095:3114
0x1022:0x2B80 indeed does seem like a solid and very deliberate
subsystem id here.
Luc Verhaegen.
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
s reliable as the board vendors. There are
other options, but pci subsystem ids are very universal and easy to
retrieve. Vendor error is the big let-down here, although, for the
unichrome, there has been some albeit minimal positive evolution over
the years.
Luc Verhaegen.
--
linuxbios mailing
guration registers?
>
> Best,
> Ning
>
> On 4/25/07, Luc Verhaegen <[EMAIL PROTECTED]> wrote:
> >
> >There are two full sets of pci ids possible in that structure.
> >
> >A full set consists of:
> >* vendor id
> >* device id
> >* subsyste
ystem ids of the device matched by 0x1022,
0x7468 are 0x1022, 0x7468 too?
Please just find 2 different devices from your motherboard that have
subsystem ids that differ from the main ids. That way, you don't need to
provide the board name as an argument.
Yes, once linuxbios is inst
On Wed, Apr 11, 2007 at 09:58:32PM +0200, Luc Verhaegen wrote:
> On Wed, Apr 11, 2007 at 11:34:59PM +0400, Anton wrote:
> > Ah, yeah. I'm not sure how the code in board_asus_a7v8x_mx()
> > corresponds with ASUS_FLASH structure. There is completely different
> > code.
>
some time on some other flash enables i promised over the past few
weeks though. :)
Luc Verhaegen
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
revision.
>
> Thanks.
>
You're probably talking about the board enable code i added?
My test system was a A7V400-MX, a rebadged A7V78X-SE.
It's no problem to dig out the bioses of the two boards listed above. I
would like to see some pci subsystem ids though.
Luc Verhaege
can be bundled together and stuck
on the wiki.
Luc Verhaegen.
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
On Mon, Apr 02, 2007 at 12:36:28AM +0200, Uwe Hermann wrote:
> Here's a quick review:
>
> On Mon, Mar 26, 2007 at 04:59:18PM +0200, Luc Verhaegen wrote:
> > been relegated to flash_rom.c. Then there's only some extraneous
> > whitespace removal and replacing // w
, a patch
that already won't apply cleanly anymore thanks to the ICH7 commit.
Luc Verhaegen.
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
On Mon, Mar 26, 2007 at 04:59:18PM +0200, Luc Verhaegen wrote:
> Done.
>
> The island aruma got renamed to agami aruma at some point, the board
> specific match has been adjusted to that now. I hope that the pci ids i
> gathered from its src/mainboards/ directory are ok. I of
The NDA itself pretty much tells you you're not
allowed to disclose anything, the addendum tells you that you're allowed
to disclose everything, except that bit with gpled code VIA handed you
directly.
Luc Verhaegen.
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
on of (only) GPLed code VIA handed to you directly
but hasn't made generally public (yet). It therefor directly forces you
to breach the GPL.
Daft, clueless, useless and will probably not stand in court.
A typical example of VIA stupidity.
Luc Verhaegen.
http://unichrome.Sf.net/
--
linuxbi
On Mon, Mar 26, 2007 at 08:52:16AM +0200, Luc Verhaegen wrote:
> On Sun, Mar 25, 2007 at 06:05:51PM +0200, Luc Verhaegen wrote:
> > On Sun, Mar 25, 2007 at 01:40:23AM -0400, Corey Osgood wrote:
> > >
> > > Luc, could you check out the PCChips M789CG for me and see i
ere's only some extraneous
whitespace removal and replacing // with /* */. I'm not sure how svn
handles moving of files, but that's usually a good point to do such
function-less changes.
Has been tested on all the same machines again. Needs a quick test on
the agami.
Luc Verhaegen.
On Sun, Mar 25, 2007 at 06:05:51PM +0200, Luc Verhaegen wrote:
> On Sun, Mar 25, 2007 at 01:40:23AM -0400, Corey Osgood wrote:
> >
> > Luc, could you check out the PCChips M789CG for me and see if this can
> > support it? The stock bios is an AMIBIOS (if it mat
t; > future.
>
> Yes, indeed. Luc, could you make this an extra file? Then I'll commit
> it.
>
Yeah, sure. Any idea about sensible naming? chip_enable.c and
board_enable.c?
Luc Verhaegen.
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
ks,
> Corey
>
I'll hand you a bit of python in a few hours that gathers the following
information.
* Int16 vector for AMI
* Dump of 0xE-0xF. The int16 vector should live here, and the
AWDFLASH structure exists here too.
So a tiny bit of python will provide for A
On Fri, Mar 23, 2007 at 07:46:45AM +0100, Peter Stuge wrote:
> On Fri, Mar 23, 2007 at 06:47:43AM +0100, Luc Verhaegen wrote:
> > This patch adds initial flashrom support for matching mainboards
> > based on pci-ids and pci subsystem/card ids.
>
> Acked-by: Peter St
On Fri, Mar 23, 2007 at 06:42:46PM +0100, Stefan Reinauer wrote:
> * Luc Verhaegen <[EMAIL PROTECTED]> [070323 06:47]:
> > This patch adds initial flashrom support for matching mainboards based
> > on pci-ids and pci subsystem/card ids.
>
> > This code works c
rted with little effort, all it takes is
the output of lspci -vn.
Commit message, signed-off, etc are done git-style.
Luc Verhaegen.
flashrom: Add board specific flash enables based on matching pci-ids.
* Matches mainboards with up to two full sets of pci-ids, and if matched
calls the respecti
On Sat, Mar 17, 2007 at 04:29:50PM +0100, Stefan Reinauer wrote:
> * Luc Verhaegen. <[EMAIL PROTECTED]> [070317 15:39]:
> > Are you saying there that, for the likes of filo, grub, etherboot, etc
> > will be forced to set up a full VGA console themselves?
>
> Not m
On Sat, Mar 17, 2007 at 03:03:37PM +0100, Stefan Reinauer wrote:
> * Luc Verhaegen. <[EMAIL PROTECTED]> [070317 14:04]:
> > > I want it to go into a nice picture/or solid color
> > > within less a second after press the ON button.
> >
> > Yes, people do s
hink it is possible?
Possible... linuxbios is, what, 99% C. So you can pretty much do
anything if it fits into your rom. So it is possible.
But the real question is, is it sensible? And the answer there is:
absolutely not.
Luc Verhaegen.
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
u've probably done
something wrong, as it's all pretty happy here. But it's nothing lethal
anyway, just inconvenient :)
The only time i did brick it here is when i did try to run a VGA BIOS
(at a wrong, hardcoded offset), so don't worry too much, just be very
careful :)
O
On Tue, Mar 13, 2007 at 12:57:27AM -0400, [EMAIL PROTECTED] wrote:
> Quoting Luc Verhaegen <[EMAIL PROTECTED]>:
>
> > On Tue, Mar 13, 2007 at 04:50:47AM +0100, Quux wrote:
>
> I understand video encoders are not standalone. They receive input
> from your GPU, in my
device local I2C/GPIO lines.
So this is an integral part part of graphics device initialisation.
As such, it is all up to the VGA BIOS, or, if available, up to the
direct support of certain graphics devices.
Luc Verhaegen.
http://unichrome.sf.net/
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
On Sat, Mar 03, 2007 at 08:26:07AM +0100, Luc Verhaegen wrote:
> On Fri, Mar 02, 2007 at 05:22:57PM +0100, Uwe Hermann wrote:
>
> > I think we should have a section in the FAQ/wiki about all these
> > CrashFree, Virtual DualBIOS and whatnot features...
>
> Hrm.
>
&g
On Fri, Mar 02, 2007 at 11:17:56PM +0100, Uwe Hermann wrote:
> On Fri, Mar 02, 2007 at 03:43:07PM +0100, Stefan Reinauer wrote:
> > > Signed-off-by: Luc Verhaegen <[EMAIL PROTECTED]>
> > Acked-by: Stefan Reinauer <[EMAIL PROTECTED]>
>
> Committed in r256
On Fri, Mar 02, 2007 at 05:22:57PM +0100, Uwe Hermann wrote:
> On Fri, Mar 02, 2007 at 04:09:28PM +0100, Luc Verhaegen wrote:
> > This motherboards BIOS is supposed to have a "CrashFree" BIOS, and i
> > have a hard time finding out what that actually is supposed to do
enjoy this protection feature without the need to pay
for an extra ROM."
There have been several of these crashfree things in the course of a few
years, all are more or less equally obscure.
Luc Verhaegen.
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
; Uwe.
Verified on:
CLE266 + VT8235
KM400 + VT8237
K8M800 + VT8235
I have no VT8231 at my disposal, but the codepath is and used to be the
same for VT8237.
Luc Verhaegen.
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
This fixes the warning that's present for all VT8235 southbridges:
...
Enabling flash write on VT8235...tried to set 0x4 to 0x14 on VT8235 failed
(WARNING ONLY)
...
It's bourne from misinterpreting the return value of pci_write_byte,
which peculiarly returns 1 for success.
Luc
80 matches
Mail list logo
