Hi,
Alvar Kusma found a bug in util/lar: If you try to add a file to a full
LAR archive, the LAR utility will segfault. This is reproduced easily by
zerofilling the LAR, then adding anything to it.
Looking at the code, the reason is obvious:
lar_empty_offset() can return an error code (-1). None of the callers
check for an error code, they simply assume the return value is valid.
Preliminary patch follows (and raises a few questions).
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net>
Index: util/lar/lar.h
===================================================================
--- util/lar/lar.h (Revision 646)
+++ util/lar/lar.h (Arbeitskopie)
@@ -58,7 +58,9 @@
#define BOOTBLOCK_NAME_LEN 16
typedef uint64_t u64;
+typedef int64_t s64;
typedef uint32_t u32;
+typedef int32_t s32;
typedef uint8_t u8;
/* NOTE -- This and the coreboot lar.h may NOT be in sync. Be careful. */
Index: util/lar/stream.c
===================================================================
--- util/lar/stream.c (Revision 646)
+++ util/lar/stream.c (Arbeitskopie)
@@ -492,7 +492,7 @@
* @param lar the LAR archive structure
* @return The offset of the first chunk of empty space
*/
-static int lar_empty_offset(struct lar *lar)
+static s64 lar_empty_offset(struct lar *lar)
{
u32 offset = 0;
struct lar_header *header;
@@ -508,10 +508,12 @@
offset += get_next_offset(header);
}
- if (offset >= get_bootblock_offset(lar->size))
+ if (offset >= get_bootblock_offset(lar->size)) {
+ err("No empty space found!\n");
return -1;
+ }
- return offset;
+ return (s64)offset;
}
/**
@@ -825,11 +827,16 @@
int maxsize(struct lar *lar, char *name)
{
int size;
- u32 offset;
+ s64 offset;
int bootblock_size;
/* Find the beginning of the available space in the LAR */
+#warning We should check all chunks of free space in the LAR. Right now we do not return the maximum size, but the size of the first chunk.
offset = lar_empty_offset(lar);
+ if (offset < 0) {
+ err("maxsize is negative\n");
+ return offset;
+ }
/* Figure out how big our header will be */
size = get_bootblock_offset(lar->size) - offset - header_len(name,NULL) - 1;
@@ -878,7 +885,7 @@
int ret, hlen;
int pathlen;
u32 *walk, csum;
- u32 offset;
+ s64 offset;
/* Find the beginning of the available space in the LAR */
offset = lar_empty_offset(lar);
@@ -886,7 +893,8 @@
/* Figure out how big our header will be */
hlen = header_len(pathname, &pathlen);
- if (offset + hlen + complen >= get_bootblock_offset(lar->size)) {
+ if ((offset < 0) ||
+ (offset + hlen + complen >= get_bootblock_offset(lar->size))) {
err("Not enough room in the LAR to add the file.\n");
return -1;
}
Hello-
My name is Andrew Knechel. We are trying to use Televideo 7020's as
linux thin clients and I saw a posting that you were able to do
something similar. Can you provide me with any details that would be
useful?
Thank you in advance for any help you can provide.
Andrew Knechel
Director of Technology
732-873-2400 X254
aknechel(a)franklinboe.org
Hello,
I remember a while back there was an issue with filo booting usb
drives. Now that I got my USB working, when I try to boot I get this:
Booting 'uda:/isolinux/vmlinuz console=tty0 console=ttyS0,115200n8
initrd=uda:/isolinux/initrd.img text'
LinuxLabs USB bootloader
Out of heap space
Was there ever a resolution to this??
Thanks - Joe
Hi,
I havew some doubts on what you mentioned regarding the flow.
...It is added inline.
Regards,
Viswesh
On Wed, Mar 26, 2008 at 11:47:56PM -0700, Viswesh S wrote:
> > But why are you doing this anyway? Wouldn't it be easier to just
> > look at the source code?
>
> [Viswesh] The source code doesnt give you the functional flow.
It does, but the source code flow is not obvious in v2.
> Taking one example, if we look at entry32.inc, we cant see that the
> next function is fpu_start.
No, but mainboard/*/*/Config.lb is also part of the source code.
Think of it as a macro file that is processed to generate code.
Following mainboardinit entry32.inc there is mainboardinit
cpu_reset.inc and then mainboardinit fpu_enable.inc.
Again, this design is in no way optimal and big improvements have
been made in the new version 3 of coreboot. :)
[Viswesh] If we look at the disassembled code, the flow according to me is that,
from the reset_vector --> _start --> _protected_start --> _fpu_start.
And I dont understand the usage of the config.lb in the build.
Can somebody explain it.
//************** Config.lb for qemu-x86***********************
## Build our 16 bit and 32 bit coreboot entry code
##
mainboardinit cpu/x86/16bit/entry16.inc
mainboardinit cpu/x86/32bit/entry32.inc
ldscript /cpu/x86/16bit/entry16.lds
ldscript /cpu/x86/32bit/entry32.lds
##
## Build our reset vector (This is where coreboot is entered)
##
mainboardinit cpu/x86/16bit/reset16.inc
ldscript /cpu/x86/16bit/reset16.lds
### Should this be in the northbridge code?
mainboardinit arch/i386/lib/cpu_reset.inc
##
## Include an id string (For safe flashing)
##
mainboardinit arch/i386/lib/id.inc
ldscript /arch/i386/lib/id.lds
###
### O.k. We aren't just an intermediary anymore!
###
##
## Setup RAM
##
mainboardinit cpu/x86/fpu/enable_fpu.inc
mainboardinit ./auto.inc
***************************** *********************************
Also anybody has Top2005 Sw for linux ?
Regards,
Viswesh
> If we dump the elf file we can actually see the next function which
> is being called, one of the reasons why I looked at the assembly
> code.
>
> I like to understand the assembly code also, but right now the
> utmost priority is to understand the functional flow.
I understand. But look into Config.lb, or even ask on this list, I
think you will get faster results. :)
> Suppose you modify the linux bios, using linux how do u flash it to
> the chip ?
>
> Do you have in system code for it (or) any tool which does it for
> you.
There is a tool called flashrom in util/flashrom/. Remember to erase
before writing to flash when using it.
> Is it better that I write code to write the coreboot to the bios
> chip.
The flashrom tool already supports a number of flash chips and
chipsets, but if your hardware is unsupported or not working properly
and you add code to make it work, please send a signed-off patch to
the list. (See the Coding guidelines in the wiki.)
//Peter
------------------------------
_______________________________________________
coreboot mailing list
coreboot(a)coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
End of coreboot Digest, Vol 37, Issue 177
*****************************************
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
On 27.03.2008 04:19, Jake Peavy wrote:
> I'd be interested in trying to help with this effort. It would be certainly
> be a learning experience for me.
>
> If Coreboot has been ported to PPC it might be very similar. Both PPC and
> MIPS architectures are RISC based, but maybe that's where the similarities
> end.
>
Well, only v2 has been ported to PPC and the structure of v3 is
radically different. However, the v3 structure allows much easier
porting, so I think v3 would be your preferred target.
> Based on http://www.mips.com/media/files/MD00103-2B-4KE-SUM-02.04.pdfsection
> 6.1.5, MIPS execution begins at 0x1FC00000. At least on the MIPS32 core I
> have ;-)
>
I assume MIPS boards have some sort of ROM. How is that ROM mapped into
the address space? Does execution begin at top of ROM, bottom of ROM or
somewhere in between? That info is needed to check if our current ROM
format (LAR) can handle MIPS or if we need to apply one of my patches.
> You mentioned payload, is this typically the S1 (MBR) code in x86 arch?
>
It's a bit more complicated like that. A payload can either be a boot
loader (like GRUB2/FILO) or an operating system (like Plan 9/Linux). It
can also be some sort of bootloader-with-shell environment (like
EFI/OpenFirmware) or something with a completely different scope (like
Memtest).
Regards,
Carl-Daniel
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
Hi all,
New member here so forgive this question if it's ridiculous.
Has anyone looked at porting Coreboot onto MIPS architecture? Can it be
used as a Yamon replacement?
Thanks,
Jake
--
-jp
If you're in a war, instead of throwing a hand grenade at the enemy, throw
one of those small pumpkins. Maybe it'll make everyone think how stupid war
is, and while they are thinking, you can throw a real grenade at them.
deepthoughtsbyjackhandy.com
Hello,
I am having a problem getting coreboot->Linux initialize any high
speed USB 2.0 devices like flash drives. The USB works fine on low
speed USB 1.1 devices like keyboards and mice. I don't think coreboot
-> i82801xx_usb_ehci.c is initializing the device correctly. According
to the Intel® 82801EB (ICH5), 82801ER (ICH5R), and 82801DB (ICH4)
Enhanced Host Controller Interface (EHCI) Programmer?s Reference
Manual (PRM) http://www.intel.com/design/chipsets/manuals/298656.htm
there are a bunch of steps that the bios is responsible to set this
device up. i82801xx_usb_ehci.c is not doing all of these steps. Is
anyone else using the i82801xx code having any problems with high
speed USB 2.0 devices???
Thanks - Joe
