March 2015 - coreboot - mail.coreboot.org

lenovo thinkpad edge 11 (amd variant / 2545)
by Jens Thiele March 20, 2015

March 20, 2015

Hi, After reading [0] and looking for a bios update (without success) I thought, maybe I should give coreboot a try. But it looks like the lenovo thinkpad edge 11 (amd variant / 2545) isn't supported yet? following the FAQ [1] : Step 1: lenovo thinkpad edge 11 (amd variant / 2545) Step 2: -[0000:00]-+-00.0 Advanced Micro Devices [AMD] RS880 Host Bridge [1022:9601] +-01.0-[01]--+-05.0 Advanced Micro Devices [AMD] nee ATI RS880M [Mobility Radeon HD 4200 Series] [1002:9712] | \-05.1 Advanced Micro Devices [AMD] nee ATI RS880 HDMI Audio [Radeon HD 4200 Series] [1002:970f] +-04.0-[02-07]----00.0 Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] +-05.0-[08]----00.0 Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter [10ec:8176] +-11.0 Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] [1002:4391] +-12.0 Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] +-12.2 Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396] +-13.0 Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] +-13.2 Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396] +-14.0 Advanced Micro Devices [AMD] nee ATI SBx00 SMBus Controller [1002:4385] +-14.2 Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel HDA) [1002:4383] +-14.3 Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 LPC host controller [1002:439d] +-14.4-[09]-- +-18.0 Advanced Micro Devices [AMD] Family 10h Processor HyperTransport Configuration [1022:1200] +-18.1 Advanced Micro Devices [AMD] Family 10h Processor Address Map [1022:1201] +-18.2 Advanced Micro Devices [AMD] Family 10h Processor DRAM Controller [1022:1202] +-18.3 Advanced Micro Devices [AMD] Family 10h Processor Miscellaneous Control [1022:1203] \-18.4 Advanced Micro Devices [AMD] Family 10h Processor Link Control [1022:1204] Step 3: superiotool r6637 Probing for ALi Super I/O at 0x3f0... Failed. Returned data: id=0xffff, rev=0xff Probing for ALi Super I/O at 0x370... Failed. Returned data: id=0xffff, rev=0xff Probing for Fintek Super I/O at 0x2e... Failed. Returned data: vid=0x0001, id=0x0285 Probing for Fintek Super I/O at 0x4e... Failed. Returned data: vid=0xffff, id=0xffff Probing for Fintek Super I/O at 0x2e... Failed. Returned data: vid=0x0001, id=0x0285 Probing for Fintek Super I/O at 0x4e... Failed. Returned data: vid=0xffff, id=0xffff Probing for ITE Super I/O (init=standard) at 0x25e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8502e) at 0x25e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8761e) at 0x25e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8228e) at 0x25e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=0x87,0x87) at 0x25e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=standard) at 0x2e... Found ITE IT8502E/TE/G (id=0x8502, rev=0x0) at 0x2e Register dump: idx 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e val 85 02 60 01 00 00 00 00 00 00 00 00 01 00 00 def 85 02 71 01 NA 00 00 NA NA NA NA NA NA 00 NA LDN 0x01 (UART1) idx 30 60 61 62 63 70 71 f0 val 00 00 00 00 00 00 00 00 def 00 03 f8 00 00 04 02 00 LDN 0x04 (System Wake-Up) idx 30 60 61 62 63 70 71 f0 val 00 00 00 00 00 00 01 00 def 00 00 00 00 00 00 01 00 LDN 0x05 (Mouse) idx 30 60 61 62 63 70 71 f0 val 01 00 00 00 00 0c 01 00 def 01 00 00 00 00 0c 01 NA LDN 0x06 (Keyboard) idx 30 60 61 62 63 70 71 f0 val 01 00 60 00 64 01 01 00 def 01 00 60 00 64 01 01 NA LDN 0x0f (Shared Memory/Flash) idx 30 60 61 62 63 70 71 f4 f5 f6 val 01 00 00 00 00 00 00 09 00 00 def 00 00 00 00 00 00 00 00 00 00 LDN 0x10 (BRAM) idx 30 60 61 62 63 70 71 f3 f4 f5 val 01 00 70 07 02 08 01 00 3f 3f def 00 00 70 00 72 08 01 NA NA NA LDN 0x11 (Power Channel 1) idx 30 60 61 62 63 70 71 val 01 00 62 00 66 00 01 def 00 00 62 00 66 01 01 LDN 0x12 (Power Channel 2) idx 30 60 61 62 63 70 71 val 01 00 68 00 6c 00 01 def 00 00 68 00 6c 01 01 LDN 0x17 (Power Channel 3) idx 30 60 61 62 63 70 71 val 00 00 00 00 00 00 00 def 00 00 6a 00 6e 01 01 Probing for ITE Super I/O (init=standard) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8502e) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8761e) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8228e) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=0x87,0x87) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=legacy/it8661f) at 0x370... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=legacy/it8671f) at 0x370... Failed. Returned data: id=0xffff, rev=0xf Probing for NSC Super I/O at 0x2e... Failed. Returned data: sid=0x85, srid=0x00 Probing for NSC Super I/O at 0x4e... Failed. Returned data: port=0xff, port+1=0xff Probing for NSC Super I/O at 0x15c... Failed. Returned data: port=0xff, port+1=0xff Probing for NSC Super I/O at 0x164e... Failed. Returned data: port=0xff, port+1=0xff Probing for Nuvoton Super I/O at 0x164e... Failed. Returned data: chip_id=0xffff Probing for Nuvoton Super I/O (sid=0xfc) at 0x164e... Failed. Returned data: sid=0xff, id=0xffff, rev=0x00 Probing for Nuvoton Super I/O at 0x2e... Failed. Returned data: chip_id=0x8502 Probing for Nuvoton Super I/O (sid=0xfc) at 0x2e... Failed. Returned data: sid=0x85, id=0x8502, rev=0x00 Probing for Nuvoton Super I/O at 0x4e... Failed. Returned data: chip_id=0xffff Probing for Nuvoton Super I/O (sid=0xfc) at 0x4e... Failed. Returned data: sid=0xff, id=0xffff, rev=0x00 Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x2e... Found SMSC SCH5317 (id=0x85, rev=0x02) at 0x2e No dump available for this Super I/O Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x2e... Failed. Returned data: id=0x00, rev=0x00 Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x4e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x4e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x162e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x162e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x164e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x164e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x3f0... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x3f0... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x370... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x370... Failed. Returned data: id=0xff, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x2e... Failed. Returned data: id/oldid=0x85/0x00, rev=0x02 Probing for Winbond Super I/O (init=0x89) at 0x2e... Failed. Returned data: id/oldid=0x85/0x00, rev=0x02 Probing for Winbond Super I/O (init=0x86,0x86) at 0x2e... Failed. Returned data: id/oldid=0x85/0x00, rev=0x02 Probing for Winbond Super I/O (init=0x87,0x87) at 0x2e... Failed. Returned data: id/oldid=0x85/0x00, rev=0x02 Probing for Winbond Super I/O (init=0x88) at 0x4e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x4e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x4e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x4e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x3f0... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x3f0... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x3f0... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x3f0... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x370... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x370... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x370... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x370... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x250... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x250... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x250... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x250... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for VIA Super I/O at 0x3f0... PCI device 1106:0686 not found. Probing for Server Engines Super I/O at 0x2e... Failed. Returned data: id=0x8502, rev=0x00 Step 4: flashrom v0.9.7-r1852 on Linux 3.2.0-4-amd64 (x86_64) flashrom is free software, get the source code at http://www.flashrom.org flashrom was built with libpci 3.1.9, GCC 4.7.2, little endian Command line (3 args): flashrom -V -p internal Calibrating delay loop... OS timer resolution is 1 usecs, 340M loops per second, delay more than 10% too short (got 49% of expected delay), recalculating... 247M loops per second, delay more than 10% too short (got 36% of expected delay), recalculating... 283M loops per second, delay more than 10% too short (got 41% of expected delay), recalculating... 278M loops per second, delay more than 10% too short (got 40% of expected delay), recalculating... 291M loops per second, 10 myus = 4 us, 100 myus = 42 us, 1000 myus = 417 us, 10000 myus = 4182 us, 4 myus = 1 us, OK. Initializing internal programmer No coreboot table found. Using Internal DMI decoder. DMI string chassis-type: "Notebook" Laptop detected via DMI. DMI string system-manufacturer: "LENOVO" DMI string system-product-name: "2545A26" DMI string system-version: "ThinkPad Edge" DMI string baseboard-manufacturer: "LENOVO" DMI string baseboard-product-name: "2545A26" DMI string baseboard-version: "Not Available" W836xx enter config mode worked or we were already in config mode. W836xx leave config mode had no effect. Active config mode, unknown reg 0x20 ID: 85. Please send the output of "flashrom -V -p internal" to flashrom(a)flashrom.org with W836xx: your board name: flashrom -V as the subject to help us finish support for your Super I/O. Thanks. Found ITE EC, ID 0x8502, Rev 0x60 on port 0x2e. PS: anybody knows how to find out wether I am effected by [0] at all? [0] http://www.heise.de/newsticker/meldung/Sicherheitsluecke-in-Firmware-von-AM… (sorry in German) didn't get around to watch http://media.ccc.de/browse/congress/2014/31c3_-_6103_-_en_-_saal_2_-_201412… https://events.ccc.de/congress/2014/Fahrplan/events/6103.html yet [1] http://www.coreboot.org/FAQ

