March 2008 - coreboot - mail.coreboot.org

[PATCH][RFC] LAR segfault when adding to a full archive
by Carl-Daniel Hailfinger March 29, 2008

March 29, 2008

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; }

3 5

Re: [coreboot] Out of heap space
by joe＠smittys.pointclark.net March 29, 2008

March 29, 2008

> Can you svn up and try again? > After r45, it just hangs after attempting to free non-allocated memory (see below). Help? Could this have something to do with USB 2.0? Booting 'uda:/isolinux/vmlinuz console=tty0 console=ttyS0,115200n8 initrd=uda:/ isolinux/initrd.img text' malloc_diag: alloc: 312 bytes (4 blocks), free: 32448 bytes (1 blocks) malloc_diag: alloc: 328 bytes (5 blocks), free: 32432 bytes (1 blocks) file_open: dev=uda, path=/isolinux/vmlinuz LinuxLabs USB bootloader uhc_init: Found UHCI at 28c0 uhc_reset: Resetting UHCI uhc_init: uhc_init setting framelist to: 076b9000 uhc_start: Starting UHCI dump_uhci: HCI at 000028c0 uhc_init: Found UHCI at 28e0 uhc_reset: Resetting UHCI uhc_init: uhc_init setting framelist to: 076b9000 uhc_start: Starting UHCI dump_uhci: HCI at 000028e0 uhc_init: Found UHCI at 2c00 uhc_reset: Resetting UHCI uhc_init: uhc_init setting framelist to: 076b9000 uhc_start: Starting UHCI dump_uhci: HCI at 00002c00 malloc_diag: alloc: 8536 bytes (6 blocks), free: 24224 bytes (1 blocks) init_framelist: frame_list is at 13b000 dump_link: frame_list_link: addr: 0012ec70 dump_link: frame_list_link: raw addr: 77e7c70 dump_link: frame_list_link: terminate: 0 dump_link: frame_list_link: queue: 1 dump_link: frame_list_link: depth: 0 malloc_diag: alloc: 16744 bytes (7 blocks), free: 16016 bytes (1 blocks) init_framelist: frame_list is at 13d000 dump_link: frame_list_link: addr: 0012ec90 dump_link: frame_list_link: raw addr: 77e7c90 dump_link: frame_list_link: terminate: 0 dump_link: frame_list_link: queue: 1 dump_link: frame_list_link: depth: 0 malloc_diag: alloc: 24952 bytes (8 blocks), free: 7808 bytes (1 blocks) init_framelist: frame_list is at 13f000 dump_link: frame_list_link: addr: 0012ecb0 dump_link: frame_list_link: raw addr: 77e7cb0 dump_link: frame_list_link: terminate: 0 dump_link: frame_list_link: queue: 1 dump_link: frame_list_link: depth: 0 malloc_diag: alloc: 26536 bytes (9 blocks), free: 6224 bytes (1 blocks) poll_usb: poll_usb1 i=0 poll_u_root_hub1 v=00001080 poll_u_root_hub1 v=00001083 poll_u_root_hub2 v=00001083 poll_u_root_hub21 v=00001083 Connection on port 28d2 New USB device, setting address 2 uhci_control_msg: uhci_control_msg: request_type = 0 request = 5 wLength=0 malloc_diag: alloc: 30648 bytes (10 blocks), free: 2112 bytes (1 blocks) dump_uhci: HCI at 000028c0 dump_td: failed_transaction: TD(0012fcc0): dump_td: failed_transaction: type: SETUP dump_td: failed_transaction: retries: 3 dump_td: failed_transaction: IOC dump_td: failed_transaction: active: 0001 dump_td: failed_transaction: device_addr: 00 dump_td: failed_transaction: endpoint: 0 dump_td: failed_transaction: data_toggle: 0 dump_td: failed_transaction: max_transfer: 7 dump_td: failed_transaction: actual: 0 dump_td: failed_transaction: link: dump_link: failed_transaction: addr: 0012fce0 dump_link: failed_transaction: raw addr: 77e8ce0 dump_link: failed_transaction: terminate: 0 dump_link: failed_transaction: queue: 0 dump_link: failed_transaction: depth: 0 dump_td: failed_transaction: TD(0012fce0): dump_td: failed_transaction: type: IN dump_td: failed_transaction: retries: 0 dump_td: failed_transaction: active: 0001 dump_td: failed_transaction: device_addr: 00 dump_td: failed_transaction: endpoint: 0 dump_td: failed_transaction: data_toggle: 1 dump_td: failed_transaction: max_transfer: 7ff dump_td: failed_transaction: actual: 0 dump_td: failed_transaction: link: dump_link: failed_transaction: addr: f8947000 dump_link: failed_transaction: raw addr: 0000 dump_link: failed_transaction: terminate: 1 dump_link: failed_transaction: queue: 0 dump_link: failed_transaction: depth: 0 Attempt to free non-allocated memory: 001417fc Thanks - Joe

