coreboot March 2008

coreboot@coreboot.org

75 participants
382 discussions

Re: [coreboot] coreboot Digest, Vol 37, Issue 175
by Wang, Qingpei 27 Mar '08

27 Mar '08

Hi, Is there any patch or method for using USB to boot linux? Jason Wang Intern Electronic Engineering Lab Peking University Beijing Technology Development Center Advanced Micro Devices(AMD) E-mail: Qingpei.Wang(a)amd.com wangqingpei(a)hotmail.com Phone:13426369984 -----Original Message----- From: coreboot-bounces(a)coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of coreboot-request(a)coreboot.org Sent: Thursday, March 27, 2008 8:20 AM To: coreboot(a)coreboot.org Subject: coreboot Digest, Vol 37, Issue 175 Send coreboot mailing list submissions to coreboot(a)coreboot.org To subscribe or unsubscribe via the World Wide Web, visit http://www.coreboot.org/mailman/listinfo/coreboot or, via email, send a message with subject or body 'help' to coreboot-request(a)coreboot.org You can reach the person managing the list at coreboot-owner(a)coreboot.org When replying, please edit your Subject line so it is more specific than "Re: Contents of coreboot digest..." Today's Topics: 1. Re: ICH Series i82801xx EHCI (USB 2.0) problems (Uwe Hermann) 2. Re: filo booting cd problem (Russell Whitaker) 3. Re: filo booting cd problem (joe(a)smittys.pointclark.net) 4. Re: ICH Series i82801xx EHCI (USB 2.0) problems (joe(a)smittys.pointclark.net) 5. Re: ICH Series i82801xx EHCI (USB 2.0) problems (joe(a)smittys.pointclark.net) 6. MIPS Yamon replacement? (Jake Peavy) 7. Re: MIPS Yamon replacement? (Peter Stuge) 8. Re: [RFC] First K8 board to port to v3 (Rudolf Marek) ---------------------------------------------------------------------- Message: 1 Date: Wed, 26 Mar 2008 18:57:51 +0100 From: Uwe Hermann <uwe(a)hermann-uwe.de> Subject: Re: [coreboot] ICH Series i82801xx EHCI (USB 2.0) problems To: coreboot(a)coreboot.org Message-ID: <20080326175751.GE26901@greenwood> Content-Type: text/plain; charset=us-ascii On Tue, Mar 25, 2008 at 10:12:29PM -0400, joe(a)smittys.pointclark.net wrote: >> On Tue, Mar 25, 2008 at 06:51:24PM -0400, joe(a)smittys.pointclark.net wrote: >>> 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 >> >> Flash drive? You mean mounting a USB thumb drive? That should work fine, >> I tested that on various coreboot boards. Or do you mean an external >> IDE/SATA drive which is connected via USB to the computer? I think >> both should work fine. >> > Yes neithor of these are working. I have tried USB thumb drives, and a > IDE-to-USB 2.0 adapter with hard drive and DVD-rom drive. Hm, that's strange, because the thumb drive should work even with USB 1.1 only (it sure does on my boards). Which ports did you try to use? AFAIUI only one or two of them will be USB 2.0, the other ones have USB 1.1 speed only, no matter which settings the BIOS uses. If you can, please test some other high-speed USB device (not thumb drives or disks). >> Note that AFAICT the USB ports _should_ be intialized ok with coreboot >> if the board code is ok, but they might only act as "full speed" >> (USB 1.1) devices. >> > Nope USB 2.0 devices (drives) are not detected at bootup, or by hot > plugging in Linux. USB 1.1 Keyboards, and mice, work fine. Hm, the kernel init _seems_ to look ok to me, but maybe I'm missing something. Loading ehci-hcd.ko module PCI: Found IRQ 7 for device 0000:00:1d.7 ehci_hcd 0000:00:1d.7: EHCI Host Controller ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 4 ehci_hcd 0000:00:1d.7: debug port 1 ehci_hcd 0000:00:1d.7: irq 7, io mem 0xf8180000 ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 usb usb4: configuration #1 chosen from 1 choice hub 4-0:1.0: USB hub found hub 4-0:1.0: 6 ports detected Is the IRQ routing correct? If you attach and use USB devices on those ports, do the numbers in /proc/interrrupts increase? > Not that I am aware, EHCI seems to setup ok in coreboot, except the > devices are not detected by coreboot, filo, or Linux. >> >> What exactly does _not_ work btw? > When Linux is running and I plug in a USB flash drive, the led on the > drive comes on for a few seconds and then turns off, and Linux does not > detect the drive. I have tried several different brands. They work fine > with the original bios. With or without a USB hub? If hub, is it a self-powered hub? Does the drive get enough power? Hm, not sure what's going on, maybe someone else can comment? It's possible that you indeed have to do the init mentioned in the datasheet. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org ------------------------------ Message: 2 Date: Wed, 26 Mar 2008 12:03:30 -0700 (PDT) From: Russell Whitaker <russ(a)ashlandhome.net> Subject: Re: [coreboot] filo booting cd problem To: Phani Babu Giddi <phanig(a)gmail.com> Cc: coreboot(a)coreboot.org Message-ID: <Pine.LNX.4.64.0803261149170.4968(a)bigred.russwhit.org> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Wed, 26 Mar 2008, Phani Babu Giddi wrote: > Yes I am using FILO with USE_GRUB=1 but while FILO is starting I press the > 'Esc' key and later I key in the kernel and initrd parameters. > > The absolute path is /boot/i386/loader/linux for the kernel image and > /boot/i386/loader/initrd for the initrd. Ofcourse I would have to add "hdb:" > to the path. > > -Phani > > On Wed, Mar 26, 2008 at 10:12 AM, <joe(a)smittys.pointclark.net> wrote: > >> Quoting Phani Babu Giddi <phanig(a)gmail.com>: >> >>> # install >>> label linux >>> kernel linux >>> append initrd=initrd splash=silent showopts >> On my main box I'm using factory bios + grub. The kernel image is vmlinuz and is in the /boot directory. Since I don't need to append any parameters, ny menu.lst looks like: #grub configuration file #by default, boot first entry default 0 timeout 6 #first entry: title slack.12 kernel (hd0,0)/boot/vmlinuz root=/dev/hda1 #second entry: [...] #fifth entry title memtest86 kernel (hd0,0)/boot/memtest.bin Note the full path to the kernel. Hope this helps, Russ ------------------------------ Message: 3 Date: Wed, 26 Mar 2008 15:30:06 -0400 From: joe(a)smittys.pointclark.net Subject: Re: [coreboot] filo booting cd problem To: Phani Babu Giddi <phanig(a)gmail.com> Cc: coreboot(a)coreboot.org Message-ID: <20080326153006.ecdzlfy6zoo00g4w(a)www.smittys.pointclark.net> Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Quoting Phani Babu Giddi <phanig(a)gmail.com>: > Yes I am using FILO with USE_GRUB=1 but while FILO is starting I press the > 'Esc' key and later I key in the kernel and initrd parameters. > > The absolute path is /boot/i386/loader/linux for the kernel image and > /boot/i386/loader/initrd for the initrd. Ofcourse I would have to add "hdb:" > to the path. > > -Phani > > On Wed, Mar 26, 2008 at 10:12 AM, <joe(a)smittys.pointclark.net> wrote: > >> Quoting Phani Babu Giddi <phanig(a)gmail.com>: >> >> > # install >> > label linux >> > kernel linux >> > append initrd=initrd splash=silent showopts >> Ok then. So if it brings you to the filo shell (boot:) you probibly want this: boot: hdb:/boot/i386/loader/linux initrd=/boot/i386/loader/initrd splash=silent showopts console=ttyS0,115200n8 If it brings you to the grub/filo shell (grub>) then you would probibly want this: grub>kernel hdb:/boot/i386/loader/linux splash=silent showopts console=ttyS0,115200n8 Press <Enter> grub>initrd hdb:/boot/i386/loader/initrd Press <Enter> grub>boot Press <Enter> Your system will now boot right into the Linux install. Hope that helps:-) Thanks - Joe ------------------------------ Message: 4 Date: Wed, 26 Mar 2008 15:43:28 -0400 From: joe(a)smittys.pointclark.net Subject: Re: [coreboot] ICH Series i82801xx EHCI (USB 2.0) problems To: Uwe Hermann <uwe(a)hermann-uwe.de> Cc: Peter Stuge <peter(a)stuge.se>, coreboot(a)coreboot.org Message-ID: <20080326154328.ao9pxp8ogoooos4k(a)www.smittys.pointclark.net> Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Quoting Uwe Hermann <uwe(a)hermann-uwe.de>: > On Wed, Mar 26, 2008 at 08:57:42AM -0400, joe(a)smittys.pointclark.net wrote: >>> Please send lspci from when you've booted with coreboot. Is the EHCI >>> USB controller there at all? If so, there should be errors during >>> boot when the ehci driver tries to load. >>> >>> (Or worst-case coreboot has done such a bad job at init that the >>> driver thinks life is good but in fact nothing EHCI works. :() > > FWIW, here's the diff. I don't think the missing sybsystem IDs are a > problem (and that could be fixed very easily anyway), The strange thing is, the code is already setup to do this but it doesn't for some reason??? > and the different > IRQ and mem regions shouldn't be a problem per se either, correct? Correct, this shouldn't matter. > > > > Might the SERR difference here cause problems? Possible? > > > > The register differences in the EHCI device should probably be analyzed > in detail (using datasheet), haven't done that so far. > > The only differences I can see are registers 0x68 and 0x6C. Register 0x68 (USB EHCI Legacy Support Extended Capability) is supposed to be read only so I don't get that one. And I am not sure exactly that the register 0x6C (USB EHCI Legacy Support Control/Status) has an issue. There is also a "Host Controller Operational Registers" located in memory, but I am not exactly sure how to read those. Thanks - Joe ------------------------------ Message: 5 Date: Wed, 26 Mar 2008 15:51:23 -0400 From: joe(a)smittys.pointclark.net Subject: Re: [coreboot] ICH Series i82801xx EHCI (USB 2.0) problems To: Uwe Hermann <uwe(a)hermann-uwe.de> Cc: coreboot(a)coreboot.org Message-ID: <20080326155123.yrrcso0b4808c00g(a)www.smittys.pointclark.net> Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Quoting Uwe Hermann <uwe(a)hermann-uwe.de>: > On Tue, Mar 25, 2008 at 10:12:29PM -0400, joe(a)smittys.pointclark.net wrote: >>> On Tue, Mar 25, 2008 at 06:51:24PM -0400, joe(a)smittys.pointclark.net wrote: >>>> 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 >>> >>> Flash drive? You mean mounting a USB thumb drive? That should work fine, >>> I tested that on various coreboot boards. Or do you mean an external >>> IDE/SATA drive which is connected via USB to the computer? I think >>> both should work fine. >>> >> Yes neithor of these are working. I have tried USB thumb drives, and a >> IDE-to-USB 2.0 adapter with hard drive and DVD-rom drive. > > Hm, that's strange, because the thumb drive should work even with > USB 1.1 only (it sure does on my boards). > that's what I thought, very strange indeed > > Which ports did you try to use? AFAIUI only one or two of them will be > USB 2.0, the other ones have USB 1.1 speed only, no matter which > settings the BIOS uses. > both > > If you can, please test some other high-speed USB device (not thumb > drives or disks). > ok > >>> Note that AFAICT the USB ports _should_ be intialized ok with coreboot >>> if the board code is ok, but they might only act as "full speed" >>> (USB 1.1) devices. >>> >> Nope USB 2.0 devices (drives) are not detected at bootup, or by hot >> plugging in Linux. USB 1.1 Keyboards, and mice, work fine. > > Hm, the kernel init _seems_ to look ok to me, but maybe I'm missing > something. > Yes, that is why I am stumped:-( > > Loading ehci-hcd.ko module > PCI: Found IRQ 7 for device 0000:00:1d.7 > ehci_hcd 0000:00:1d.7: EHCI Host Controller > ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 4 > ehci_hcd 0000:00:1d.7: debug port 1 > ehci_hcd 0000:00:1d.7: irq 7, io mem 0xf8180000 > ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 > usb usb4: configuration #1 chosen from 1 choice > hub 4-0:1.0: USB hub found > hub 4-0:1.0: 6 ports detected > > > Is the IRQ routing correct? I think so? I will check this. > > If you attach and use USB devices on those > ports, do the numbers in /proc/interrrupts increase? > Well for the keyboard and mouse yes, I have not checked it with a USB 2.0 device, I have not checked that. > > >> Not that I am aware, EHCI seems to setup ok in coreboot, except the >> devices are not detected by coreboot, filo, or Linux. >>> >>> What exactly does _not_ work btw? >> When Linux is running and I plug in a USB flash drive, the led on the >> drive comes on for a few seconds and then turns off, and Linux does not >> detect the drive. I have tried several different brands. They work fine >> with the original bios. > > With or without a USB hub? If hub, is it a self-powered hub? Does the > drive get enough power? > No usb hub. Direct connect. > > > Hm, not sure what's going on, maybe someone else can comment? Please:-( > > It's > possible that you indeed have to do the init mentioned in the datasheet. > Possible, that is why I asked if anyone else was having this problem and/or can confirm it works. Thanks - Joe ------------------------------ Message: 6 Date: Wed, 26 Mar 2008 14:05:50 -0600 From: "Jake Peavy" <djstunks(a)gmail.com> Subject: [coreboot] MIPS Yamon replacement? To: coreboot(a)coreboot.org Message-ID: <c5221b990803261305k280e5c98hb4e67d462c2c4c0e(a)mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" 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

