January 2014 - coreboot - mail.coreboot.org

Re: [coreboot] C720 swapparoo
by Aaron Durbin Jan. 29, 2014

Jan. 29, 2014

On Wed, Jan 29, 2014 at 4:25 PM, Aaron Durbin <adurbin(a)google.com> wrote: > On Wed, Jan 29, 2014 at 4:16 PM, John Lewis <jlewis(a)johnlewis.ie> wrote: >> On 29/01/14 22:03, Aaron Durbin wrote: >>>> >>>> >>>> This is where we reach the crux of the matter - In the stock/shellball >>>> firmware, extracting BOOT_STUB doesn't yield a file which cbfstool in >>>> upstream coreboot or CrOS coreboot can decipher. Looking at the file in >>>> hexedit it appears to be almost identical to a CBFS that is recognised, >>>> but >>>> that's it. I have managed to extract the SVGA binary from the CBFS in the >>>> RW_LEGACY slot, and I've made an educated guess as to where the >>>> system-agent >>>> begins and ends in the unrecognised CBFS (section beginning "LARCHIVE >>>> mrc.bin" or similar with the binary itself following, surrounded by FF's) >>>> copying and pasting it to a file. I would like to know if I am correct in >>>> my >>>> assumptions about extracting that file manually and what size it should >>>> be, >>>> in bytes? >>>> >>> >>> That's interesting. It is just a regular 'ol cbfs. The images that >>> shipped with your device is an 8MiB SPI. First 2MiB Duncan covered. >>> The next 5 have nothing to do w/ coreboot proper -- all the extra >>> vboot firmware bits. The last 1MiB is the cbfs. >>> >> >> Okay, well I extracted the attached file using: >> >> eval `./fmap_decode bios.bin | grep BOOT_STUB` >> dd if=c720.rom ibs=$((area_offset)) skip=1 | dd bs=$((area_size)) >> iflag=fullblock of=c720-coreboot.bin >> >> and: >> >> ../coreboot/build/cbfstool c720-coreboot.bin print >> >> produces: >> >> c720-coreboot.bin: >> 1024 kB, bootblocksize 3144, romsize 8388608, offset 0x700000 >> alignment: 64 bytes >> >> Name Offset Type Size >> >> zippo. >> > > Try cherry-picking this one: > https://chrome-internal-review.googlesource.com/153037 Ugh. If only my copy/past worked. Try this one instead: http://review.coreboot.org/#/c/4771/ -Aaron

1 0

Re: [coreboot] C720 swapparoo
by John Lewis Jan. 29, 2014

Jan. 29, 2014

On 29/01/14 20:54, Duncan Laurie wrote: > > - The SPI flash descriptor, which lives at the bottom 4K of the SPI > chip in the SI_DESC region of the flashmap. It is readable from the > host but not writable. > - The Management Engine binary, which lives at the bottom 2MB (-4K for > the descriptor) of the SPI chip in the SI_ME region of the flashmap. > It is neither readable or writable from the host. Okay, I have the descriptor and ME binaries already (I guess it doesn't matter too much about the ME anyway, since it being missing wouldn't prevent boot, just cause half-hourly power-off). > > For the basic coreboot+payload (BOOT_STUB region in flashmap) the > binaries are all in CBFS and can be read out with the usual 'cbfstool > bios.bin extract -n NAME -f NAME' > > - The mainboard-specific DIMM SPDs, stored as "spd.bin" (also checked > in to the mainboard directory in coreboot) > - The reference code binary, which is stored as "mrc.bin" > - The Video BIOS, which is stored as "pci8086,0406.rom" > - The microcode, which is stored as "cpu_microcode_blob.bin" (with > recent changes this may be handled differently upstream now) > This is where we reach the crux of the matter - In the stock/shellball firmware, extracting BOOT_STUB doesn't yield a file which cbfstool in upstream coreboot or CrOS coreboot can decipher. Looking at the file in hexedit it appears to be almost identical to a CBFS that is recognised, but that's it. I have managed to extract the SVGA binary from the CBFS in the RW_LEGACY slot, and I've made an educated guess as to where the system-agent begins and ends in the unrecognised CBFS (section beginning "LARCHIVE mrc.bin" or similar with the binary itself following, surrounded by FF's) copying and pasting it to a file. I would like to know if I am correct in my assumptions about extracting that file manually and what size it should be, in bytes? Further more, trying to use upstream coreboot to compile with that 2 MB management engine yields: Created CBFS image (capacity = 8386544 bytes) E: Not enough space for content. E: Could not add [c720-me.bin, 2093056 bytes (2044 KB)@0x7a0000]; too big? E: Failed to add 'c720-me.bin' into ROM image. I have tried 2, 4, 6, and 8 MB CBFS in coreboot menuconfig. Not sure why building for Peppy tries to put the ME in CBFS when other builds don't. Building using CrOS coreboot works, but I am loath to recommend someone foolhardy with a C720 try it, unless I know there is a reasonable chance the binaries are okay/correct. John.