1 0

Re: [coreboot] 0xE0000/0xF0000 segment issue
by WANG FEI March 20, 2015

March 20, 2015

I'm curious why your seabios payload is loading to shadow RAM (C/D/E/F000 segment), this area suppose to be used by seabios, I guess since seabios is a legacy BIOS. My suggestion is to load your seabios to a over 1MB address. On Thu, Mar 19, 2015 at 2:38 PM, Naresh G. Solanki < naresh.solanki.2011(a)gmail.com> wrote: > Hi All, > > > I'm trying to port coreboot with seabios payload. > Everything goes fine till the control is transferred to payload. > > Since payload is loaded between memory range 0xC_0000 - 0x10_0000. > > The problem I was facing was that the board was going to auto reboot mode > while executing payload.. > > Once it reboot then I'm not able to control the processor through XDP > until I manually do CPU reset. > > It keeps on rebooting once control is transferred to payload. > > > To find out the cause I did detailed memory test & found out that the > memory range 0xA0000 - 0xBFFFF & 0xE0000 - 0xFFFFF always reads 0xFF. > > since payload is loaded in the same region so before jmp_payload, I tried > to read this region through XDP & found payload code exist. > > so I introduced wbinvd instruction just before jmp_payload & I found that > the XDP started reading 0xFF in the memory range 0xE0000 - 0xFFFFF. > > Thus from this I conclude that before the payload was able to execute > because of cached copy of it in CPU cache & it didn't really existed in RAM. > > Also to enable memory range 0xE_0000 to 0xF_FFFF I have followed the > guidlines as per table 15 of the document > > http://www.intel.com/content/www/us/en/intelligent-systems/queens-bay/atom-… > > Is that OK. > What I can do to successfully enable the memory range 0xE_0000 to > 0xF_FFFF for read write operation so that my payload execution goes > undisturbed. > > My ultimate aim is to load Windows by Seabios as payload. > > Thanks > N Solanki > > > > > > > > > > > > > > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] VGA doesn't work on Mohon Peak
by Kuzmichev Viktor March 20, 2015

