[coreboot] How can extract descriptor.bin from bios image?
Dear Sir. My EVB is ADI SG-2440 and mohon peak CRB. This time, My coreboot image are not running GbE. Another guy are said to me that "Must add a descriptor.bin to coreboot.img". And I was found the descriptor.bin from original bios image. See below. * poplinux@raw rangeley $ > ./tools/ifdtool ~/data/project/sdk/intel_rangeley/crb/BIOS/BIOS1_org.bin -d File /home/poplinux/data/project/sdk/intel_rangeley/crb/BIOS/BIOS1_org.bin is 8388608 bytes FLMAP0:0x01040003 NR: 1 FRBA:0x40 NC: 1 FCBA:0x30 FLMAP1:0x09100206 ISL: 0x09 FPSBA: 0x100 NM: 2 FMBA:0x60 FLMAP2:0x00210020 PSL: 0x2100 FMSBA: 0x200 FLUMAP1: 0x08e0 Intel ME VSCC Table Length (VTL):8 Intel ME VSCC Table Base Address (VTBA): 0x000e00 ME VSCC table: JID0: 0x001740ef SPI Componend Device ID 1: 0x17 SPI Componend Device ID 0: 0x40 SPI Componend Vendor ID:0xef VSCC0: 0x20052005 Lower Erase Opcode: 0x20 Lower Write Enable on Write Status: 0x50 Lower Write Status Required:No Lower Write Granularity:64 bytes Lower Block / Sector Erase Size:4KB Upper Erase Opcode: 0x20 Upper Write Enable on Write Status: 0x50 Upper Write Status Required:No Upper Write Granularity:64 bytes Upper Block / Sector Erase Size:4KB JID1: 0x00167120 SPI Componend Device ID 1: 0x16 SPI Componend Device ID 0: 0x71 SPI Componend Vendor ID:0x20 VSCC1: 0xd817d817 Lower Erase Opcode: 0xd8 Lower Write Enable on Write Status: 0x06 Lower Write Status Required:No Lower Write Granularity:64 bytes Lower Block / Sector Erase Size:64KB Upper Erase Opcode: 0xd8 Upper Write Enable on Write Status: 0x06 Upper Write Status Required:No Upper Write Granularity:64 bytes Upper Block / Sector Erase Size:64KB JID2: 0x00177120 SPI Componend Device ID 1: 0x17 SPI Componend Device ID 0: 0x71 SPI Componend Vendor ID:0x20 VSCC2: 0xd817d817 Lower Erase Opcode: 0xd8 Lower Write Enable on Write Status: 0x06 Lower Write Status Required:No Lower Write Granularity:64 bytes Lower Block / Sector Erase Size:64KB Upper Erase Opcode: 0xd8 Upper Write Enable on Write Status: 0x06 Upper Write Status Required:No Upper Write Granularity:64 bytes Upper Block / Sector Erase Size:64KB JID3: 0x00172020 SPI Componend Device ID 1: 0x17 SPI Componend Device ID 0: 0x20 SPI Componend Vendor ID:0x20 VSCC3: 0xd817d817 Lower Erase Opcode: 0xd8 Lower Write Enable on Write Status: 0x06 Lower Write Status Required:No Lower Write Granularity:64 bytes Lower Block / Sector Erase Size:64KB Upper Erase Opcode: 0xd8 Upper Write Enable on Write Status: 0x06 Upper Write Status Required:No Upper Write Granularity:64 bytes Upper Block / Sector Erase Size:64KB OEM Section: 00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Found Region Section FLREG0:0x01ff Flash Region 0 (Flash Descriptor): - 001f FLREG1:0x07ff0200 Flash Region 1 (BIOS): 0020 - 007f FLREG2:0x0fff Flash Region 2 (Intel ME): 00fff000 - 0fff (unused) FLREG3:0x0fff Flash Region 3 (GbE): 00fff000 - 0fff (unused) FLREG4:0x0fff Flash Region 4 (Platform Data): 00fff000 - 0fff (unused) Found Component Section FLCOMP 0x09300024 Dual Output Fast Read Support: not supported Read ID/Read Status Clock Frequency: 33MHz Write/Erase Clock Frequency: 33MHz Fast Read Clock Frequency: 33MHz Fast Read Support: supported Read Clock Frequency:20MHz Component 2 Density: 8MB Component 1 Density: 8MB FLILL 0x Invalid Instruction 3: 0x00 Invalid Instruction 2: 0x00 Invalid Instruction 1: 0x00 Invalid Instruction 0: 0x00 FLPB 0x Flash Partition Boundary Address: 0x00 Found PCH Strap Section PCHSTRP0: 0x081a0002 PCHSTRP1: 0x PCHSTRP2: 0x PCHSTRP3: 0x0003 PCHSTRP4: 0x007f PCHSTRP5: 0x007fffc0 PCHSTRP6: 0x0001c7c
Re: [coreboot] ifwitool: Incorrect calculation of dst_size
Hello Furquan, On Mon, 13 Jun 2016, Furquan Shaikh wrote: > Hello Rolf, > Thanks for the fix! Yes, the correction looks good. Please feel free to push > this change to gerrit on coreboot.org. > thank you for your fast reply. I will try to push this change. Best regards, Rolf -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: [GSoC] Better RISC-V support, week #3
A new post titled "[GSoC] Better RISC-V support, week #3" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/06/13/gsoc-better-risc-v-support-week-3/ Last week, after updating GCC (by applying Iru Cai’s patch) and commenting out uses of outdated instructions and CSRs (most notably eret and the HTIF CSRs), I noticed that coreboot crashed when it tried to access any global variables. This was because the coreboot build system thought coreboot would live near the start of the address space. I found spike-riscv/memlayout.ld, and adjusted the starting offset. But then I got a linker error: build/bootblock/arch/riscv/rom_media.o: In function `boot_device_ro': [...]/src/arch/riscv/rom_media.c:26:(.text.boot_device_ro+0x0): relocation truncated to fit: _RISCV_HI20 against `.LANCHOR0' I played around with the start address and noticed that addresses below 0x7800 worked, but if I chose an address that was too close to 0x8000, it broke. This is, in fact, because pointers to global variables were determined with an instruction sequence like lui a0, 0xN; addi a0, a0, 0xNNN. On 32-bit RISC-V, the LUI instruction loads its argument into the upper 20 bits of a register, and ADDI adds a 12-bit number. On a 64-bit RISC-V system, lui a0, 0x8 loads 0x8000 into a0, because the number is sign extended. After disassembling some .o files of coreboot and the RISC-V proxy kernel, I finally noticed that I had to use the -mcmodel=medany compiler option, which makes data accesses pc-relative. Now that coreboot finally ran and could access its data section, I finished debugging the UART block that I promised last week. Coreboot can now print stuff, but it stops running pretty soon. Plans for this week This week I will debug why coreboot hangs, and will hopefully get it to boot until the “Payload not found” line again, which worked with an older version of Spike. Also, Ron Minnich will be giving a talk about coreboot on RISC-V at the coreboot convention in San Francisco, in a few hours. -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] ifwitool: Incorrect calculation of dst_size
Dear Furquan, it seems to me that there is a slight formal mistake in calculation of dst_size, which causes the ifwitool to crash. I was able to fix it on my own with the following patch, which moves the closing bracket one line ahead: diff --git a/util/cbfstool/ifwitool.c b/util/cbfstool/ifwitool.c index 7fca542..a1365bd 100644 --- a/util/cbfstool/ifwitool.c +++ b/util/cbfstool/ifwitool.c @@ -1679,8 +1679,8 @@ static enum ifwi_ret ifwi_dir_replace(int type) } struct buffer dst; - size_t dst_size = buffer_size(&ifwi_image.subpart_buf[type] + - buffer_size(&b) - s->e[i].length); + size_t dst_size = buffer_size(&ifwi_image.subpart_buf[type]) + + buffer_size(&b) - s->e[i].length; size_t subpart_start = s->e[i].offset; size_t subpart_end = s->e[i].offset + s->e[i].length; Could you please confirm if this correction is okay? Best regards, Rolf -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Not running GbE interface.
Dear Sir. My EVB is Rangeley Mohon peak. I was successfuly build and boot the coreboot on my EVB. But, not running the GbE interface. So, I was try to find the mailing list . and Got a some threads. *1. **Message for **G**bE(**This is **perfectly same **that my issue**)* https://www.coreboot.org/pipermail/coreboot/2015-January/079074.html => But this mail is not include detail procedure.(some link a brokened.) Anyway. got a important thing. That "Must need a descriptor.bin". *2. descripter.bin * https://www.coreboot.org/pipermail/coreboot/2015-March/079532.html => This message recommand that It is easy, the descripter.bin is extract from ADI's coreboot binary. But i don't have a idea to extract from ADI's coreboot binary. Please advise to me. thank you. -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ifwitool: Incorrect calculation of dst_size
Hello Rolf, Thanks for the fix! Yes, the correction looks good. Please feel free to push this change to gerrit on coreboot.org. - Furquan On Mon, Jun 13, 2016 at 4:10 AM, Rolf Evers-Fischer < embedde...@evers-fischer.de> wrote: > Dear Furquan, > it seems to me that there is a slight formal mistake in calculation of > dst_size, which causes the ifwitool to crash. > > I was able to fix it on my own with the following patch, which moves the > closing bracket one line ahead: > > diff --git a/util/cbfstool/ifwitool.c b/util/cbfstool/ifwitool.c > index 7fca542..a1365bd 100644 > --- a/util/cbfstool/ifwitool.c > +++ b/util/cbfstool/ifwitool.c > @@ -1679,8 +1679,8 @@ static enum ifwi_ret ifwi_dir_replace(int type) > } > > struct buffer dst; > - size_t dst_size = buffer_size(&ifwi_image.subpart_buf[type] + > - buffer_size(&b) - s->e[i].length); > + size_t dst_size = buffer_size(&ifwi_image.subpart_buf[type]) + > + buffer_size(&b) - s->e[i].length; > size_t subpart_start = s->e[i].offset; > size_t subpart_end = s->e[i].offset + s->e[i].length; > > > Could you please confirm if this correction is okay? > > Best regards, > Rolf > -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