1 0

[RFC] First K8 board to port to v3
by Carl-Daniel Hailfinger 27 Mar '08

27 Mar '08

Hi, to keep a record of the IRC conversation we had yesterday, here is the stuff I said (in slightly rewritten form): Ideal conditions for supporting a board in v3 are: - documentation freely available - board available in the market for the next few months - socketed BIOS - already supported well in v2. Chipset choice (availability in the last field means end-user availability of boards for a recent processor): - SIS 966 family: Source available, no docs, vendor cooperative, almost unavailable. - Nvidia CK804 family: Source available, no docs, no cooperation from vendor, availability rather limited. - Nvidia MCP55 family: Source available, no docs, no cooperation from vendor, readily available. - AMD 8100 family: Source available, docs available, vendor cooperative, almost unavailable. (Can be tested in the freely downloadable SimNow.) - AMD/ATI newer chipsets: No source available, no docs available, vendor cooperative, readily available. (Given AMD's recent track record for opening documentation we probably can expect improvements regarding docs and source). - VIA K8T890: Source available, docs available slowly with NDA (Rudolf has them), vendor somewhat cooperative, availability limited. - VIA K8M890: No source, no docs available yet (Rudolf is working on this), vendor somewhat cooperative, readily available. (Rumored to be similar to K8T890.) Unless things at the chipset front change significantly till the end of April, we are probably stuck with MCP55. Board choice: - Gigabyte M57SLI: Multiple revisions, newer ones (rev 2.x) have soldered SPI flash behind a IT8716F LPC-to-SPI translation chip. Availability prognosis is good. Limitations of the M57SLI (though I can't offer a K8 board supported better in v2): Rev. 2.x boards have SPI behind IT8716F, can only map fixed 512 kByte of ROM into address space.That means we have to rewrite LAR walking completely to work with SPI chips above 512 kByte because we can't map them directly and have to read them byte-by-byte. Then again, if we are willing to live with 512 kByte ROMs on the M57SLI, it should work out just fine. Streaming decompression (like in v2) does not solve the LAR walking problems, because the LAR walk routine expects a memory mapped LARchive.The rewritten LAR walking will be very ugly in v3: either you consume horrible amounts of stack space (~1100 bytes more) or you write a streaming version of strncmp() and wrap most accesses to LAR headers in functions or you shadow/copy all of ROM directly after RAM is enabled. Since you can't map the ROM in memory (except for copying/shadowing), so you have to read it byte-wise and give the decompression routine a callback function which will fetch the ROM contents byte-wise. That makes the decompression a lot slower and it needs additional scratch space. In fact, the additional scratch space requirements can be bigger than the compressed size of the file in ROM, so there are possibly only disadvantages of the streaming decompression method over the shadow/copy method. Of course, the streaming LAR walk and decompression also increases boot block size a lot. So if the person doing the K8 port is willing to limit himself to 512 kByte ROMs on the M57SLI, he avoids all those nasty issues. Regards, Carl-Daniel -- http://www.hailfinger.org/