March 20, 2015

My setup is this: coreboot loads SeaBIOS as a primary payload which then loads GRUB from hard drive which in its turn boots Linux. What I am trying to achieve is to have Linux output on VGA display. I've changed debug level to 8 but still have not been able to see anything related to VGA or display or something else close to it in the output. And after enabling boot splash the board just reboots. I tried different framebuffer graphics resolutions with different color modes. I added new log in the attachment. It's also worth to mention that VGA works fine with vendor's BIOS, so I booted both Linux and Windows with it. Still, can't figure out why VGA controller does not work properly with coreboot. -Viktor On 03/19/2015 05:58 PM, WANG FEI wrote: > Viktor, I've messed around VGA function on my platform before, I got > the problem to display seabios messages on VGA as well, finally I fed > up and enabled the bootsplash in coreboot instead, as along as the > coreboot splash can be shown on monitor, which proves the VGA function > works, it's what I want, maybe you want more... > > Here is my suggestions, 1) Once the VGA option rom integrated in > coreboot, making sure it can be invoked during coreboot booting, you > possible have to change the debug level to 8 to get more coreboot > debug message. I remember it will show a message before/after VGA > option rom invoked, searching "VGA" or other keyword in your coreboot > log to make sure it does happen. 2) Enable boot splash on coreboot, > making sure it can be shown up on your monitor. > > I can not help you on seabios VGA function, I never make it work neither. > > -Fei > > On Thu, Mar 19, 2015 at 10:22 AM, Kuzmichev Viktor > <kuzmichevviktorv(a)gmail.com <mailto:kuzmichevviktorv@gmail.com>> wrote: > > Hello, > > I'm using coreboot + SeaBIOS on Mohon Peak CRB. And I've tried to > make VGA work for a while now. I used this article as a guide: > http://www.coreboot.org/VGA_support > > Extracting VGA BIOS from vendor BIOS image did not work: > $ ./bios_extract EDVLCRB1.86B.0043.R00.1408290947_MPK.bin > Using file "EDVLCRB1.86B.0043.R00.1408290947_MPK.bin" (8192kB) > Error: Unable to detect BIOS Image type. > > Then, I've downloaded VGA BIOS from here: > http://www.aspeedtech.com/support.php > Mohon Peak uses Aspeed VGA controller AST1300. > > And also, I've extracted Video ROM from /dev/mem: > # dd if=/dev/mem of=vgabios.bin bs=1k count=32 skip=768 > > Neither of them worked. Here's what I've tried. I've tried to add > them via coreboot's menuconfig (' Add VGA BIOS image' option). > I've tried to add them manually via cbfstool as an optionrom and > as a raw file. I've tried to put them in CBFS under vgaroms/ > directory. Here's my latest ROM-file layout: > $ ./build/cbfstool build/coreboot.rom print > coreboot.rom: 8192 kB, bootblocksize 1024, romsize 8388608, offset > 0x600000 > alignment: 64 bytes, architecture: x86 > > Name Offset Type Size > cmos_layout.bin 0x600000 cmos_layout 1352 > pci1a03,2000.rom 0x600580 optionrom 32768 > fallback/romstage 0x6085c0 stage 26616 > fallback/ramstage 0x60ee00 stage 59904 > fallback/payload 0x61d840 payload 56100 > config 0x62b3c0 raw 4532 > revision 0x62c5c0 raw 708 > pci8086,1f41.rom 0x62c8c0 raw 61952 > vgaroms/pci1a03,2000.rom 0x63bb00 raw 32768 > img/Memtest86+(5.01) 0x643b40 payload 159492 > (empty) 0x66aa80 null 939288 > mrc.cache 0x74ffc0 (unknown) 65536 > cpu_microcode_blob.bin 0x760000 microcode 83968 > (empty) 0x774840 null 46936 > fsp.bin 0x77ffc0 (unknown) 372736 > (empty) 0x7db000 null 150424 > > The entries pci1a03,2000.rom are the VGA ROMs there. I also tried > to remove either of them. I've tested with coreboot option 'Run > VGA Option ROMs' checked and unchecked without any difference. In > SeaBIOS I set 'VGA Hardware Type (coreboot linear framebuffer)' as > the other options are None, GeodeGX2 and GeodeLX, so coreboot > linear framebuffer seemed more logical. > > I saw this mailing list: > http://www.seabios.org/pipermail/seabios/2015-January/008588.html > but found no solution there and it seems not to be my case as my > board does not hang. > > I put coreboot and SeaBIOS output in the attachment. Debug levels > set to 7 for both. In coreboot only 'Output verbose CBFS debug > messages' checked in 'Debugging' submenu. > > Is there anything I'm doing wrong or simply missing? > > Viktor > > -- > coreboot mailing list: coreboot(a)coreboot.org > <mailto:coreboot@coreboot.org> > http://www.coreboot.org/mailman/listinfo/coreboot > >

