coreboot June 2009

coreboot@coreboot.org

84 participants
500 discussions

Re: [coreboot] coreboot for VX800+Nano
by Harrison, Jon (SELEX GALILEO, UK) 23 Jun '09

23 Jun '09

Konstantin, I note that you have experience of the CN400. I am currently trying to develop C3/CN400 support (Actually Luke CoreFusion) support, but I am having diffculty with the early RAM init. I've been looking at the VX800 code for comparison. Other than the fact that the VX800 code is mostly written for DDR2 can you tell me if the general ram init sequence for the CN400 should be the same. From the bits that are being tweaked in the Vx800 code, it looks like the CN400 DLL/NB reset sequence should be similar after setting the DRAM frequency. I'd appreciate any help you could offer in outlining any key sequence steps in the RAM init for the CN400. Thanks, Jon -----Original Message----- Konsstantin Lazarev wrote: > Hello, > > I am interested to participate in development of coreboot support for > VIA VX8xx+Nano. I have experience in adaptation of LinuxBIOS for GeodeLX > platforms in a past. And I have experience in low-level programming and > vendor BIOSes (GS, Phoenix) adaptation for other VIA chipsets (CN400, > VT8237, CX700, C3, C7). Now I am working on bringing up VX800+Nano > based platform (hardware is available) and very interested in moving it > to open-source BIOS instead of vendor one. And any existing coreboot > source code for VIA VX8xx would be very helpful. I will be glad to > contribute my work to open-source BIOS project. I (my employer) have NDA > signed with VIA. > > Thank you, > Konstantin Lazarev. > SELEX Sensors and Airborne Systems Limited Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ********************************************************************

1 0

Re: [coreboot] When I run... # ./qemu -L ~ -hda /root/Project/Kantor/Thin_client/qemu-0.10.5/disk.img -nographic
by Rick Ant 23 Jun '09

23 Jun '09

I got this message : ================= boot: hda:/boot/vmlinuz root=/dev/hda initrd=/boot/initrd console=ttyS0 hda: LBA48 524MB: QEMU HARDDISK Mounted ext2fs Found Linux version 2.6.16.5 (root@e-smith) #2 PREEMPT Sat Sep 22 00:14:46 Local time zone must be set--see bzImage. Loading kernel... ok Loading initrd... ok Jumping to entry point... ============== Is the coreboot working fine ? or not yet ? Can I write it to Compact flash for real boot ? How ? Thanks --- On Tue, 6/23/09, ron minnich <rminnich(a)gmail.com> wrote: From: ron minnich <rminnich(a)gmail.com> Subject: Re: [coreboot] When I run... # ./qemu -L ~ -hda /root/Project/Kantor/Thin_client/qemu-0.10.5/disk.img -nographic To: "Rick Ant" <rick_077(a)yahoo.com> Cc: "Warren Turkal" <wt(a)penguintechs.org>, coreboot(a)coreboot.org Date: Tuesday, June 23, 2009, 12:02 AM yes, the hda is usually not partitioned. What I do to boot, e.g., hda-linux.img or whatever root (hd0) kernel /vmlinuz root=/dev/hda and then it is fine. ron

1 0

Re: [coreboot] coreboot for intel atom processor
by ron minnich 23 Jun '09

23 Jun '09

On Mon, Jun 22, 2009 at 11:13 PM, Anurag_Vashisth<Anurag_Vashisth(a)satyam.com> wrote: > Hi All, > > I've decided to use the coreboot to boot my development board SBC (single board computer) which is required to boot Linux(ubuntu 8.10) as its payload. > > My hardware configuration is: > 1) INTEL ATOM CPU Z510P > 2) INTEL SCH US15WP chipset I recommend v2. > > But i am confused about: > 1) which coreboot version (v2 or v3) should i use? > 2) which mainboard to start with? Stefan can tell us. > DISCLAIMER: > This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. Can you please get rid of this disclaimer? It really makes no sense to send this kind of disclaimer to a mailing list. thanks ron

1 0

Re: [coreboot] When I run... # ./qemu -L ~ -hda /root/Project/Kantor/Thin_client/qemu-0.10.5/disk.img -nographic
by Rick Ant 23 Jun '09

23 Jun '09

