I just tried make randconfig to test whether all allowed configuations
can be built. The result was disastrous.
Without a make distclean before make randconfig, I get all sorts of
compile errors for about 60% of the randomly generated .config files.
With make distclean before make randconfig, most of the configurations
This means that some dependencies are wrong, resulting in incorrect builds.
To reproduce, simply run "make randconfig; make;" in a loop. It will
fail after two or three iterations.
This patch fixes lar options parsing, a seg fault with long path names, and
makes use of functions that were already defined. It also adds greedy name
matching for listing and extracting archives, which allows recursive descent
into the lar directory structure.
An example is:
lar -l normal/payload
normal/payload/segment0 (172032 bytes, zeroes compressed to 1 bytes
@0x4330);loadaddress 0x0x112e60 entry 0x0x10e5fc
normal/payload/segment1 (77384 bytes, lzma compressed to 42674 bytes
@0x4390);loadaddress 0x0x100000 entry 0x0x10e5fc
normal/payload/segment2 (72 bytes, lzma compressed to 47 bytes
@0xeaa0);loadaddress 0x0x13ce60 entry 0x0x10e5fc
Total size = 42962B 41KB (0xa7d2)
No matching lar entries found.
add more options to the usage message
use get_larsize() instead of using larsize
rearrange errors from parsing args to be more correct
change elfname size to MAX_PATHLEN instead of 64
make file_in_list greedy with filename matches
change total_size calculation to include file names
change lar_add_entry to use header_len function instead of reinventing
Signed-off-by: Myles Watson <mylesgw(a)gmail.com>
Have three motherboards running cn700, VT8237 chips set. All three
boards have W39V040BPZ bios chips. I can not program them with
flashrom. Flashrom see the chip as W39V040B. Flashrom start on the
flash and just sits there. When flashed with the -V option I can see
the memory address is not changing. But, big problem is the fact that
the chip does get a bit flashed, as, I can no longer boot. So there is
Looking at the data sheet for the W39V040B, all the PZ gives me is the
PLCC package and lead free. So, is this a problem with the vt8237 south
bridge? Where should I go to start debugging?
This is a ready-made script which gathers all information about a system
we could want to evaluate whether porting is possible and/or easy.
The idea behind it is to get loads of people to run the script and help
us analyze coverage of flashrom and superiotool, together with board
distribution among willing testers.
In the future, this could include the ICH GPIO dumper, the K8 resource
dumper, the MCP55 configuration dumper and a few other utilities.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net>
# Coreboot system information gathering script
# This is very Linux-specific right now.
# This script is Copyright (C) 2008 Carl-Daniel Hailfinger
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
# You should have received a copy of the GNU General Public License along
# with this program; if not, write to the Free Software Foundation, Inc.,
# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
lspci -vvvnnxxx >lspci-vvvnnxxx.txt
lspci -t >lspci-t.txt
svn co svn://linuxbios.org/repos/trunk/util/flashrom
./flashrom/flashrom -V >flashrom.txt
rm -rf flashrom
svn co svn://linuxbios.org/repos/trunk/util/superiotool
./superiotool/superiotool -d -e -V >superiotool.txt
rm -rf superiotool
cat /proc/ioports >ioports.txt
cat /proc/iomem >iomem.txt
cat /proc/interrupts >interrupts.txt
cat /proc/cpuinfo >cpuinfo.txt
tar cjf coreboot_data.tar.bz2 coreboot_data/
echo All done. Please send coreboot_data.tar.bz2 to dumps(a)coreboot.org. Thanks.
Is there a way in LB to hide a PCI device from the OS? I want to prevent linux from loading the device driver automatically for a particular PCI device. (Similar to a device behind a bridge). I don't want to do any tweaks in linux.
I appreciate your time.
Never miss a thing. Make Yahoo your homepage.
FYI. I'm interested in reviving the ADLO effort. I sent the
following email to the bochs developers mailing list.
----- Forwarded message from Kevin O'Connor <kevin(a)koconnor.net> -----
From: Kevin O'Connor <kevin(a)koconnor.net>
Date: Thu, 21 Feb 2008 22:31:28 -0500
Subject: [RFC] port bochs-bios to gcc
I'm interested in porting the "bochs bios" code to gcc. This is the
code currently located in the "bochs/bios/" directory - mostly in the
I've gotten my port far enough along to boot a freedos floppy image.
There is still plenty of work to be done, but I believe I have gotten
the code to a point where I can demonstrate that the methodology is
I am looking for comments on the idea, feedback on the code, and
hopefully to spur other developer interest.
In order to use gcc to build 16 bit code, the code uses the
".code16gcc" feature of the gnu assembler (gas). This same option is
used in the boot code of recent Linux kernels.
The code should build using standard gnu tools. (Just untar the
package and run "make".) I use a standard FC8 Linux machine. The
code isn't too big, so I will try to attach it to this email.
As above, the code is in an "early alpha" state, but one should be
able to test it with an emulator. (I tested it with qemu.)
Why do this? My main interest is in eventually getting the code to
run on real hardware. The current rombios.c code is rather scary - it
is about eleven thousand lines of code, of which about a third is
assembler. I'm hoping a port to standard C will spur greater
flexibility and interest in the project.
----- End forwarded message -----
I have not found one tool that can obtain the fadt.c and dsdt.c from the
machine trough /proc/acpi/fadt and /proc/acpi/dsdt
I have write the two utitilities, if one needs it.
NOTE: you can compile the tools simply written "make genfadt" and "make
Trying to figure out if it the payloads (filo) or coreboots
resposiblity to detect a 40 or 80 ribbon IDE cable. Reading the ATA
specifications it looks like a IDENTIFY_DRIVE command query to the
drive is the way it detects this and then the bios sets this in the
IDE pci configuration register. Right now, it does not detect this and
when the Linux IDE driver takes over it only runs at ATA33 not ATA100.
For coreboot to automate this it would have to a IDENTIFY_DRIVE
command query to the drive and then set IDE pci configuration
register. Would this be possible to do pre payload or is this
something that would have to be set manually. If manual could we
impliment a global setting??
IDE_CABLE = 40 or 80
Thanks - Joe