1 0

How to do source code level debug of coreboot?
by 郭佳 March 20, 2015

March 20, 2015

Hi, I'm porting coreboot to Intel C2000 Rangeley based board. I've purchased Asset Arium ECM-XDP3e debugger, but the support from provider is quite limited and I can't do source code level debug using it. I would like to ask: (1) What is the coreboot binary with debug information? Shall I just specify coreboot.rom in my debugger application, or there are separated binary files, such as rom stage, ram stage and payloads? (2) What is the load address of coreboot? Shall I adjust the symbol table when coreboot is copied from ROM to RAM? Regards, Hook Guo

1 0

Re: [coreboot] GCC update broke AMD Fam10h boot
by Aaron Durbin March 20, 2015

March 20, 2015

On Thu, Mar 19, 2015 at 7:53 PM, Julius Werner <jwerner(a)chromium.org> wrote: >> 145a8a: 83 c3 14 add $0x14,%ebx > > Okay, sorry, I didn't know you looked that closely into this. That's > quite unrefuteable. > > The only question that I still have is then WTF the compiler was > thinking... this just sounds like a plain bug somewhere (but I agree > that doesn't really help us much). We could still work around it with > an explicit __attribute__((aligned, 4)) or __attribute__((packed)) if > that works... I guess if the compiler does this for no apparent > reason, then there's no real guarantee that a simple list of pointers > won't also get screwed up like this? Well... I was working the assumption an array of pointers couldn't possibly get hosed. That's about all I got for that. ;) As for decorating the structures it's just sort of a pain in that you need to match alignment of the symbol in the linker script and the structure declaration -- for every object that we place like this in the linker scripts. Definitely doable though. Something to keep in one's back pocket. -Aaron

1 0

Re: [coreboot] GCC update broke AMD Fam10h boot
by Julius Werner March 20, 2015

March 20, 2015

> 145a8a: 83 c3 14 add $0x14,%ebx Okay, sorry, I didn't know you looked that closely into this. That's quite unrefuteable. The only question that I still have is then WTF the compiler was thinking... this just sounds like a plain bug somewhere (but I agree that doesn't really help us much). We could still work around it with an explicit __attribute__((aligned, 4)) or __attribute__((packed)) if that works... I guess if the compiler does this for no apparent reason, then there's no real guarantee that a simple list of pointers won't also get screwed up like this?

1 0

Re: [coreboot] GCC update broke AMD Fam10h boot
by Aaron Durbin March 20, 2015

March 20, 2015

On Thu, Mar 19, 2015 at 7:21 PM, Julius Werner <jwerner(a)chromium.org> wrote: >> That said, I went back and looked at the assembly dump. It was using >> 0x14 as the size of the structure when sequencing through the entries. >> >> 001465dc R _bs_init_begin >> 001465e0 r cbmem_bscb >> 00146600 r gcov_bscb >> 0014663c R _bs_init_end >> >> Each *entry* was aligned to 0x20. Just aligning the symbol wouldn't >> have fixed it. That means we'd need to mark the structure declaration >> as aligned to a specific value and annotate it accordingly in the >> linker script. That's one route or just go w/ pointers to the >> structures. > > Yeah, that's what I was talking about in the first mail... I think > this means that the compiler would consider the sizeof() for each > structure to be 0x20. I'm pretty sure there's some kind of rule that > the sizeof() for any object must be evenly divisible by its minimum > alignment... that's how normal arrays work as well (e.g. if you had > struct mystruct { uint32_t a; uint8_t b; } and don't mark it > __packed__, then sizeof(struct mystruct) is 0x8 and an array of them > would have 3 bytes padding after each entry). So I'm pretty sure the > pointer++ mechanism to walk through it would've still worked if the > initial address had been right. (can we repro this? then we could > simply try it out instead of guessworking.) I think you misunderstood what I wrote; I wasn't guessworking. The bscb structure arrays were aligned to 0x20. But the structure size to the compiler is 0x14. It's 0x14 in gdb and it's 0x14 in the instructions calculating the next entry. That's how I diagnosed this to begin with. From 4.92/ramstage.debug: 145991: bb dc 65 14 00 mov $0x1465dc,%ebx ... 145a36: 81 fb 3c 66 14 00 cmp $0x14663c,%ebx 145a3c: 74 5f je 145a9d <main+0x11c> ... 145a8a: 83 c3 14 add $0x14,%ebx ... 145a9b: eb 99 jmp 145a36 <main+0xb5> So we know the first entry in the array is wrong based on _bs_init_begin != cbmem_bscb. However, ignoring that the entry after cbmem_bscb is wrong too because the 0x14 increment will not result in resolving to gcov_bscb. -Aaron

1 0

Re: [coreboot] GCC update broke AMD Fam10h boot
by Timothy Pearson March 20, 2015

March 20, 2015

On 03/19/2015 09:21 PM, Julius Werner wrote: >> That said, I went back and looked at the assembly dump. It was using >> 0x14 as the size of the structure when sequencing through the entries. >> >> 001465dc R _bs_init_begin >> 001465e0 r cbmem_bscb >> 00146600 r gcov_bscb >> 0014663c R _bs_init_end >> >> Each *entry* was aligned to 0x20. Just aligning the symbol wouldn't >> have fixed it. That means we'd need to mark the structure declaration >> as aligned to a specific value and annotate it accordingly in the >> linker script. That's one route or just go w/ pointers to the >> structures. > > Yeah, that's what I was talking about in the first mail... I think > this means that the compiler would consider the sizeof() for each > structure to be 0x20. I'm pretty sure there's some kind of rule that > the sizeof() for any object must be evenly divisible by its minimum > alignment... that's how normal arrays work as well (e.g. if you had > struct mystruct { uint32_t a; uint8_t b; } and don't mark it > __packed__, then sizeof(struct mystruct) is 0x8 and an array of them > would have 3 bytes padding after each entry). So I'm pretty sure the > pointer++ mechanism to walk through it would've still worked if the > initial address had been right. (can we repro this? then we could > simply try it out instead of guessworking.) Reproduction should be a simple matter of reverting 9ef9d859 on your local tree and building for the ASUS KFSN4-DRE; the breakage was extremely consistent and reproducible. The only wildcard would be that gcc was building coreboot with specific optimisations for the AMD Fam10h processor; you might need to force the appropriate flags set (-mtune=amdfam10 ?) if building on some other CPU. -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com