2 4

[LinuxBIOS] Televideo TC7020 successfully booted with LinuxBiosV2
by Knechel, Andrew March 28, 2008

March 28, 2008

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

1 0

Out of heap space
by joe＠smittys.pointclark.net March 28, 2008

March 28, 2008

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

5 9

r45 - in trunk/filo-0.5: drivers/usb fs i386 main
by svn＠coreboot.org March 28, 2008

March 28, 2008

Author: stepan Date: 2008-03-28 15:25:16 +0100 (Fri, 28 Mar 2008) New Revision: 45 Modified: trunk/filo-0.5/drivers/usb/scsi_cmds.c trunk/filo-0.5/drivers/usb/scsi_cmds.h trunk/filo-0.5/drivers/usb/usb.c trunk/filo-0.5/drivers/usb/usb_scsi_low.c trunk/filo-0.5/drivers/usb/usb_scsi_low.h trunk/filo-0.5/fs/fsys_iso9660.c trunk/filo-0.5/fs/iso9660.h trunk/filo-0.5/i386/ldscript trunk/filo-0.5/i386/segment.c trunk/filo-0.5/main/malloc.c Log: Some fixes for USB. Thanks to Fridel Fainshtain for the malloc/alignment hints. Modified: trunk/filo-0.5/drivers/usb/scsi_cmds.c =================================================================== --- trunk/filo-0.5/drivers/usb/scsi_cmds.c 2008-03-13 02:25:53 UTC (rev 44) +++ trunk/filo-0.5/drivers/usb/scsi_cmds.c 2008-03-28 14:25:16 UTC (rev 45) @@ -228,11 +228,11 @@ uchar control; } __attribute__ ((packed)) ReadBlockCMD_t ; -int ll_read_block(devhandle sgd, char *buffer, int blocknum, int count) +int ll_read_block(devhandle sgd, unsigned char *buffer, int blocknum, int count) { int ret; ReadBlockCMD_t rb; - char sensedat[32]; + unsigned char sensedat[32]; memset(&rb,0,sizeof(rb)); rb.cmd = READ_10; @@ -250,11 +250,11 @@ } -int ll_write_block(devhandle sgd, char *buffer, int blocknum, int count) +int ll_write_block(devhandle sgd, unsigned char *buffer, int blocknum, int count) { int ret; ReadBlockCMD_t rb; - char sensedat[32]; + unsigned char sensedat[32]; memset(&rb,0,sizeof(rb)); rb.cmd = WRITE_10; @@ -281,11 +281,11 @@ uchar control; } __attribute__ ((packed)) ReadLongCMD_t ; -int ll_read_long(devhandle sgd, char *buffer, int blocknum, int size) +int ll_read_long(devhandle sgd, unsigned char *buffer, int blocknum, int size) { int ret; ReadLongCMD_t rb; - char sensedat[32]; + unsigned char sensedat[32]; memset(&rb,0,sizeof(rb)); rb.cmd = READ_LONG; @@ -307,7 +307,7 @@ { int ret; struct ReadCapacityResponse response; - char sensedat[32]; + unsigned char sensedat[32]; ret = scsi_command(sgd, ReadCapacityCMD, sizeof(ReadCapacityCMD), SG_DXFER_FROM_DEV, (uint8_t *)&response, sizeof(response), sensedat, sizeof(sensedat) ); if(ret<0) { @@ -328,7 +328,7 @@ int query(devhandle sgd, query_response_t *qr) { int ret; - char sensedat[32]; + unsigned char sensedat[32]; ret = scsi_command(sgd, InquiryCMD, sizeof(InquiryCMD), SG_DXFER_FROM_DEV, (uint8_t *)qr, sizeof(query_response_t), sensedat, sizeof(sensedat) ); @@ -351,7 +351,7 @@ int ReportLUNS(devhandle sgd, lun_list_t *list) { int ret; - char sensedat[32]; + unsigned char sensedat[32]; memset (list, 0, sizeof(lun_list_t)); ret = scsi_command(sgd, ReportLunsCMD, sizeof(ReportLunsCMD), SG_DXFER_FROM_DEV, (uint8_t *)list, sizeof(lun_list_t), sensedat, sizeof(sensedat) ); @@ -399,7 +399,7 @@ int ReportOpCodes(devhandle sgd, report_opcode_result_t *list) { int ret; - char sensedat[32]; + unsigned char sensedat[32]; ReportOpcodesCMD_t ReportOpcodesCMD; memset (list, 0, sizeof(report_opcode_result_t)); Modified: trunk/filo-0.5/drivers/usb/scsi_cmds.h =================================================================== --- trunk/filo-0.5/drivers/usb/scsi_cmds.h 2008-03-13 02:25:53 UTC (rev 44) +++ trunk/filo-0.5/drivers/usb/scsi_cmds.h 2008-03-28 14:25:16 UTC (rev 45) @@ -7,7 +7,7 @@ #define ushort uint16_t void PrintSense(uchar *sense, int len); -int ll_read_block(devhandle sgd, char *buffer, int blocknum, int count); +int ll_read_block(devhandle sgd, unsigned char *buffer, int blocknum, int count); int get_capacity(devhandle sgd, unsigned long *block_count, unsigned int *blk_len); int UnitReady(uchar sgd); Modified: trunk/filo-0.5/drivers/usb/usb.c =================================================================== --- trunk/filo-0.5/drivers/usb/usb.c 2008-03-13 02:25:53 UTC (rev 44) +++ trunk/filo-0.5/drivers/usb/usb.c 2008-03-28 14:25:16 UTC (rev 45) @@ -155,7 +155,7 @@ ushort lang; if(!string) { - strcpy(buffer, "unknown"); + strcpy((char *)buffer, "unknown"); return(0); } @@ -191,7 +191,7 @@ real_len = len; if(real_len<=4) { - strcpy(buffer, "USB"); + strcpy((char *)buffer, "USB"); real_len = 3; buffer[real_len] = 0; } else { Modified: trunk/filo-0.5/drivers/usb/usb_scsi_low.c =================================================================== --- trunk/filo-0.5/drivers/usb/usb_scsi_low.c 2008-03-13 02:25:53 UTC (rev 44) +++ trunk/filo-0.5/drivers/usb/usb_scsi_low.c 2008-03-28 14:25:16 UTC (rev 45) @@ -70,7 +70,7 @@ } __attribute__ ((packed)) usb_csw_t; -int scsi_command( uchar device, unsigned char *cmd, int cmd_len, int direction, unsigned char *data, int data_len, char *sense_data, int sense_len) +int scsi_command( uchar device, unsigned char *cmd, int cmd_len, int direction, unsigned char *data, int data_len, unsigned char *sense_data, int sense_len) { usb_cbw_t cbw; usb_csw_t csw; @@ -131,7 +131,7 @@ return(data_len - csw.residue); } -int request_sense( uchar device, char *sense_data, int len) +int request_sense( uchar device, unsigned char *sense_data, int len) { usb_cbw_t cbw; usb_csw_t csw; Modified: trunk/filo-0.5/drivers/usb/usb_scsi_low.h =================================================================== --- trunk/filo-0.5/drivers/usb/usb_scsi_low.h 2008-03-13 02:25:53 UTC (rev 44) +++ trunk/filo-0.5/drivers/usb/usb_scsi_low.h 2008-03-28 14:25:16 UTC (rev 45) @@ -4,7 +4,7 @@ #define SG_DXFER_FROM_DEV -3 #define SG_DXFER_TO_DEV -2 -int scsi_command( unsigned char device, unsigned char *cmd, int cmd_len, int direction, unsigned char *data, int data_len, char *sense_data, int sense_len); -int request_sense( unsigned char device, char *sense_data, int len); +int scsi_command( unsigned char device, unsigned char *cmd, int cmd_len, int direction, unsigned char *data, int data_len, unsigned char *sense_data, int sense_len); +int request_sense( unsigned char device, unsigned char *sense_data, int len); #endif Modified: trunk/filo-0.5/fs/fsys_iso9660.c =================================================================== --- trunk/filo-0.5/fs/fsys_iso9660.c 2008-03-13 02:25:53 UTC (rev 44) +++ trunk/filo-0.5/fs/fsys_iso9660.c 2008-03-28 14:25:16 UTC (rev 45) @@ -151,7 +151,7 @@ for (; idr->length.l > 0; idr = (struct iso_directory_record *)((char *)idr + idr->length.l) ) { - const char *name = idr->name; + const unsigned char *name = idr->name; unsigned int name_len = idr->name_len.l; file_type = (idr->flags.l & 2) ? ISO_DIRECTORY : ISO_REGULAR; @@ -236,7 +236,7 @@ } rr_ptr.ptr = RRCONT_BUF + ce_ptr->u.ce.offset.l; rr_len = ce_ptr->u.ce.size.l; - if (!iso9660_devread(ce_ptr->u.ce.extent.l, 0, ISO_SECTOR_SIZE, RRCONT_BUF)) + if (!iso9660_devread(ce_ptr->u.ce.extent.l, 0, ISO_SECTOR_SIZE, (char *)RRCONT_BUF)) { errnum = 0; /* this is not fatal. */ break; Modified: trunk/filo-0.5/fs/iso9660.h =================================================================== --- trunk/filo-0.5/fs/iso9660.h 2008-03-13 02:25:53 UTC (rev 44) +++ trunk/filo-0.5/fs/iso9660.h 2008-03-28 14:25:16 UTC (rev 45) @@ -152,7 +152,7 @@ typedef union RR_ptr { struct rock_ridge *rr; - char *ptr; + unsigned char *ptr; int i; } RR_ptr_t; Modified: trunk/filo-0.5/i386/ldscript =================================================================== --- trunk/filo-0.5/i386/ldscript 2008-03-13 02:25:53 UTC (rev 44) +++ trunk/filo-0.5/i386/ldscript 2008-03-28 14:25:16 UTC (rev 45) @@ -8,8 +8,8 @@ */ BASE_ADDR = 0x100000; -/* 16KB heap and stack */ -HEAP_SIZE = 16384; +/* 32KB heap and 16k stack */ +HEAP_SIZE = 32768; STACK_SIZE = 16384; SECTIONS Modified: trunk/filo-0.5/i386/segment.c =================================================================== --- trunk/filo-0.5/i386/segment.c 2008-03-13 02:25:53 UTC (rev 44) +++ trunk/filo-0.5/i386/segment.c 2008-03-28 14:25:16 UTC (rev 45) @@ -48,7 +48,7 @@ unsigned long new_offset; unsigned d0, d1, d2; struct gdtarg gdtarg; -#define ALIGNMENT 16 +#define ALIGNMENT 0x1000 prog_addr = virt_to_phys(&_start); prog_size = virt_to_phys(&_end) - virt_to_phys(&_start); Modified: trunk/filo-0.5/main/malloc.c =================================================================== --- trunk/filo-0.5/main/malloc.c 2008-03-13 02:25:53 UTC (rev 44) +++ trunk/filo-0.5/main/malloc.c 2008-03-28 14:25:16 UTC (rev 45) @@ -186,20 +186,24 @@ // very dumb allot2 implementation to get -// usb stack working quickly. This should be -// redone later.. -// -// note: this will fail if alignment is smaller than sizeof(unsigned long) +// usb stack working quickly. + void *allot2(size_t size, unsigned int alignment) { void *addr; unsigned long addrval; - addr=malloc(2*size); + if(((alignment + 1) & alignment) != 0) { + debug("alignment not power of 2"); + return (void *)0; + } + + addr=malloc(size + alignment + sizeof(unsigned long)); + addrval=(unsigned long)addr; addrval+=alignment+1; // 0x12345600 + 0xff + 1 addrval&=~alignment; // 0x12345700 - *(void * *)(addrval-sizeof(unsigned long))=addr; + *(unsigned long *)(addrval-sizeof(unsigned long))=addr; return (void *)addrval; } @@ -208,11 +212,9 @@ unsigned long addr=(unsigned long)mem; addr-=sizeof(unsigned long); - free((void *)(*(unsigned long *)addr)); + free((void *)addr); } -// end of ugly code. - void malloc_diag(void) { debug("alloc: %lu bytes (%u blocks), free: %lu bytes (%u blocks)\n",

1 0

Re: [coreboot] Code flow from reset vector
by Viswesh S March 28, 2008

March 28, 2008

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

1 0

Re: [coreboot] MIPS Yamon replacement?
by Carl-Daniel Hailfinger March 28, 2008

March 28, 2008

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

3 4

[LinuxBIOS] [RFC][PATCH] v3: lar header after member support
by Carl-Daniel Hailfinger March 28, 2008

March 28, 2008

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

2 3

MIPS Yamon replacement?
by Jake Peavy March 28, 2008

March 28, 2008

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

6 10

ICH Series i82801xx EHCI (USB 2.0) problems
by joe＠smittys.pointclark.net March 28, 2008

March 28, 2008

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

4 16