Hello, Please provide more info. Given the missing info, it seem like the following 1) What payload are you using? I'm using FILO And creating 500Mb image =================== Create an empty disk image: $ qemu-img create -f raw disk.img 500M Format it: $ mkfs.ext2 -F disk.img ==================== 2) What did you do to initialize the image after creating the image? Did you install a Linux distro in the the image? ===== I don't understand with this question ?? I have done... Create a boot directory and copy your Linux kernel (vmlinuz) and initramfs (initrd) to it: # mkdir /mnt/rootfs/boot # cp vmlinuz /mnt/rootfs/boot/vmlinuz # cp initrd /mnt/rootfs/boot/initrd ========================= Which vmlinuz and initrd should I use ?? Confuse.. Please provide any other info you think might be relevant. Should I compile a new kernel or what should I do next after boot : I include the message I got when running qemu... ======================= telebit:~/Project/Kantor/Thin_client/qemu-0.10.5/i386-softmmu # ./qemu -L ~ -hda /root/Project/Kantor/Thin_client/qemu-0.10.5/disk.img -nographic Could not open '/dev/kqemu' - QEMU acceleration layer not activated: No such file or directory coreboot-2.0.0-r-GRUB2 Mon Jun 22 05:02:00 WIT 2009 starting... Uncompressing coreboot to RAM. Jumping to image. Check CBFS header at fffeffd0 magic is 4f524243 Found CBFS header at fffeffd0 Check normal/payload CBFS: follow chain: ffe00000 + 28 + 9626 + align -> ffe09650 Check normal/coreboot_ram Stage: load @ 16384/81920 bytes, enter @ 4000 Stage: done loading. Jumping to image. coreboot-2.0.0-r-GRUB2 Mon Jun 22 05:02:00 WIT 2009 booting... Enumerating buses... Show all devs...Before Phase 3. Root Device: enabled 1, 0 resources PCI_DOMAIN: 0000: enabled 1, 0 resources PCI: 00:00.0: enabled 1, 0 resources PCI: 00:01.0: enabled 1, 0 resources PCI: 00:01.1: enabled 1, 0 resources Compare with tree... Root Device: enabled 1, 0 resources PCI_DOMAIN: 0000: enabled 1, 0 resources PCI: 00:00.0: enabled 1, 0 resources PCI: 00:01.0: enabled 1, 0 resources PCI: 00:01.1: enabled 1, 0 resources scan_static_bus for Root Device Finding PCI configuration type. PCI: Using configuration type 1 PCI_DOMAIN: 0000 enabled PCI_DOMAIN: 0000 scanning... PCI: pci_scan_bus for bus 00 PCI: 00:00.0 [8086/1237] enabled PCI: 00:01.0 [8086/7000] bus ops PCI: 00:01.0 [8086/7000] enabled PCI: 00:01.1 [8086/7010] ops PCI: 00:01.1 [8086/7010] enabled PCI: 00:01.2, bad id 0xffffffff malloc Enter, size 1100, free_mem_ptr 00014000 malloc 00014000 PCI: 00:01.3 [8086/7113] bus ops PCI: 00:01.3 [8086/7113] enabled PCI: 00:01.4, bad id 0xffffffff PCI: 00:01.5, bad id 0xffffffff PCI: 00:01.6, bad id 0xffffffff PCI: 00:01.7, bad id 0xffffffff malloc Enter, size 1100, free_mem_ptr 0001444c malloc 0001444c PCI: 00:02.0 [1013/00b8] ops PCI: 00:02.0 [1013/00b8] enabled malloc Enter, size 1100, free_mem_ptr 00014898 malloc 00014898 PCI: 00:03.0 [10ec/8029] enabled malloc Enter, size 1100, free_mem_ptr 00014ce4 malloc 00014ce4 PCI: 00:04.0 [1af4/1002] enabled PCI: 00:05.0, bad id 0xffffffff PCI: 00:06.0, bad id 0xffffffff PCI: 00:07.0, bad id 0xffffffff PCI: 00:08.0, bad id 0xffffffff PCI: 00:09.0, bad id 0xffffffff PCI: 00:0a.0, bad id 0xffffffff PCI: 00:0b.0, bad id 0xffffffff PCI: 00:0c.0, bad id 0xffffffff PCI: 00:0d.0, bad id 0xffffffff PCI: 00:0e.0, bad id 0xffffffff PCI: 00:0f.0, bad id 0xffffffff PCI: 00:10.0, bad id 0xffffffff PCI: 00:11.0, bad id 0xffffffff PCI: 00:12.0, bad id 0xffffffff PCI: 00:13.0, bad id 0xffffffff PCI: 00:14.0, bad id 0xffffffff PCI: 00:15.0, bad id 0xffffffff PCI: 00:16.0, bad id 0xffffffff PCI: 00:17.0, bad id 0xffffffff PCI: 00:18.0, bad id 0xffffffff PCI: 00:19.0, bad id 0xffffffff PCI: 00:1a.0, bad id 0xffffffff PCI: 00:1b.0, bad id 0xffffffff PCI: 00:1c.0, bad id 0xffffffff PCI: 00:1d.0, bad id 0xffffffff PCI: 00:1e.0, bad id 0xffffffff PCI: 00:1f.0, bad id 0xffffffff scan_static_bus for PCI: 00:01.0 scan_static_bus for PCI: 00:01.0 done scan_static_bus for PCI: 00:01.3 scan_static_bus for PCI: 00:01.3 done PCI: pci_scan_bus returning with max=000 scan_static_bus for Root Device done done Allocating resources... Show resources in subtree (Root Device)...Original. Root Device links 1 child on link 0 Root Device PCI_DOMAIN: 0000 links 1 child on link 0 PCI_DOMAIN: 0000 PCI: 00:00.0 links 0 child on link 0 NULL PCI: 00:01.0 links 0 child on link 0 NULL PCI: 00:01.1 links 0 child on link 0 NULL PCI: 00:01.3 links 0 child on link 0 NULL PCI: 00:02.0 links 0 child on link 0 NULL PCI: 00:03.0 links 0 child on link 0 NULL PCI: 00:04.0 links 0 child on link 0 NULL Reading resources... Root Device compute_allocate_resource io: base: 00000400 size: 00000000 align: 0 gran: 0 Root Device read_resources bus 0 link: 0 PCI_DOMAIN: 0000 read_resources bus 0 link: 0 PCI_DOMAIN: 0000 read_resources bus 0 link: 0 done Root Device read_resources bus 0 link: 0 done PCI: 00:03.0 10 * [0x00000400 - 0x000004ff] io PCI: 00:04.0 10 * [0x00000800 - 0x0000081f] io PCI: 00:01.1 20 * [0x00000820 - 0x0000082f] io Root Device compute_allocate_resource io: base: 00000830 size: 00000430 align: 8 gran: 0 done Root Device compute_allocate_resource mem: base: 00000000 size: 00000000 align: 0 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:02.0 10 * [0x00000000 - 0x01ffffff] prefmem PCI: 00:02.0 14 * [0x02000000 - 0x02000fff] mem Root Device compute_allocate_resource mem: base: 02001000 size: 02001000 align: 25 gran: 0 done Done reading resources. Show resources in subtree (Root Device)...After reading. Root Device links 1 child on link 0 Root Device Root Device resource base 400 size 430 align 8 gran 0 limit ffff flags 100 index 0 Root Device resource base 0 size 2001000 align 25 gran 0 limit febfffff flags 200 index 1 PCI_DOMAIN: 0000 links 1 child on link 0 PCI_DOMAIN: 0000 PCI_DOMAIN: 0000 resource base 0 size 0 align 0 gran 0 limit ffff flags 40040100 index 10000000 PCI_DOMAIN: 0000 resource base 0 size 0 align 0 gran 0 limit ffffffff flags 40040200 index 10000100 PCI: 00:00.0 links 0 child on link 0 NULL PCI: 00:01.0 links 0 child on link 0 NULL PCI: 00:01.1 links 0 child on link 0 NULL PCI: 00:01.1 resource base 820 size 10 align 4 gran 4 limit ffff flags 40000100 index 20 PCI: 00:01.3 links 0 child on link 0 NULL PCI: 00:02.0 links 0 child on link 0 NULL PCI: 00:02.0 resource base 0 size 2000000 align 25 gran 25 limit ffffffff flags 40001200 index 10 PCI: 00:02.0 resource base 2000000 size 1000 align 12 gran 12 limit ffffffff flags 40000200 index 14 PCI: 00:03.0 links 0 child on link 0 NULL PCI: 00:03.0 resource base 400 size 100 align 8 gran 8 limit ffff flags 40000100 index 10 PCI: 00:04.0 links 0 child on link 0 NULL PCI: 00:04.0 resource base 800 size 20 align 5 gran 5 limit ffff flags 40000100 index 10 Setting resources... Root Device compute_allocate_resource io: base: 00001000 size: 00000430 align: 8 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:03.0 10 * [0x00001000 - 0x000010ff] io PCI: 00:04.0 10 * [0x00001400 - 0x0000141f] io PCI: 00:01.1 20 * [0x00001420 - 0x0000142f] io Root Device compute_allocate_resource io: base: 00001430 size: 00000430 align: 8 gran: 0 done Root Device compute_allocate_resource mem: base: fc000000 size: 02001000 align: 25 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:02.0 10 * [0xfc000000 - 0xfdffffff] prefmem PCI: 00:02.0 14 * [0xfe000000 - 0xfe000fff] mem Root Device compute_allocate_resource mem: base: fe001000 size: 02001000 align: 25 gran: 0 done Root Device assign_resources, bus 0 link: 0 RAM size config registers are empty; defaulting to 64 MBytes I would set ram size to 0x10000 Kbytes PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 PCI: 00:01.1 20 <- [0x0000001420 - 0x000000142f] size 0x00000010 gran 0x04 io PCI: 00:02.0 10 <- [0x00fc000000 - 0x00fdffffff] size 0x02000000 gran 0x19 prefmem PCI: 00:02.0 14 <- [0x00fe000000 - 0x00fe000fff] size 0x00001000 gran 0x0c mem PCI: 00:03.0 10 <- [0x0000001000 - 0x00000010ff] size 0x00000100 gran 0x08 io PCI: 00:04.0 10 <- [0x0000001400 - 0x000000141f] size 0x00000020 gran 0x05 io PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 Root Device assign_resources, bus 0 link: 0 Done setting resources. Show resources in subtree (Root Device)...After assigning values. Root Device links 1 child on link 0 Root Device Root Device resource base 1000 size 430 align 8 gran 0 limit ffff flags 40000100 index 0 Root Device resource base fc000000 size 2001000 align 25 gran 0 limit febfffff flags 40000200 index 1 PCI_DOMAIN: 0000 links 1 child on link 0 PCI_DOMAIN: 0000 PCI_DOMAIN: 0000 resource base 0 size 0 align 0 gran 0 limit ffff flags 40040100 index 10000000 PCI_DOMAIN: 0000 resource base 0 size 0 align 0 gran 0 limit ffffffff flags 40040200 index 10000100 PCI_DOMAIN: 0000 resource base 0 size a0000 align 0 gran 0 limit 0 flags e0004200 index a PCI_DOMAIN: 0000 resource base c0000 size 3f40000 align 0 gran 0 limit 0 flags e0004200 index b PCI: 00:00.0 links 0 child on link 0 NULL PCI: 00:01.0 links 0 child on link 0 NULL PCI: 00:01.1 links 0 child on link 0 NULL PCI: 00:01.1 resource base 1420 size 10 align 4 gran 4 limit ffff flags 60000100 index 20 PCI: 00:01.3 links 0 child on link 0 NULL PCI: 00:02.0 links 0 child on link 0 NULL PCI: 00:02.0 resource base fc000000 size 2000000 align 25 gran 25 limit ffffffff flags 60001200 index 10 PCI: 00:02.0 resource base fe000000 size 1000 align 12 gran 12 limit ffffffff flags 60000200 index 14 PCI: 00:03.0 links 0 child on link 0 NULL PCI: 00:03.0 resource base 1000 size 100 align 8 gran 8 limit ffff flags 60000100 index 10 PCI: 00:04.0 links 0 child on link 0 NULL PCI: 00:04.0 resource base 1400 size 20 align 5 gran 5 limit ffff flags 60000100 index 10 Done allocating resources. Enabling resources... PCI: 00:00.0 subsystem <- 00/00 PCI: 00:00.0 cmd <- 00 PCI: 00:01.0 cmd <- 07 PCI: 00:01.1 cmd <- 01 PCI: 00:01.3 cmd <- 00 PCI: 00:02.0 cmd <- 03 PCI: 00:03.0 cmd <- 01 PCI: 00:04.0 cmd <- 01 done. Initializing devices... Root Device init PCI: 00:00.0 init Check CBFS header at fffeffd0 magic is 4f524243 Found CBFS header at fffeffd0 Check normal/payload CBFS: follow chain: ffe00000 + 28 + 9626 + align -> ffe09650 Check normal/coreboot_ram CBFS: follow chain: ffe09650 + 38 + 6135 + align -> ffe0f7c0 Check CBFS: follow chain: ffe0f7c0 + 28 + 1e0808 + align -> fffefff0 CBFS: Could not find file pci8086,1237.rom In cbfs, rom address for PCI: 00:00.0 = 00000000 On mainboard, rom address for PCI: 00:00.0 = 0 PCI: 00:01.0 init RTC Init RTC: Checksum invalid zeroing cmos Invalid CMOS LB checksum PCI: 00:01.1 init IDE: Primary IDE interface: on IDE: Secondary IDE interface: on IDE: Access to legacy IDE ports: off PCI: 00:02.0 init Check CBFS header at fffeffd0 magic is 4f524243 Found CBFS header at fffeffd0 Check normal/payload CBFS: follow chain: ffe00000 + 28 + 9626 + align -> ffe09650 Check normal/coreboot_ram CBFS: follow chain: ffe09650 + 38 + 6135 + align -> ffe0f7c0 Check CBFS: follow chain: ffe0f7c0 + 28 + 1e0808 + align -> fffefff0 CBFS: Could not find file pci1013,00b8.rom In cbfs, rom address for PCI: 00:02.0 = 00000000 On mainboard, rom address for PCI: 00:02.0 = c0000 PCI Expansion ROM, signature 0xaa55, INIT size 0x8000, data ptr 0x736f PCI ROM Image, Vendor ffff, Device 0300, Device or Vendor ID mismatch Vendor ffff, Device 0300 Keyboard init... setting ethernet Assigning IRQ 11 to 0:3.0 Readback = 11 pci_level_irq: current ints are 0x0 pci_level_irq: try to set ints 0x800 PCI: 00:03.0 init Check CBFS header at fffeffd0 magic is 4f524243 Found CBFS header at fffeffd0 Check normal/payload CBFS: follow chain: ffe00000 + 28 + 9626 + align -> ffe09650 Check normal/coreboot_ram CBFS: follow chain: ffe09650 + 38 + 6135 + align -> ffe0f7c0 Check CBFS: follow chain: ffe0f7c0 + 28 + 1e0808 + align -> fffefff0 CBFS: Could not find file pci10ec,8029.rom In cbfs, rom address for PCI: 00:03.0 = 00000000 On card, rom address for PCI: 00:03.0 = 0 PCI: 00:04.0 init Check CBFS header at fffeffd0 magic is 4f524243 Found CBFS header at fffeffd0 Check normal/payload CBFS: follow chain: ffe00000 + 28 + 9626 + align -> ffe09650 Check normal/coreboot_ram CBFS: follow chain: ffe09650 + 38 + 6135 + align -> ffe0f7c0 Check CBFS: follow chain: ffe0f7c0 + 28 + 1e0808 + align -> fffefff0 CBFS: Could not find file pci1af4,1002.rom In cbfs, rom address for PCI: 00:04.0 = 00000000 On card, rom address for PCI: 00:04.0 = 0 Devices initialized Show all devs...After init. Root Device: enabled 1, 2 resources PCI_DOMAIN: 0000: enabled 1, 4 resources PCI: 00:00.0: enabled 1, 0 resources PCI: 00:01.0: enabled 1, 0 resources PCI: 00:01.1: enabled 1, 1 resources PCI: 00:01.3: enabled 1, 0 resources PCI: 00:02.0: enabled 1, 2 resources PCI: 00:03.0: enabled 1, 1 resources PCI: 00:04.0: enabled 1, 1 resources High Tables Base is 3ff0000. Copying Interrupt Routing Table to 0x000f0000... done. Copying Interrupt Routing Table to 0x03ff0000... done. Moving GDT to 0x3ff0400...ok Multiboot Information structure has been written. Writing high table forward entry at 0x00000500 Wrote coreboot table at: 00000500 - 00000518 checksum f3df New low_table_end: 0x00000518 Now going to write high coreboot table at 0x03ff0800 rom_table_end = 0x03ff0800 Adjust low_table_end from 0x00000518 to 0x00001000 Adjust rom_table_end from 0x03ff0800 to 0x04000000 Adding high table area Wrote coreboot table at: 03ff0800 - 03ff0e7c checksum 6720 Check CBFS header at fffeffd0 magic is 4f524243 Found CBFS header at fffeffd0 Check normal/payload Got a payload Segment ffe00028 data: malloc Enter, size 36, free_mem_ptr 00015130 malloc 00015130 New segment dstaddr 0x100000 memsize 0x235e0 srcaddr 0xffe0007c filesize 0x9548 (cleaned up) New segment addr 0x100000 size 0x235e0 offset 0xffe0007c filesize 0x9548 Segment ffe00044 data: malloc Enter, size 36, free_mem_ptr 00015154 malloc 00015154 New segment dstaddr 0x1235e0 memsize 0x48 srcaddr 0xffe095c4 filesize 0x48 (cleaned up) New segment addr 0x1235e0 size 0x48 offset 0xffe095c4 filesize 0x48 Segment ffe00060 Entry 001077c8 Loading Segment: addr: 0x0000000000100000 memsz: 0x00000000000235e0 filesz: 0x0000000000009548 lb: [0x0000000000004000, 0x0000000000018000) Post relocation: addr: 0x0000000000100000 memsz: 0x00000000000235e0 filesz: 0x0000000000009548 it's not compressed! [ 0x0000000000100000, 0000000000109548, 0x00000000001235e0) <- 00000000ffe0007c Clearing Segment: addr: 0x0000000000109548 memsz: 0x000000000001a098 Loading Segment: addr: 0x00000000001235e0 memsz: 0x0000000000000048 filesz: 0x0000000000000048 lb: [0x0000000000004000, 0x0000000000018000) Post relocation: addr: 0x00000000001235e0 memsz: 0x0000000000000048 filesz: 0x0000000000000048 it's not compressed! [ 0x00000000001235e0, 0000000000123628, 0x0000000000123628) <- 00000000ffe095c4 Loaded segments Jumping to boot code at 1077c8 entry = 0x001077c8 lb_start = 0x00004000 lb_size = 0x00014000 adjust = 0x03fc4000 buffer = 0x03fc8000 elf_boot_notes = 0x000109e0 adjusted_boot_notes = 0x03fd49e0 FILO version 0.4.2 (root@telebit) Mon Jun 22 04:20:39 WIT 2009 Can't get memory map from firmware. Using hardcoded default. Press <Enter> for default boot, or <Esc> for boot prompt... timed out boot: hda1:/vmlinuz root=/dev/hda1 console=tty0 console=ttyS0,115200 hda: LBA48 524MB: QEMU HARDDISK =================== --- On Mon, 6/22/09, Warren Turkal <wt(a)penguintechs.org> wrote: From: Warren Turkal <wt(a)penguintechs.org> Subject: Re: [coreboot] When I run... # ./qemu -L ~ -hda /root/Project/Kantor/Thin_client/qemu-0.10.5/disk.img -nographic To: "Rick Ant" <rick_077(a)yahoo.com> Cc: coreboot(a)coreboot.org Date: Monday, June 22, 2009, 10:22 AM Please provide more info. Given the missing info, it seem like the following 1) What payload are you using? 2) What did you do to initialize the image after creating the image? Did you install a Linux distro in the the image? Please provide any other info you think might be relevant. Also, please keep this in one email thread. It'll help people find the info if they go searching for help later. Thanks, wt On Mon, Jun 22, 2009 at 2:11 AM, Rick Ant<rick_077(a)yahoo.com> wrote: > When I run : > # ./qemu -L ~ -hda /root/Project/Kantor/Thin_client/qemu-0.10.5/disk.img > -nographic > > I got : > coreboot-2.0.0-r-GRUB2 Mon Jun 22 05:02:00 WIT 2009 starting... > Uncompressing coreboot to RAM. > Jumping to image. > Check CBFS header at fffeffd0 > magic is 4f524243 > Found CBFS header at fffeffd0 > Check normal/payload > > . > . > . > . > . > and last with : > Unrecognized partitioning scheme > boot: hda1:/vmlinuz root=/dev/hda1 console=tty0 console=ttyS0,115200 > > I can't do : > > cp vmlinuz /mnt/rootfs/boot/vmlinuz > cp initrd /mnt/rootfs/boot/initrd > > why were those happen? > What should i do? > > Thanks > > > > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot >

2 1

coreboot for intel atom processor
by Anurag_Vashisth 23 Jun '09

23 Jun '09

Hi All, I've decided to use the coreboot to boot my development board SBC (single board computer) which is required to boot Linux(ubuntu 8.10) as its payload. My hardware configuration is: 1) INTEL ATOM CPU Z510P 2) INTEL SCH US15WP chipset But i am confused about: 1) which coreboot version (v2 or v3) should i use? 2) which mainboard to start with? please let me know if you need more details. Thanks Anurag Vashisth +919739278384 DISCLAIMER: This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated.

1 0

[flashrom] r623 - trunk
by svn＠coreboot.org 23 Jun '09

23 Jun '09

Author: hailfinger Date: 2009-06-23 02:47:26 +0200 (Tue, 23 Jun 2009) New Revision: 623 Modified: trunk/sb600spi.c Log: SB600 SPI: Kill unused variable. Make a few local functions in sb600spi.c static. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Luc Verhaegen <libv(a)skynet.be> Modified: trunk/sb600spi.c =================================================================== --- trunk/sb600spi.c 2009-06-22 11:14:43 UTC (rev 622) +++ trunk/sb600spi.c 2009-06-23 00:47:26 UTC (rev 623) @@ -25,18 +25,19 @@ #include "flash.h" #include "spi.h" -struct sb600_spi_controller { - unsigned int spi_cntrl0; /* 00h */ - unsigned int restrictedcmd1; /* 04h */ - unsigned int restrictedcmd2; /* 08h */ - unsigned int spi_cntrl1; /* 0ch */ - unsigned int spi_cmdvalue0; /* 10h */ - unsigned int spi_cmdvalue1; /* 14h */ - unsigned int spi_cmdvalue2; /* 18h */ - unsigned int spi_fakeid; /* 1Ch */ -}; +/* This struct is unused, but helps visualize the SB600 SPI BAR layout. + *struct sb600_spi_controller { + * unsigned int spi_cntrl0; / * 00h * / + * unsigned int restrictedcmd1; / * 04h * / + * unsigned int restrictedcmd2; / * 08h * / + * unsigned int spi_cntrl1; / * 0ch * / + * unsigned int spi_cmdvalue0; / * 10h * / + * unsigned int spi_cmdvalue1; / * 14h * / + * unsigned int spi_cmdvalue2; / * 18h * / + * unsigned int spi_fakeid; / * 1Ch * / + *}; + */ -struct sb600_spi_controller *spi_bar = NULL; uint8_t *sb600_spibar; int sb600_spi_read(struct flashchip *flash, uint8_t *buf, int start, int len) @@ -86,7 +87,7 @@ return rc; } -void reset_internal_fifo_pointer(void) +static void reset_internal_fifo_pointer(void) { mmio_writeb(mmio_readb(sb600_spibar + 2) | 0x10, sb600_spibar + 2); @@ -94,7 +95,7 @@ printf("reset\n"); } -void execute_command(void) +static void execute_command(void) { mmio_writeb(mmio_readb(sb600_spibar + 2) | 1, sb600_spibar + 2); @@ -111,8 +112,6 @@ writecnt--; - spi_bar = (struct sb600_spi_controller *) sb600_spibar; - printf_debug("%s, cmd=%x, writecnt=%x, readcnt=%x\n", __func__, cmd, writecnt, readcnt);