5 17

filo booting cd problem
by joe＠smittys.pointclark.net 26 Mar '08

26 Mar '08

Hello, I am trying to boot the GeeXboX installer cd from the filo grub prompt and I keep getting this message: hdc: ATAPI: SONY DVD RW DRU-710A 8MB medium detected Disc doesn't use boot disk emulation What am I doing wrong? Thanks - Joe

7 22

Re: [coreboot] Code flow from reset vector
by a a 26 Mar '08

26 Mar '08

Peter Stuge wrote: > On Wed, Mar 26, 2008 at 04:27:11AM -0700, Viswesh S wrote: >> I modified the makefile and copied the coreboot before the >> stripping to vis_1strip and then did an objdump. > > coreboot.rom is not an ELF file so elfutils can't really do much good > with it, as you have noticed. a v2 coreboot.rom actualy IS a elf file (the payload) with some stuff (even another elf and a load of binary code) appended... > > >> [viswesh@arka image]$ objdump -D --start-address=0xfffffff0 --stop-address=0xffffffff vis_1strip >> vis_1strip: file format elf32-i386 >> Disassembly of section .ram: >> Disassembly of section .rom: >> Disassembly of section .reset: >> fffffff0 : >> fff0: e9 51 53 ff ff jmp ffff5346 you should do -mi8086 see below > > Remember I wrote that it is common to have a far jump very early? > > >> So here I can actually see the flash location and the opcodes in >> that location. >> >> But when I do the same, as you mentioned, when I try to dump the >> last 0x20 bytes in coreboot.rom file, I should actually see similar >> instructions and basically there should be a jump in the last 16 bytes. > > If you use an x86 disassembler on the last 16 bytes of coreboot.rom > you will get the above instruction. You can use objdump but it needs > some help. First make a new file starting from the address you are > interested in: > > stuge@n410c ~/co/v2/targets/gigabyte/m57sli/m57sli $ dd if=coreboot.rom of=out bs=$[524288-16] skip=1 > 0+1 records in > 0+1 records out > 16 bytes (16 B) copied, 0.000135259 s, 118 kB/s i agree (524288 is you chip size...... > > Then disassemble: > > stuge@n410c ~/co/v2/targets/gigabyte/m57sli/m57sli $ objdump -b binary -m i386 -D out wrong should be objdump -b binary -m i8086 -D out remember that ALL cpus of teh x86 famaly EVEN the most new ones start basicaly as an 8086 aka in realmode (it has some tricks in place with CS but thats another story and quete hard to follow).... bottom line is that objdump does proetct mode disassemble when dont give a -m of give -mi386 ... -mi8086 makes it do realmode disasmbly and that what you will need for the first ??(100 ?? orso) bytes that get executed .. basicaly that jump then some segment discriptor setup and the switch to protected mode > > out: file format binary > > Disassembly of section .data: > > 0000000000000000 : > 0: e9 11 f0 ff ff jmp 0xfffff016 > 5: 00 00 add %al,(%eax) > 7: 00 e9 add %ch,%cl > 9: 5f pop %edi > a: f0 ff lock (bad) > c: ff 00 incl (%eax) > ... > stuge@n410c ~/co/v2/targets/gigabyte/m57sli/m57sli $ > > The addresses say 0 but if you prefer just use the --start-address > option. > > >> [viswesh@arka image]$ objdump -D coreboot.rom | grep -ni reset_vector >> [viswesh@arka image]$ objdump -D coreboot.rom | grep -ni _start > > Will not work since coreboot.rom is not in a file format that objdump > can parse correctly. > > >> [viswesh@arka image]$ objdump -D coreboot.rom | tail >> 13cf96: 00 00 add %al,(%eax) >> 13cf98: 00 00 add %al,(%eax) >> 13cf9a: 00 00 add %al,(%eax) >> 13cf9c: d1 e5 shl %ebp >> 13cf9e: 10 00 adc %al,(%eax) >> 13cfa0: 08 00 or %al,(%eax) >> 13cfa2: 00 00 add %al,(%eax) >> 13cfa4: 27 daa >> 13cfa5: e7 10 out %eax,$0x10 >> ... >> [viswesh@arka image]$ >> >> So here also we dont see any jump to a specific location. > > Again, objdump treats coreboot.rom as an ELF file, which it is not, > and so you get garbage output. it is .. and you are looking at the payload .... > >> So basically where should be the code which should be flashed into >> the location 0xfffffff0. > > It is 16 bytes from the end of coreboot.rom. > >>From your previous work you may be used to working with hex files or > S-records which contain both address and data. Because x86 always > starts at top of 4GB there is no need for address information. > > The flash chip must always be at the top of 4GB. The binary flash > file is always written to the top of the flash. > > >> (or) how can I locate the code inside the coreboot.rom,if it is >> there inside the rom file. > > The dd and objdump trick I show above will work but is very clumsy > and does not scale well. you can also force objdump to start at the end of the file wit --start-address= but you still need to specify -bbinary (and -mi8086 for the parts before the pmode switch) > > I recommend the DOS utility HIEW (Hackers View) if you're going to be > taking apart binary files. It has some useful disassembly options. > > The thing with dd and objdump is that because there are bytes in the > coreboot.rom stream that are not instructions but instead data, it is > not neccessarily possible to disassemble the entire coreboot.rom file > in one go and then take it apart. When data at one byte position is > parsed as an instruction it may parse the following byte as part of > the same instruction which causes an error in alignment in the > disassembler because the data byte in the first position was actually > the last data byte and the following byte was the first byte of an > instruction. This is why you usually have to explicitly chop up the > binary file at whatever boundary you are interested in. > > > But why are you doing this anyway? Wouldn't it be easier to just look > at the source code? > > > //Peter > Reinder _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