1 0

Re: [coreboot] GCC update broke AMD Fam10h boot
by Julius Werner March 20, 2015

March 20, 2015

> That said, I went back and looked at the assembly dump. It was using > 0x14 as the size of the structure when sequencing through the entries. > > 001465dc R _bs_init_begin > 001465e0 r cbmem_bscb > 00146600 r gcov_bscb > 0014663c R _bs_init_end > > Each *entry* was aligned to 0x20. Just aligning the symbol wouldn't > have fixed it. That means we'd need to mark the structure declaration > as aligned to a specific value and annotate it accordingly in the > linker script. That's one route or just go w/ pointers to the > structures. Yeah, that's what I was talking about in the first mail... I think this means that the compiler would consider the sizeof() for each structure to be 0x20. I'm pretty sure there's some kind of rule that the sizeof() for any object must be evenly divisible by its minimum alignment... that's how normal arrays work as well (e.g. if you had struct mystruct { uint32_t a; uint8_t b; } and don't mark it __packed__, then sizeof(struct mystruct) is 0x8 and an array of them would have 3 bytes padding after each entry). So I'm pretty sure the pointer++ mechanism to walk through it would've still worked if the initial address had been right. (can we repro this? then we could simply try it out instead of guessworking.)

1 0

Re: [coreboot] GCC update broke AMD Fam10h boot
by Aaron Durbin March 20, 2015