1 0

When I run... # ./qemu -L ~ -hda /root/Project/Kantor/Thin_client/qemu-0.10.5/disk.img -nographic
by Rick Ant 22 Jun '09

22 Jun '09

When I run : # ./qemu -L ~ -hda /root/Project/Kantor/Thin_client/qemu-0.10.5/disk.img -nographic I got : coreboot-2.0.0-r-GRUB2 Mon Jun 22 05:02:00 WIT 2009 starting... Uncompressing coreboot to RAM. Jumping to image. Check CBFS header at fffeffd0 magic is 4f524243 Found CBFS header at fffeffd0 Check normal/payload . . . . . and last with : Unrecognized partitioning scheme boot: hda1:/vmlinuz root=/dev/hda1 console=tty0 console=ttyS0,115200 I can't do : cp vmlinuz /mnt/rootfs/boot/vmlinuz cp initrd /mnt/rootfs/boot/initrd why were those happen? What should i do? Thanks

2 1

flashrom: Non-power-of-2 chip sizes, registers and external programmers
by Carl-Daniel Hailfinger 22 Jun '09

22 Jun '09

This mail is about two separate problems with a very similar cause: - Non-power-of-2 chip sizes. - Flash register space. General remark: Addressing chips in x86 mainboards means their address space is top-aligned. However, the same chips in external programmers have bottom-aligned addressing. ------Non-power-of-2 chip sizes-------- Flashrom currently supports a few chips with sizes which are not powers of 2. Most notably, some 3 Mbit (384 kByte) chips. Example addresses in binary for onboard 384 KByte flash: Nothing mapped: 11111111111110000000000000000000 to 11111111111110011111111111111111 Bottom 128 kByte: 11111111111110100000000000000000 to 11111111111110111111111111111111 Middle 128 kByte: 11111111111111000000000000000000 to 11111111111111011111111111111111 Top 128 kByte: 11111111111111100000000000000000 to 11111111111111111111111111111111 If we ignore the leading ones (the chip ignores them as well) and write the lowest significant bits as X, the example addresses can be written like this: Nothing mapped: 00X Bottom 128 kByte: 01X Middle 128 kByte: 10X Top 128 kByte: 11X Flashrom will use address 01X-11X to access the flash chip, giving us a readback result of Bottom,Middle,Top. If we accept the addresses above as canonical, an external programmer with bottom-aligned addressing will use addresses 00X-10X instead, giving us a readback result of Nothing,Bottom,Middle. Notice the Nothing at the start of the readback and the missing Top. There are two ways to fix this: 1. Have all programmers use top-aligned addresses. 2. Force the user to specify alignment manually. Option 1 causes problems for all machines with bottom-aligned flash (PowerPC?, maybe some PCI option ROMs), but is the right thing to do if the chip should be used for x86 BIOS. Option 2 causes problems for x86 BIOS chips in external programmers because manual intervention is necessary. Chips with power-of-two sizes are totally unaffected by the problem above. ------Flash register space-------- Flash chips with register space usually provide access that register space if a specific bit in the address is zero. That bit is almost always bit 22. External programmers currently have bottom-aligned addressing, so the register selection bit is always zero. This can cause reads and writes of chips with separate register space to fail, possibly even confusing the chip until it doesn't respond anymore. Using top-aligned addresses for external programmers would fix the register space issue completely for all chips where register selection bit bein zero means register access. However, it is entirely possible that there are chips where the register selection bit has opposite logic. No such chips seem to be usable on x86 mainboards, so I'm not too worried about this. Regards, Carl-Daniel -- http://www.hailfinger.org/