2 2

Re: [coreboot] C720 swapparoo
by John Lewis Jan. 29, 2014

Jan. 29, 2014

Forgot to hit reply to all/list, again ... On 29/01/14 19:14, Duncan Laurie wrote: > > Of course you could also replace the payload with SeaBIOS directly if > you are so inclined. This is just a way to enable default legacy mode > without having to modify the underlying firmware. > > -duncan > Many thanks for the comprehensive answer, Duncan. That will certainly keep many C720 users happy. However, as I would also ultimately like to get rid of nag screens, etc, the quoted bit above leads me to more questions. What do you mean by replacing the payload, literally replacing one of the payloads or compiling my own coreboot? As the binaries are not in the third-party repo, is it possible to successfully extract and use them from the stock ROM? John.

2 1

Re: [coreboot] Shortened in types (u32) vs stdint types (uint32_t)
by Peter Stuge Jan. 29, 2014

Jan. 29, 2014

Aaron Durbin wrote: > We should accept patches that come in any form. I could not disagree more with this in general. I disagree less strongly for the specific case of u32 vs. uint32_t but I do still disagree - I also like the stdint types, mostly because they are becoming widely available. I think they look ugly, but I also have a strong preferece to always keep declarations at start of functions rather than as close to the use as possible, so they don't have to be all over the code. > I also might add that the kernel allows such types: It's allowed to be better than the kernel. > I don't think that adds any barrier to readability. I think it does. Not a very large barrier, but it does add one. It's nice to have a code style to fall back on, maybe even neccessary, when all developers don't prefer the same style anyway, which is, well, unusual. //Peter

2 1

C720 swapparoo
by John Lewis Jan. 29, 2014

Jan. 29, 2014

Dear List, If I dd the contents of the RW_LEGACY slot into the WP_RO slot on the stock c720 firmware, will it a) Still work and b) then boot into SeaBIOS by default? :) John.

2 1

Shortened in types (u32) vs stdint types (uint32_t)
by mrnuke Jan. 29, 2014

Jan. 29, 2014

<rant> stdint types are ugly as hell. That "_t" at the end is a pain in the ass to type, every day of the week. They're too freaking long for a variable type. A real pain. There is still widespread lack of adoption and FUD towards these types. I'm willing to bet that, had they been named properly, like uint32 (not a typo, there is no "_t"), the adoption would not be an issue. </rant> We normally use supershort in types in coreboot (u32). I am, of course, ignoring the legacy legacy types such as unsigned long, which have sadly persisted in coreboot source from the very early days. Personally, I'm a fan of u32 short types, and I really enjoy working with them. However, recent contributions to other projects have forced me to suck it up and deal with their stdint evil sisters. To the real point: We have lots of recent contributions from google, which use stdint types. They're compatible with our old short types because, well, they're typedef'd from the same thing. The problem however, is that it creates more inconsistency within our tree. As a result, I propose we make stdint types mandatory, and deprecate shortname types. People don't want to learn a separate set of data types for every project to which they contribute. stdint types solve this problem by being standardized. I am far from liking this change, but it just makes sense. So, can we get votes of approval? I can add this info to the Coding Guidelines if there is enough support. Hopefully, we'll be able to migrate to stdint entirely, and drop shorties. Alex

