Hi,
Why is it problem to boot from an usb port when we are using linuxbios and
filo. as I can see all usb code are there, what is missing?
Thanks,
/Masoud
Add initial support for i855gme. This is a work in progress and I
don't expect it to work on all boards, or even any besides mine. This
is based heavily on i855pm.
Signed off by Jon Dufresne <jon.dufresne(a)gmail.com>
This patch includes config files for the asus/a8n5x port. It is the same as
asus/a8n_e with a different pnp layout, so I used #include's whenever possible.
System boots and is usable with usb keyboard.
works:
- serial port
- vga (old pci card)
- memtest86+ succeeds, but only with Rudolf's patch for unbuffered dimms
in K8. Otherwise you get spurious memory corruption.
- ide disk
- usb
doesn't:
- ps/2 keyboard
- onboard ethernet
- vga pci-e card (??)
- any other pci card I tried
wasn't tested:
- sata
- game port
- onboard audio (not supported by alsa anyway)
- ps/2 mouse
--
Robert Millan
<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)
Is there a magic number for LZMA? Should there be?
I accidentally used an uncompressed payload with v2 when it expected a
compressed payload, and it gave me the message:
Decoder scratchpad too small!!
Decoding error = 1
I think it would be nicer to have an error like:
Payload not compressed with lzma!
Myles
On two boards, one MCP55 based and another CK804, if I flash the
proprietary BIOS with: flasrom -wv bios.bin
Verification fails and if I try to boot, it doesn't. Have to flash the
BIOS in another board based on K8T890 that I have. In that one all
works fine, with both BIOS chips I have - one winbond and a PMC.
Haven't tried flashing coreboot due to lack of support.
Since the chipsets are support, this isn't supposed to happen, right?
Best regards,
Tiago Marques
On 1/27/08, Stefan Reinauer <stepan(a)coresystems.de> wrote:
> * Tiago Marques <tiagomnm(a)gmail.com> [080127 16:21]:
> > Hi.
> > Both failed, tried with two different BIOS chips.
> > Flashing with AWDFlash works fine though.
> > Had to flash it again in a VIA K8T890 board, which works flawlessly.
> > Any ideas, fix?
>
> What's the problem?
>
> --
> coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
> Tel.: +49 761 7668825 • Fax: +49 761 7664613
> Email: info(a)coresystems.de • http://www.coresystems.de/
> Registergericht: Amtsgericht Freiburg • HRB 7656
> Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
>
Attached is a patch that enables AMD Geode CS5536 chipset support. I
have tested it successfully on a MSM800 board from digital logic. It
does, however, have a few issues that I would like some feedback on.
In my discussions with Marc Jones, Geode systems write protect the BIOS
via RCONFs (cache settings similar to MTRRs). Unlocking requires
changing MSR 0x1808 top byte to 0x22. Reading and writing to the msr,
however, requires instrucitons rdmsr/wrmsr, which are ring0 privileged
instructions so only the kernel can do the read/write. So my patch uses
the msr kernel module to access these instructions from user space using
the /dev/cpu/0/msr device.
My questions are:
- I do not think this is portable beyond linux. Is that an issue?
- My code assumes the msr kernel module is already loaded. Is there a
way to force a kernel module to load from the C code? My code does die
gracefully with a message reminding them to load the kernel module if
things fail.
- It seems like there should be a way to revert the msr back after
flashing is completed to put the bios back in write protect mode. Is
there a cleanup mechanism available? Something like disable_flash...
Thanks,
Lane Brooks
It now finds the part, and gets ready to program it, but exits
instantly without doing anything. I think this is the culprit:
void generic_spi_page_program(int block, uint8_t *buf, uint8_t *bios)
{
if (it8716f_flashport)
it8716f_spi_page_program(block, buf, bios);
}
i.e. the flashport is not set. So, before I dig too far into this, is
there some simple thing I should look at to get flashrom working on
this board?
Also, seems to me it's a pretty serious error if this can not be
determined, ... anyone mind if I add an error message? right now it
exits with no error, having done no work :-)
thanks
ron
Sorry to be a pain, but any progress with this?
Thanks,
Corey
> OK, thank you.
> My employer approved the submission. I"ll do it soon.
>
> On Nov 26, 2007 1:24 AM, Corey Osgood <[EMAIL PROTECTED]> wrote:
>
> > Fridel Fainshtein wrote:
> > > OK,
> > >
> > > supposing FILO USB works
> > > How do I submit the corrections?
> > >
> >
> > http://www.linuxbios.org/Development_Guidelines#How_to_contribute
> >
> > In short form:
> > 1) cd to the filo-0.5/ folder
> > 2) svn add * -R (if you've created any new files, be sure to move files
> > you don't want added first)
> > 3) svn diff > clever_patchname.patch
> > 4) edit the patch, add a short description of what the patch does (which
> > goes into the svn commit log) and a Signed-off-by: line, per the
> > guidelines linked to above.
> >
> > Thanks!
> > -Corey
> >
Hi Uwe,
Thanks for the review. I have updated the patch based on your review.
The new patch needs Nikolay's CS5530/CS5536 PIRQ patch.
I cannot run superiotool with the factory BIOS because the BIOS is WinCE.
WakeOnLan doesn't work out of the box. The original thin-clients
manager is able to on/off WOL feature as far as I remember.
It's a PC97317 board. Strange, the superiotool r2992 says "No Super I/O found"
NIC is soldered on the motherboard, and it resides on pci 15.0. Fixed
the config entry.
Floppy connector may be available in one of the pin headers but I
can't confirm. I leave it off to be conservative.
COM2 is a regular DB9 serial. Fixed the comment.
irq_tables.c in the previous patch was re-generated by getpir tool,
and manually edited. However I had no way of testing it. Linux kernel
won't read it unless patched, you know. Anyway I reworked on this
file using Nikolay's irq patch.
As for MiniPCI slot there are INTA and INTB by definition of the
MiniPCI. lspci output had no 14.0 because it's a slot.
I installd a WiFi card to the MiniPCI slot(PCI 14.0) for testing. It
got IRQ9 and worked great!
Regards,
Kenji Noguchi
We had that patch in a larger package about 7 weeks ago, but most parts
of the package have been merged since then, reducing the clutter in the
patch to zero. For your reference:
Message-ID: <470EA5CF.2020409(a)gmx.net>
Date: Fri, 12 Oct 2007 00:38:07 +0200
AFAIK not all architectures start executing code at the top of ROM, some
start at the bottom (low address). In that case, we can't start the
archive with a LAR header, but we can end it with one or postfix the
first archive member with a LAR header. To achieve that, the patch
redefines offset as signed instead of unsigned and allows the lar header
after the boot block to point to the boot block at the beginning. That
way, even bottom boot architectures can use the existing header format
unless the first LAR member is bigger than 2 GB.
This patch also introduces a 2 GB limit for file names in LARchives and
a 2 GB limit for unused space between header and data. There is no new
restriction for member lengths or archive length.
Current LAR archives look like this:
Hn=header n
-=padding
Dn=data n
H0D0D0D0H1D1----H2D2D2
where the last bytes of D2 are executed after poweron.
The patch (together with signed offset) makes archives like the below
one possible:
D0D0D0H0H1D1----H2D2D2 (header after boot block points to boot block)
The new archive format possibility allows placing a boot block at the
beginning without sacrificing the goal of one common archive format.
However, there are two potential problems:
- Endless loops if we aren't careful when walking the LAR. I think I got
all corner cases right.
- "Nobody will need more than 640kB", in our case it would be 2GB boot
blocks.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net>
Index: LinuxBIOSv3-larheaderaftermember/include/lar.h
===================================================================
--- LinuxBIOSv3-larheaderaftermember/include/lar.h (Revision 539)
+++ LinuxBIOSv3-larheaderaftermember/include/lar.h (Arbeitskopie)
@@ -61,7 +61,15 @@
u32 reallen;
u32 checksum;
u32 compchecksum;
- u32 offset;
+ /* The offset is signed to allow header after data for the first member
+ * of the LAR. This is needed if code execution starts at bottom of
+ * flash instead of at top of flash (x86). Please note that a
+ * header-after-data LAR member can't be larger than 2^31 bytes.
+ * Right now, we are about five orders of magnitude away from such a
+ * beast.
+ * Filenames are limited to 2^31-1-sizeof(lar_header)-1 bytes.
+ * "Nobody will ever need more than 640k" */
+ s32 offset;
/* Compression:
* 0 = no compression
* 1 = lzma
Index: LinuxBIOSv3-larheaderaftermember/lib/lar.c
===================================================================
--- LinuxBIOSv3-larheaderaftermember/lib/lar.c (Revision 539)
+++ LinuxBIOSv3-larheaderaftermember/lib/lar.c (Arbeitskopie)
@@ -116,7 +116,9 @@
if (strcmp(fullname, filename) == 0) {
printk(BIOS_SPEW, "LAR: CHECK %s @ %p\n", fullname, header);
- result->start = walk + ntohl(header->offset);
+ /* In the header-before-member case offset is at least
+ * sizeof(header) + strlen(filename) + 1 */
+ result->start = walk + (s32)ntohl(header->offset);
result->len = ntohl(header->len);
result->reallen = ntohl(header->reallen);
result->compression = ntohl(header->compression);
@@ -137,9 +139,30 @@
* In the case of consecutive archive members with header-
* before-member structure, the next iteration of the loop will
* start exactly at the beginning of the next header.
- */
+ * In the case of header-after-member (e.g. for bottom boot
+ * architectures) the calculation below will effectively cause
+ * walk < header. To elaborate a bit more, in this case
+ * (header->offset + header->len - 1) will evaluate to a value
+ * between -1 (header directly after file), -16 (file, 15 bytes
+ * pad, header), and even smaller values if there is 16 bytes
+ * or more of padding between member and header. The outer
+ * expression will usually evaluate to 0xfffffff0, cause the
+ * expected overflow with unsigned arithmetic and result in a
+ * decrease of walk. That condition can be checked. */
+#warning FIXME: This loop will explode if this code is ever compiled in 64bit mode
+#warning because of the hardcoded 0xfffffff0.
walk += (ntohl(header->offset) + ntohl(header->len) - 1)
& 0xfffffff0;
+ /* If we have header-after-member, walk < header is true.
+ * Go forward instead by starting at header, adding header size
+ * and strlen(fullname). The result of this calculation is the
+ * position of the terminating \0 of fullname. Round that
+ * address down to the next 16 byte boundary. */
+ if (walk < (char *)header) {
+ walk = (char *)header;
+ walk += (sizeof(struct lar_header) + strlen(fullname))
+ & 0xfffffff0;
+ }
}
printk(BIOS_SPEW, "LAR: File not found!\n");
return 1;
Index: LinuxBIOSv3-larheaderaftermember/util/lar/lar.h
===================================================================
--- LinuxBIOSv3-larheaderaftermember/util/lar/lar.h (Revision 539)
+++ LinuxBIOSv3-larheaderaftermember/util/lar/lar.h (Arbeitskopie)
@@ -60,6 +60,7 @@
typedef uint64_t u64;
typedef uint32_t u32;
typedef uint8_t u8;
+typedef int32_t s32;
/* NOTE -- This and the user-mode lar.h may NOT be in sync. Be careful. */
struct lar_header {
@@ -68,9 +69,15 @@
u32 reallen;
u32 checksum;
u32 compchecksum;
- /* Filenames are limited to 2^31-1-sizeof(lar_header)-1 bytes.
+ /* The offset is signed to allow header after data for the first member
+ * of the LAR. This is needed if code execution starts at bottom of
+ * flash instead of at top of flash (x86). Please note that a
+ * header-after-data LAR member can't be larger than 2^31 bytes.
+ * Right now, we are about five orders of magnitude away from such a
+ * beast.
+ * Filenames are limited to 2^31-1-sizeof(lar_header)-1 bytes.
* "Nobody will ever need more than 640k" */
- u32 offset;
+ s32 offset;
/* Compression:
* 0 = no compression
* 1 = lzma