1 0

[flashrom] r622 - trunk
by svn＠coreboot.org 22 Jun '09

22 Jun '09

Author: hailfinger Date: 2009-06-22 13:14:43 +0200 (Mon, 22 Jun 2009) New Revision: 622 Modified: trunk/flashchips.c Log: Mark MX25L6405 as PROBE supported. Thanks to Michael Stapelberg for the report. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Modified: trunk/flashchips.c =================================================================== --- trunk/flashchips.c 2009-06-22 11:07:44 UTC (rev 621) +++ trunk/flashchips.c 2009-06-22 11:14:43 UTC (rev 622) @@ -1361,7 +1361,7 @@ .model_id = MX_25L6405, .total_size = 8192, .page_size = 256, - .tested = TEST_UNTESTED, + .tested = TEST_OK_PROBE, .probe = probe_spi_rdid, .probe_timing = TIMING_ZERO, .erase = spi_chip_erase_60_c7,

1 0

[flashrom] r621 - trunk
by svn＠coreboot.org 22 Jun '09

22 Jun '09

Author: hailfinger Date: 2009-06-22 13:07:44 +0200 (Mon, 22 Jun 2009) New Revision: 621 Modified: trunk/flashchips.c Log: Mark the SST49LF003A as PROBE supported. Thanks to Simon Brown for the report. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Modified: trunk/flashchips.c =================================================================== --- trunk/flashchips.c 2009-06-22 10:09:07 UTC (rev 620) +++ trunk/flashchips.c 2009-06-22 11:07:44 UTC (rev 621) @@ -2049,7 +2049,7 @@ .model_id = SST_49LF003A, .total_size = 384, .page_size = 64 * 1024, - .tested = TEST_UNTESTED, + .tested = TEST_OK_PROBE, .probe = probe_sst_fwhub, .probe_timing = TIMING_FIXME, /* routine is wrapper to probe_jedec (sst_fwhub.c) */ .erase = erase_sst_fwhub,

1 0

← Newer
1
...
15
16
17
18
19
20
21
...
50
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot June 2009