6 7

Re: [coreboot] Shortened in types (u32) vs stdint types (uint32_t)
by Aaron Durbin Jan. 29, 2014

Jan. 29, 2014

On Tue, Jan 28, 2014 at 6:37 PM, ron minnich <rminnich(a)gmail.com> wrote: > Standardizing on the short names is easy. Converting to them is even > easier, via spatch. I'll +2 such patches :-) > > We can make the cut in less time than it takes to discuss it :-) > > I'm not that concerned either way, except that, historically, coreboot > has gone with the short names. I personally don't think there should be any sort of standard. We should accept patches that come in any form. I also might add that the kernel allows such types: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include… I haven't heard any technical arguments as to only allow the short names, and our own stdint.h provides the uintX_t variants. For the people that find typing uintX_t hard then they are free to use the short ones. I don't think that adds any barrier to readability. Both sets of types describe the bit width which is the most important. -Aaron

1 0

FSP or standalone coreboot support for D525
by prasanna karthik Jan. 29, 2014

Jan. 29, 2014

Is there a port available for Intel atom Atom D525 based nexcom EBC 352 board?

1 0

Unable to start correctly coreboot on Asus f2a85-m REV 1.02
by HacKurx Jan. 26, 2014

Jan. 26, 2014

Hi, Despite my many test I can not run correctly coreboot on my motherboard. Here is my hardware: _F2A85-M REV 1.02 _AMD A8-6600K APU (Radeon HD 8570D vga = 1002,990e) _Corsair Value Select 4 Go DDR3 1333 MHz CL9 (CMV4GX3M1A1333C9) lspci 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Complex 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Richland [Radeon HD 8570D] 00:01.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Trinity HDMI Audio Controller 00:10.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller (rev 03) 00:10.1 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller (rev 03) 00:11.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 40) 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller (rev 11) 00:12.2 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller (rev 11) 00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller (rev 11) 00:13.2 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller (rev 11) 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 14) 00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD] FCH Azalia Controller (rev 01) 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 11) 00:14.4 PCI bridge: Advanced Micro Devices, Inc. [AMD] FCH PCI Bridge (rev 40) 00:15.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Hudson PCI to PCI bridge (PCIE port 0) 00:15.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Hudson PCI to PCI bridge (PCIE port 1) 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 0 00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 1 00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 2 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 3 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 4 00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Function 5 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 09) I proceeded to build a standard coreboot image using seabios as a payload (using a local copy of the VGA bios and embedding this into the coreboot image), leaving all the settings as default apart from selecting the motherboard, upon writing this to the flash and rebooting the machine I had no output from the VGA & HDMI adapter and and my keyboard is frozen. Can you send me a link to a known-good image that you use? So that i can verify my hardware is compatible. Does he work the revision 1.02 of this motherboard in coreboot? Thank you for your help. -- Best regards, HacKurx (Loic) hackurx.wordpress.org

1 0

cmos.layout upgradability
by Vladimir 'φ-coder/phcoder' Serbinenko Jan. 26, 2014

Jan. 26, 2014

Hello, all. Due to my failue to foresee this problem if one upgrades X60 coreboot, you need to manually reset CMOS config or your trackpad may not work as option "trackpad_enable" will get a garbage value. While I admit my part of fault, I feel like we should have a way to update options safely. I see following possibilities: 1) Hide ourselves and tell that on upgrade you always have to clear CMOS. I don't think it's really an option as users will continue just running flashrom and in case of external flashing, CMOS reset may require full power removal with cell battery sometimes in difficult to access places inside laptop. 2) Have some version field to check and if it mismatches reset CMOS to default. To avoid having to maintain version manually I propose to checksum option table and write 16-bit result to CMOS. 16-bit should give enough confidence without excessively using CMOS. I've made a prototype at http://review.coreboot.org/#/c/4790/4 . If we can agree that it's a right approach, I'll make this prototype into complete patch (mostly missing is laborous adding of version field) 2a) instead of having separate field we could make XOR layout checksum into CMOS checksum. This would save 2 bytes but will break any existing users if they check checksum.

3 5