2 1

Device mapping problem
by Klaus Stammermann 26 Mar '08

26 Mar '08

Hi there Booting on my Via EPIA-ME6000 with original BIOS the installed OS starts without any problems. But using my coreboot image it got a problem with device mapping. I posted changes on my coreboot config here: http://www.coreboot.org/pipermail/coreboot/2008-March/031945.html At end of that posting there is this error description: "But system does not booting at all. I think device mapping works not correct. On booting system is checking sda. Some errors like: exception Emask ... 0x2 frozen soft resetting port... configured for UDMA... (... are inserted by me because I got this output only on display) At end kernel panic is shown: 0800 2000880 sda driver: sd Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) But installed system starts with original bios. As device I use a CF-disk on an CF-IDE adapter." I try to solve this problem, but I don't know where to look at. Does anyone get an idea what could be wrong in my config? Greetings Klaus

4 10

Re: [coreboot] Code flow from reset vector
by Viswesh S 26 Mar '08

26 Mar '08

Hi , Thanks for the answers, but still some questions. I modified the makefile and copied the coreboot before the stripping to vis_1strip and then did an objdump. [viswesh@arka image]$ objdump -D --start-address=0xfffffff0 --stop-address=0xffffffff vis_1strip vis_1strip: file format elf32-i386 Disassembly of section .ram: Disassembly of section .rom: Disassembly of section .reset: fffffff0 <reset_vector>: fff0: e9 51 53 ff ff jmp ffff5346 <_start+0x2> fff5: 00 00 add %al,(%eax) fff7: 00 e9 add %ch,%cl fff9: 9f lahf fffa: 53 push %ebx fffb: ff (bad) fffc: ff 00 incl (%eax) ... Disassembly of section .id: [viswesh@arka image]$ So here I can actually see the flash location and the opcodes in that location. But when I do the same, as you mentioned, when I try to dump the last 0x20 bytes in coreboot.rom file, I should actually see similar instructions and basically there should be a jump in the last 16 bytes. [viswesh@arka image]$ objdump -D coreboot.rom | grep -ni reset_vector [viswesh@arka image]$ objdump -D coreboot.rom | grep -ni _start [viswesh@arka image] Here I have dumped both the beginning and the end of the coreboot,rom file. [viswesh@arka image]$ objdump -D coreboot.rom | more coreboot.rom: file format elf32-i386 Disassembly of section .note: 00100000 <.note>: 100000: 08 00 or %al,(%eax) 100002: 00 00 add %al,(%eax) 100004: 05 00 00 00 01 add $0x1000000,%eax 100009: 00 00 add %al,(%eax) 10000b: 00 45 4c add %al,0x4c(%ebp) 10000e: 46 inc %esi 10000f: 42 inc %edx 100010: 6f outsl %ds:(%esi),(%dx) 100011: 6f outsl %ds:(%esi),(%dx) 100012: 74 00 je 0x100014 100014: 46 inc %esi 100015: 49 dec %ecx [viswesh@arka image]$ objdump -D coreboot.rom | tail 13cf96: 00 00 add %al,(%eax) 13cf98: 00 00 add %al,(%eax) 13cf9a: 00 00 add %al,(%eax) 13cf9c: d1 e5 shl %ebp 13cf9e: 10 00 adc %al,(%eax) 13cfa0: 08 00 or %al,(%eax) 13cfa2: 00 00 add %al,(%eax) 13cfa4: 27 daa 13cfa5: e7 10 out %eax,$0x10 ... [viswesh@arka image]$ So here also we dont see any jump to a specific location. So basically where should be the code which should be flashed into the location 0xfffffff0. (or) how can I locate the code inside the coreboot.rom,if it is there inside the rom file. Thanks in advance, Viswesh ----- Original Message ---- From: a a <todthgie(a)hotmail.com> To: coreboot(a)coreboot.org Cc: viswesh_vichu(a)yahoo.com Sent: Wednesday, March 26, 2008 1:04:13 PM Subject: Re: [coreboot] Code flow from reset vector Hello, Viswesh S wrote: > Hi, > I understand the procedure in which internally how the CS register ( > Segment selector and base address part) make sure that we point to the > address 0xFFFFFFF0. correct > But my doubts are in this part. > 1) We will be flashing the coreboot.rom into the BIOS flash, right ? yes and the flash chip is mapped at 0x(1)00000000 - chipsize (0xFFFFFFFF - chipsize +1 in the core iirc) so a 256Kbyte (0x40000 bytes) chip would be at 0xFFFC0000....0xFFFFFFFF.... > 2) If we objdump coreboot.rom, dump all the sections, we dont see the > reset vector part and also the address 0xFFFFFFF0.This could be because > these sections are stripped off.Is it because of that ? no, it will be at chipsize -0x10 (0x3FFF0 for a 256Kbyte chip) coreboot.rom should be EXACLY as long as you flash chip is .... so 0x10 bytes from the end of the file > 4) If they are stripped off, then when I flash the coreboot.rom, what do > I flash into the address 0xFFFFFFF0, as the coreboot.rom doesnt even > contain the data(opcodes ) to write in that location. no they should not be stripped... whats in the file @ 0x10 bytes from the end ends op @ 0xFFFFFFF0 > Am I missing anything. > Regards, > Viswesh > ps:- I am trying to correlate my experience in embedded firmware exp, > where the files we were flashing had absolute addresses and we could > objdump the flash file to understand the code at each location. a lot of embedded targets have the flash at 0x00000000 the x86 does not. the adresses are static but have a offset of 4G-chipsize ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