March 20, 2015

On Thu, Mar 19, 2015 at 3:54 PM, Julius Werner <jwerner(a)chromium.org> wrote: >> You are right that it would work, but back solving for which alignment >> the compiler decided is hard. It's definitely whack-a-mole in that >> case. It could have very well decided 16 too. Without any insight as >> to why that breaks down. Or you go the route of putting alignments on >> structures just for that behavior which I consider not the best >> approach. > > Well, we only need to pick an alignment *larger* than what the > compiler decides, right? I'd hazard a guess that 8 would be enough for > a long time (GCC probably just got confused between 32 and 64 bit > modes or something... there's no other reason I could think of to > explain this). Yes, my concern was not knowing that upper limit. I looked into the Linux kernel on how they do most of this. From what I could tell they largely use pointers to the structures like I worked around it. When embedding structures into sections they use ALIGN(8) as you suggested (see include/asm-generic/vmlinux.lds.h for the fun). That said, I went back and looked at the assembly dump. It was using 0x14 as the size of the structure when sequencing through the entries. 001465dc R _bs_init_begin 001465e0 r cbmem_bscb 00146600 r gcov_bscb 0014663c R _bs_init_end Each *entry* was aligned to 0x20. Just aligning the symbol wouldn't have fixed it. That means we'd need to mark the structure declaration as aligned to a specific value and annotate it accordingly in the linker script. That's one route or just go w/ pointers to the structures. I'm looking forward to your linker scripts through preprocessor patches to land because we can leverage for aligning some linker scripts across archs, etc. Right now the changes are cumbersome. The last part is just me whining. :) > >>> From that I'd conclude that if you did: >>> >>> extern struct boot_state_init_entry _bs_init_begin[]; >>> extern struct boot_state_init_entry _bs_init_end[]; >>> >>> for (cur = _bs_init_begin; cur < _bs_init_end; cur++) ... >>> >>> the compiler shouldn't be able to guarantee that the first array >>> wasn't empty and therefore pointing to "one after the end" which is >>> the start of the next array in the first iteration. >> >> I think you are right on that point -- using '<' instead of equality. >> But those aren't pointer types. Not sure if the spec things arrays >> like that are poitners or a separate type. Either way, hopefully there >> isn't some language in the spec that suggests comparisons like that >> can be optimized away. > > The array degenerates to a pointer at that point AFAIK. You could also > write &_bs_init_begin... for an array type the two should be pretty > much equivalent. We can still try that w/o the NULL tombstones. It doesn't hurt to try, right?

1 0