2 1

MSI 7250 (MCP55 based) pci slots Interrupts problem
by George V. Adamov 26 Mar '08

26 Mar '08

MSI MS7250 - MCP 55 based motherboard. I have troubles with interrupts of devices plug in PCI slots. If I use irq_tables.c with only record for irq router (just like it is for Gigabyte based on MCP55 and MSI7260 ): write_pirq_info(pirq_info, bus_mcp55[0], ((sbdn+6)<<3)|0, 0x1, 0xdef8, 0x2, 0xdef8, 0x3, 0xdef8, 0x4, 0xdef8, 0, 0); Linux says that no interrupt for pin A assigned for devices in pcis slots. I grubbed IRQ table with getpir and added records for other devices. As for pci slots it looks like /*slot0*/ write_pirq_info(pirq_info, 0x01, ((sbdn+0x00)<<3)|0, 0x80/*80*/, 0x0800, 0x00, 0x0000, 0x00, 0x0000, 0x00, 0x00000, 0x1, 0x0); pirq_info++; slot_num++; /*slot1*/ write_pirq_info(pirq_info, 0x01, ((sbdn+0x01)<<3)|0, 0x81/*81*/,/*0x0800*/ 0x0800, 0x00,/*0x0*/ 0x0000, 0x00,/*0x0*/ 0x0000, 0x00, 0x00000, 0x2, 0x0); pirq_info++; slot_num++; /*slot2*/ write_pirq_info(pirq_info, 0x01, ((sbdn+0x02)<<3)|0, 0x82,/*0x4ca0*/ 0x4c80, 0x83, 0x4ca0, 0x80, 0x4ca0, 0x81, 0x04ca0, 0x3, 0x0); And I also used function pci_assign_irqs - to write irqs from the table into configuration space of each device After this the device plug in pci slot0 starts up (it was a network card), but running cat /proc/interrupts - showed strange CPU time for eth0 (at least 3 orders higher than any other device) it was also easy to note that system was a bit slow with ethernet card pluged. But at least card worked ;) I tried to plug it to slot1 and slot2 - when Linux tried to load module for the card I got NMI (((( Any ideas what the trouble is ?

1 0

Re: [coreboot] Code flow from reset vector
by a a 26 Mar '08

26 Mar '08

Hello, Viswesh S wrote: > Hi, > I understand the procedure in which internally how the CS register ( > Segment selector and base address part) make sure that we point to the > address 0xFFFFFFF0. correct > But my doubts are in this part. > 1) We will be flashing the coreboot.rom into the BIOS flash, right ? yes and the flash chip is mapped at 0x(1)00000000 - chipsize (0xFFFFFFFF - chipsize +1 in the core iirc) so a 256Kbyte (0x40000 bytes) chip would be at 0xFFFC0000....0xFFFFFFFF.... > 2) If we objdump coreboot.rom, dump all the sections, we dont see the > reset vector part and also the address 0xFFFFFFF0.This could be because > these sections are stripped off.Is it because of that ? no, it will be at chipsize -0x10 (0x3FFF0 for a 256Kbyte chip) coreboot.rom should be EXACLY as long as you flash chip is .... so 0x10 bytes from the end of the file > 4) If they are stripped off, then when I flash the coreboot.rom, what do > I flash into the address 0xFFFFFFF0, as the coreboot.rom doesnt even > contain the data(opcodes ) to write in that location. no they should not be stripped... whats in the file @ 0x10 bytes from the end ends op @ 0xFFFFFFF0 > Am I missing anything. > Regards, > Viswesh > ps:- I am trying to correlate my experience in embedded firmware exp, > where the files we were flashing had absolute addresses and we could > objdump the flash file to understand the code at each location. a lot of embedded targets have the flash at 0x00000000 the x86 does not. the adresses are static but have a offset of 4G-chipsize > Message: 5 > Date: Wed, 26 Mar 2008 00:40:21 +0100 > From: Peter Stuge > > Subject: Re: [coreboot] Code flow from reset vector > To: coreboot(a)coreboot.org > Message-ID: > > Content-Type: text/plain; charset=us-ascii > > On Tue, Mar 25, 2008 at 12:02:15PM -0700, Viswesh S wrote: > > I understand the coreboot.rom is the BIOS code, which comes inside > > the address mapped in real mode.( 0xA0000 - 0x100000). > > Mh, not only. > > > > If that is the case, then how do we write into the address > > 0xFFFFFFF0, while we flash the BIOS. > > 386 and up power up with CS set specially so that it "points" at > physical address 0xffff0000. Similar to the flat real mode idea. > > A far/long jump changes CS into plain real mode so a far jump is > pretty common early in the boot process. > > > //Peter > > > > ------------------------------ > > > ------------------------------------------------------------------------ > Never miss a thing. Make Yahoo your homepage. > > _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

1 0

Re: [coreboot] Code flow from reset vector
by Viswesh S 26 Mar '08

26 Mar '08

Hi, I understand the procedure in which internally how the CS register ( Segment selector and base address part) make sure that we point to the address 0xFFFFFFF0. But my doubts are in this part. 1) We will be flashing the coreboot.rom into the BIOS flash, right ? 2) If we objdump coreboot.rom, dump all the sections, we dont see the reset vector part and also the address 0xFFFFFFF0.This could be because these sections are stripped off.Is it because of that ? 4) If they are stripped off, then when I flash the coreboot.rom, what do I flash into the address 0xFFFFFFF0, as the coreboot.rom doesnt even contain the data(opcodes ) to write in that location. Am I missing anything. Regards, Viswesh ps:- I am trying to correlate my experience in embedded firmware exp, where the files we were flashing had absolute addresses and we could objdump the flash file to understand the code at each location. Message: 5 Date: Wed, 26 Mar 2008 00:40:21 +0100 From: Peter Stuge <peter(a)stuge.se> Subject: Re: [coreboot] Code flow from reset vector To: coreboot(a)coreboot.org Message-ID: <20080325234021.15330.qmail(a)stuge.se> Content-Type: text/plain; charset=us-ascii On Tue, Mar 25, 2008 at 12:02:15PM -0700, Viswesh S wrote: > I understand the coreboot.rom is the BIOS code, which comes inside > the address mapped in real mode.( 0xA0000 - 0x100000). Mh, not only. > If that is the case, then how do we write into the address > 0xFFFFFFF0, while we flash the BIOS. 386 and up power up with CS set specially so that it "points" at physical address 0xffff0000. Similar to the flat real mode idea. A far/long jump changes CS into plain real mode so a far jump is pretty common early in the boot process. //Peter ------------------------------ ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs

1 0

Igel Thinclient tk 3000
by Markus 26 Mar '08

26 Mar '08

Today i was able to boot via etherboot 5.4.3 coreboot v2. But only with irqpoll. So i generate with getpir a irq_tables.c. I use the axus/tc320 as sample. So i copied the irq_tables.c to src/mainboard/axus/tc320 but after i can't compile any more. gcc -Wl,--build-id=none -nostdlib -nostartfiles -static -o coreboot_ram -T /home/ryven/Linuxbios/coreboot-v2/src/config/coreboot_ram.ld coreboot_ram.o coreboot_ram.o: In function `write_tables': (.text+0x26f2): undefined reference to `write_pirq_routing_table' collect2: ld returned 1 exit status make[1]: *** [coreboot_ram] Fehler 1 make[1]: Leaving directory `/home/ryven/Linuxbios/coreboot-v2/targets/axus/tc320/tc320/normal' make: *** [normal/coreboot.rom] Fehler 1 So how is the right way? Regards Markus

2 3

← Newer
1
...
5
6
7
8
9
10
11
...
39
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 March 2008