coreboot July 2014

coreboot@coreboot.org

44 participants
92 discussions

Re: [coreboot] [RFC] board_status: Add serial log to `serial_console.txt`
by ron minnich 04 Jul '14

04 Jul '14

On Thu, Jul 3, 2014 at 4:18 PM, David Hendricks <dhendrix(a)google.com> wrote: > Necromancing this thread... > > Sage has a patch to *optionally* use a serial console log in > board_status.sh: http://review.coreboot.org/#/c/6094/ > > Earlier objections to such an approach seemed to stem from either: > - Desire to use cbmem console instead. A fine idea, but on some platforms > (especially those which use AGESA) a lot of information gets spit out to > the console before cbmem is available. Re-factoring to make cbmem init > happen earlier is unfeasible AFAICT. > > - Avoid confusing cbmem console log and other logs. This can be easily > solved by using a different filename. I personally think it's best to only > upload one log (whichever is most useful) and avoid polluting the web UI > with redundant files. But I could live with multiple console logs if others > feel strongly. > > Seeing as how only a small handful of people currently actually use this > utility anyway, I'm inclined to think it's best to make the utility more > useful for a major coreboot contributor get some more status reports > uploaded. > > > Yes, please, let's just get this done. I think Sage's arguments make lots of sense. ron

1 0

source of coreboot boot log for board-status database
by Martin Roth 04 Jul '14

04 Jul '14

I've added a routine to grab the boot log for the board-status database from a serial device. I didn't realize at the time that it had already been voted down on the mailing list - I was told that if I wanted this to go in, I should appeal to the mailing list. Please see the patch here: http://review.coreboot.org/#/c/6094/ Since there are currently some platforms that do not yet support the cbmem console, I would like to be able to grab the console from a serial device on the host side. I'm happy to mark it as coming from the serial device, and note in the script that by preference the cbmem console log should be used. I am fully prepared to add text to the script belittling anyone who has to fall back to such plebian measures or any other punishments that are deemed to be required. Other possible alternatives I see to having the script read the console from a serial device: 1) Add a command line option to the board_status.sh script that allows the user to point to a file already containing the console log. 2) Add a command line option to allow the console log to just be skipped and upload the rest of the data without it. 3) Simply wait until the boards support cbmem console log and not push anything about those platforms until that point. 4) Collect the data manually and push it into the repo without the board_status.sh script being used. My thought is that having the script grab the data from the serial port is better than any of these options, but I'm sure there are other possibilities that I've missed. (Apologies if my tone offends anyone - I'm told that when I try to be funny, it comes across as condecension. I guess that's why I'm a programmer and not a comedian.) <-- my new tagline. Martin

2 1

Re: [coreboot] [RFC] board_status: Add serial log to `serial_console.txt`
by Vladimir 'φ-coder/phcoder' Serbinenko 04 Jul '14

04 Jul '14

On 10.02.2014 23:47, David Hendricks wrote: > On Sun, Feb 9, 2014 at 4:50 AM, Paul Menzel > <paulepanter(a)users.sourceforge.net > <mailto:paulepanter@users.sourceforge.net>> wrote: > > Dear coreboot folks, > > > currently no coreboot messages are stored for boards not supporting > CBMEM console (or where this option is disabled (currently by default)) > or no coreboot *romstage* messages are stored for boards, where the data > cannot be preserved (passed to ramstage). > > Using the serial (or USB) console all these messages can be captured > with no problem, so I propose to just add these captured messages into > the file `serial_console.txt`. Of course this file probably contains > also the payload and (Linux) kernel log, but I think that is fine. > > SeaBIOS’ `readserial.py` should be used for capturing the messages as it > adds time stamps. > > Scripting this is going to be hard, as the log is captured on a > different system. So for now I propose to add it manually. > > > I don't think the script itself should be responsible for collecting > serial output. Instead, how about adding an argument to override the > default behavior of running "cbmem -c" on the target so that the user > can pass in a filename? The user will simply capture the serial output > using whatever tool they like, dump the output to a text file, and run > the script with an argument to use the file instead of calling "cbmem > -c". Here is a proof-of-concept: http://review.coreboot.org/#/c/5191 . > This requires user to do right manipulations. While keyboard and chair are usually fine, the space between them exhibits strong bug-inducing properties. The idea of the script is to reduce a possibility of user error creating strange reports. In this case the common erro I expect is using a stale file fom some other version. It's a particularly nasty one as at first glance in may look fine but would be almost useless to track how details changed from one submit to the next. If we let user supply files at all, it should be added to report, not replace files, and it should have some prefix to clearly indicate that user was involved in creating them. E.g. user_serial_log.txt > But in general I think I agree with Vladimir. CBMEM console should be > supported and if not then that should be fixed. > > -- > David Hendricks (dhendrix) > Systems Software Engineer, Google Inc. > >

6 14

Re: [coreboot] Request for Intel Haswell info
by ron minnich 03 Jul '14

03 Jul '14

as a first pass, did you burn coreboot for the wrong board just to see if you got anything al all on serial? I just went through this process on a different board and that was my starting point, as it is for many. ron

1 0

Re: [coreboot] F2A85-M: Chassis Fan Not Working
by Idwer Vollering 03 Jul '14

03 Jul '14

2014-06-28 17:59 GMT+02:00 HacKurx <hackurx(a)gmail.com>: > Hi, > > I just update coreboot on my motherboard and after reboot of my > computer the chassis fan stopped working. > > I did not have this problem with the version of coreboot from 1 March 2014: > http://review.coreboot.org/#/c/5226/ > > Have you an idea of the problem? Thank you No, I can't reproduce that (see console output below). Then again, I don't use the boxed fan ;) Do(es) the fan(s) start when you put some load on your machine, to 'warm up' the APU? Play some 1080p video or compile a linux kernel, reusing your distribution's .config found in /boot/ or /proc/ coreboot-4.0-6334-g6a089e3 do jul 3 15:47:49 CEST 2014 starting... BSP Family_Model: 00610f01 cpu_init_detectedx = 00000000 agesawrapper_amdinitreset Fch OEM config in INIT RESET Done PCI: 00:14.4 bridge ctrl <- 0403 PCI: 00:14.4 cmd <- 01 PCI: 00:14.5 subsystem <- 1022/1410 PCI: 00:14.5 cmd <- 02 PCI: 00:14.7 subsystem <- 1022/1410 PCI: 00:14.7 cmd <- 06 PCI: 00:15.0 bridge ctrl <- 0003 PCI: 00:15.0 cmd <- 00 PCI: 00:15.1 bridge ctrl <- 0003 PCI: 00:15.1 cmd <- 07 PCI: 00:18.0 cmd <- 00 PCI: 00:18.1 subsystem <- 1022/1410 PCI: 00:18.1 cmd <- 00 PCI: 00:18.2 subsystem <- 1022/1410 PCI: 00:18.2 cmd <- 00 PCI: 00:18.3 subsystem <- 1022/1410 PCI: 00:18.3 cmd <- 00 PCI: 00:18.4 subsystem <- 1022/1410 PCI: 00:18.4 cmd <- 00 PCI: 00:18.5 subsystem <- 1022/1410 PCI: 00:18.5 cmd <- 00 PCI: 03:00.0 cmd <- 03 done. BS: BS_DEV_ENABLE times (us): entry 321 run 38403 exit 0 Initializing devices... Root Device init Root Device init 794 usecs CPU_CLUSTER: 0 init start_eip=0x00001000, code_size=0x00000031 Initializing CPU #0 CPU: vendor AMD device 610f01 CPU: family 15, model 10, stepping 01 Using generic cpu ops (good) Model 15 Init. MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled Enabling cache Setting up local apic... apic_id: 0x10 done. siblings = 03, CPU #0 initialized CPU1: stack_base 002c5000, stack_end 002c5ff8 Asserting INIT. Waiting for send to finish... +Deasserting INIT. Waiting for send to finish... +#startup loops: 2. Sending STARTUP #1 to 17. After apic_write. Startup point 1. Waiting for send to finish... +Sending STARTUP #2 to 17. After apic_write. Startup point 1. Waiting for send to finish... +After Startup. Initializing CPU #1 CPU: vendor AMD device 610f01 CPU: family 15, model 10, stepping 01 Using generic cpu ops (good) Model 15 Init. MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled Enabling cache Setting up local apic... apic_id: 0x11 done. siblings = 03, CPU #1 initialized CPU2: stack_base 002c4000, stack_end 002c4ff8 Asserting INIT. Waiting for send to finish... +Deasserting INIT. Waiting for send to finish... +#startup loops: 2. Sending STARTUP #1 to 18. After apic_write. Startup point 1. Waiting for send to finish... +Sending STARTUP #2 to 18. After apic_write. Startup point 1. Waiting for send to finish... +After Startup. Initializing CPU #2 CPU: vendor AMD device 610f01 CPU: family 15, model 10, stepping 01 Using generic cpu ops (good) Model 15 Init. MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled Enabling cache Setting up local apic... apic_id: 0x12 done. siblings = 03, CPU #2 initialized CPU3: stack_base 002c3000, stack_end 002c3ff8 Asserting INIT. Waiting for send to finish... +Deasserting INIT. Waiting for send to finish... +#startup loops: 2. Sending STARTUP #1 to 19. After apic_write. Startup point 1. Waiting for send to finish... +Sending STARTUP #2 to 19. After apic_write. Startup point 1. Waiting for send to finish... +After Startup. Initializing CPU #3 Waiting for 1 CPUS to stop CPU: vendor AMD device 610f01 CPU: family 15, model 10, stepping 01 Using generic cpu ops (good) Model 15 Init. MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled Enabling cache Setting up local apic... apic_id: 0x13 done. siblings = 03, CPU #3 initialized All AP CPUs stopped (1219 loops) CPU1: stack: 002c5000 - 002c6000, lowest used address 002c5dc8, stack used: 568 bytes CPU2: stack: 002c4000 - 002c5000, lowest used address 002c4dc8, stack used: 568 bytes CPU3: stack: 002c3000 - 002c4000, lowest used address 002c3dc8, stack used: 568 bytes CPU_CLUSTER: 0 init 153026 usecs PCI: 00:00.0 init PCI: 00:00.0 init 830 usecs PCI: 00:01.0 init In CBFS, ROM address for PCI: 00:01.0 = ffc00778 PCI expansion ROM, signature 0xaa55, INIT size 0xfa00, data ptr 0x01b4 PCI ROM image, vendor ID 1002, device ID 9904, PCI ROM image, Class Code 030000, Code Type 00 Copying VGA ROM Image from ffc00778 to 0xc0000, 0xfa00 bytes Real mode stub @00000600: 867 bytes Calling Option ROM... ... Option ROM returned. VGA Option ROM was run PCI: 00:01.0 init 77789 usecs PCI: 00:01.1 init PCI: 00:01.1 init 830 usecs PCI: 00:10.0 init PCI: 00:10.0 init 830 usecs PCI: 00:10.1 init PCI: 00:10.1 init 830 usecs PCI: 00:11.0 init PCI: 00:11.0 init 830 usecs PCI: 00:12.0 init PCI: 00:12.0 init 830 usecs PCI: 00:12.2 init PCI: 00:12.2 init 830 usecs PCI: 00:13.0 init PCI: 00:13.0 init 830 usecs PCI: 00:13.2 init PCI: 00:13.2 init 826 usecs PCI: 00:14.0 init IOAPIC: Initializing IOAPIC at 0xfec00000 IOAPIC: Bootstrap Processor Local APIC = 0x10 IOAPIC: ID = 0x04 IOAPIC: Dumping registers reg 0x0000: 0x04000000 reg 0x0001: 0x00178021 reg 0x0002: 0x04000000 IOAPIC: 24 interrupts IOAPIC: Enabling interrupts on FSB IOAPIC: reg 0x00000000 value 0x10000000 0x00000700 IOAPIC: reg 0x00000001 value 0x00000000 0x00010000 IOAPIC: reg 0x00000002 value 0x00000000 0x00010000 IOAPIC: reg 0x00000003 value 0x00000000 0x00010000 IOAPIC: reg 0x00000004 value 0x00000000 0x00010000 IOAPIC: reg 0x00000005 value 0x00000000 0x00010000 IOAPIC: reg 0x00000006 value 0x00000000 0x00010000 IOAPIC: reg 0x00000007 value 0x00000000 0x00010000 IOAPIC: reg 0x00000008 value 0x00000000 0x00010000 IOAPIC: reg 0x00000009 value 0x00000000 0x00010000 IOAPIC: reg 0x0000000a value 0x00000000 0x00010000 IOAPIC: reg 0x0000000b value 0x00000000 0x00010000 IOAPIC: reg 0x0000000c value 0x00000000 0x00010000 IOAPIC: reg 0x0000000d value 0x00000000 0x00010000 IOAPIC: reg 0x0000000e value 0x00000000 0x00010000 IOAPIC: reg 0x0000000f value 0x00000000 0x00010000 IOAPIC: reg 0x00000010 value 0x00000000 0x00010000 IOAPIC: reg 0x00000011 value 0x00000000 0x00010000 IOAPIC: reg 0x00000012 value 0x00000000 0x00010000 IOAPIC: reg 0x00000013 value 0x00000000 0x00010000 IOAPIC: reg 0x00000014 value 0x00000000 0x00010000 IOAPIC: reg 0x00000015 value 0x00000000 0x00010000 IOAPIC: reg 0x00000016 value 0x00000000 0x00010000 IOAPIC: reg 0x00000017 value 0x00000000 0x00010000 PCI: 00:14.0 init 66902 usecs PCI: 00:14.2 init PCI: 00:14.2 init 830 usecs PCI: 00:14.3 init RTC Init PCI: 00:14.3 init 1284 usecs PCI: 00:14.4 init PCI: 00:14.4 init 830 usecs PCI: 00:14.5 init PCI: 00:14.5 init 830 usecs PCI: 00:14.7 init PCI: 00:14.7 init 826 usecs PCI: 00:15.0 init PCI: 00:15.0 init 830 usecs PCI: 00:15.1 init PCI: 00:15.1 init 830 usecs PCI: 00:18.0 init PCI: 00:18.0 init 830 usecs PCI: 00:18.1 init PCI: 00:18.1 init 830 usecs PCI: 00:18.2 init PCI: 00:18.2 init 830 usecs PCI: 00:18.3 init PCI: 00:18.3 init 830 usecs PCI: 00:18.4 init PCI: 00:18.4 init 830 usecs PCI: 00:18.5 init PCI: 00:18.5 init 830 usecs PNP: 002e.1 init PNP: 002e.1 init 786 usecs PNP: 002e.4 init ITE IT8728F Super I/O HWM: Initializing Hardware Monitor.. ITE IT8728F Super I/O HWM: Base Address at 0x295 PNP: 002e.4 init 5574 usecs PNP: 002e.5 init Keyboard init... No PS/2 keyboard detected. PNP: 002e.5 init 143934 usecs PNP: 002e.7 init PNP: 002e.7 init 787 usecs PCI: 03:00.0 init PCI: 03:00.0 init 830 usecs Devices initialized Show all devs...After init. Root Device: enabled 1 CPU_CLUSTER: 0: enabled 1 APIC: 10: enabled 1 DOMAIN: 0000: enabled 1 PCI: 00:00.0: enabled 1 PCI: 00:01.0: enabled 1 PCI: 00:01.1: enabled 1 PCI: 00:02.0: enabled 0 PCI: 00:03.0: enabled 0 PCI: 00:04.0: enabled 0 PCI: 00:05.0: enabled 0 PCI: 00:06.0: enabled 0 PCI: 00:07.0: enabled 0 PCI: 00:08.0: enabled 0 PCI: 00:10.0: enabled 1 PCI: 00:10.1: enabled 1 PCI: 00:11.0: enabled 1 PCI: 00:12.0: enabled 1 PCI: 00:12.2: enabled 1 PCI: 00:13.0: enabled 1 PCI: 00:13.2: enabled 1 PCI: 00:14.0: enabled 1 I2C: 01:50: enabled 1 I2C: 01:51: enabled 1 PCI: 00:14.1: enabled 0 PCI: 00:14.2: enabled 1 PCI: 00:14.3: enabled 1 PNP: 002e.0: enabled 0 PNP: 002e.1: enabled 1 PNP: 002e.2: enabled 0 PNP: 002e.3: enabled 0 PNP: 002e.4: enabled 1 PNP: 002e.5: enabled 1 PNP: 002e.6: enabled 0 PNP: 002e.7: enabled 1 PNP: 002e.a: enabled 0 PCI: 00:14.4: enabled 1 PCI: 00:14.5: enabled 1 PCI: 00:14.6: enabled 0 PCI: 00:14.7: enabled 1 PCI: 00:15.0: enabled 1 PCI: 00:15.1: enabled 1 PCI: 00:15.2: enabled 0 PCI: 00:15.3: enabled 0 PCI: 00:18.0: enabled 1 PCI: 00:18.1: enabled 1 PCI: 00:18.2: enabled 1 PCI: 00:18.3: enabled 1 PCI: 00:18.4: enabled 1 PCI: 00:18.5: enabled 1 APIC: 11: enabled 1 APIC: 12: enabled 1 APIC: 13: enabled 1 PCI: 03:00.0: enabled 1 BS: BS_DEV_INIT times (us): entry 0 run 569533 exit 0 CBMEM region bf120000-bfffffff (cbmem_check_toc) CBMEM region bf120000-bfffffff (cbmem_initialize_empty) Adding CBMEM entry as no. 1 Moving GDT to bf120200...ok Adding CBMEM entry as no. 2 Finalize devices... Devices finalized Adding CBMEM entry as no. 3 DmiTable:0, AcpiPstatein: 10010126, AcpiSrat:0,AcpiSlit:0, Mce:100111ba, Cmc:1001127c,Alib:10011336, AcpiIvrs:0 in agesawrapper_amdinitlate NvStorageSize=383, NvStorage=1001ccd4 SF: Detected MX25L3205D with page size 1000, total 400000 SF: Successfully erased 4096 bytes @ 0xffff7000 VolatileStorageSize=5a26, VolatileStorage=1001d057 SF: Detected MX25L3205D with page size 1000, total 400000 SF: Successfully erased 24576 bytes @ 0xffff0000 SF: Detected MX25L3205D with page size 1000, total 400000 SF: Successfully erased 4096 bytes @ 0xffff6000 BS: BS_POST_DEVICE times (us): entry 8449 run 3009 exit 3334098 BS: BS_OS_RESUME_CHECK times (us): entry 0 run 0 exit 0 Writing IRQ routing tables to 0xf0000...write_pirq_routing_table done. Adding CBMEM entry as no. 4 Writing IRQ routing tables to 0xbf130600...write_pirq_routing_table done. PIRQ table: 48 bytes. Wrote the mp table end at: 000f0410 - 000f061c Adding CBMEM entry as no. 5 Wrote the mp table end at: bf131610 - bf13181c MP table: 540 bytes. Adding CBMEM entry as no. 6 ACPI: Writing ACPI tables at bf132600... ACPI: * DSDT at bf1326c8 ACPI: * DSDT @ bf1326c8 Length 187c ACPI: * FACS at bf133f48 ACPI: * FADT at bf133f88 pm_base: 0x0800 ACPI: added table 1/32, length now 40 ACPI: * HPET at bf134080 ACPI: added table 2/32, length now 44 ACPI: * MADT at bf1340b8 ACPI: added table 3/32, length now 48 ACPI: added table 4/32, length now 52 ACPI: * IVRS at bf134300 AGESA IVRS table NULL. Skipping. ACPI: * SRAT at bf134300 AGESA SRAT table NULL. Skipping. ACPI: * SLIT at bf134300 AGESA SLIT table NULL. Skipping. ACPI: * AGESA ALIB SSDT at bf134300 ACPI: added table 5/32, length now 56 ACPI: * SSDT at bf134820 ACPI: added table 6/32, length now 60 ACPI: * SSDT for PState at bf135560 ACPI: * SSDT ACPI: added table 7/32, length now 64 ACPI: done. ACPI tables: 12197 bytes. Adding CBMEM entry as no. 7 smbios_write_tables: bf13da00 Root Device (ASUS F2A85-M) CPU_CLUSTER: 0 (AMD FAM15 Root Complex) APIC: 10 (AMD CPU Family 15h) DOMAIN: 0000 (AMD FAM15 Root Complex) PCI: 00:00.0 (AMD FAM15 Northbridge) PCI: 00:01.0 (AMD FAM15 Northbridge) PCI: 00:01.1 (AMD FAM15 Northbridge) PCI: 00:02.0 (AMD FAM15 Northbridge) PCI: 00:03.0 (AMD FAM15 Northbridge) PCI: 00:04.0 (AMD FAM15 Northbridge) PCI: 00:05.0 (AMD FAM15 Northbridge) PCI: 00:06.0 (AMD FAM15 Northbridge) PCI: 00:07.0 (AMD FAM15 Northbridge) PCI: 00:08.0 (AMD FAM15 Northbridge) PCI: 00:10.0 (ATI HUDSON) PCI: 00:10.1 (ATI HUDSON) PCI: 00:11.0 (ATI HUDSON) PCI: 00:12.0 (ATI HUDSON) PCI: 00:12.2 (ATI HUDSON) PCI: 00:13.0 (ATI HUDSON) PCI: 00:13.2 (ATI HUDSON) PCI: 00:14.0 (ATI HUDSON) I2C: 01:50 (unknown) I2C: 01:51 (unknown) PCI: 00:14.1 (ATI HUDSON) PCI: 00:14.2 (ATI HUDSON) PCI: 00:14.3 (ATI HUDSON) PNP: 002e.0 (ITE IT8728F Super I/O) PNP: 002e.1 (ITE IT8728F Super I/O) PNP: 002e.2 (ITE IT8728F Super I/O) PNP: 002e.3 (ITE IT8728F Super I/O) PNP: 002e.4 (ITE IT8728F Super I/O) PNP: 002e.5 (ITE IT8728F Super I/O) PNP: 002e.6 (ITE IT8728F Super I/O) PNP: 002e.7 (ITE IT8728F Super I/O) PNP: 002e.a (ITE IT8728F Super I/O) PCI: 00:14.4 (ATI HUDSON) PCI: 00:14.5 (ATI HUDSON) PCI: 00:14.6 (ATI HUDSON) PCI: 00:14.7 (ATI HUDSON) PCI: 00:15.0 (ATI HUDSON) PCI: 00:15.1 (ATI HUDSON) PCI: 00:15.2 (ATI HUDSON) PCI: 00:15.3 (ATI HUDSON) PCI: 00:18.0 (AMD FAM15 Northbridge) PCI: 00:18.1 (AMD FAM15 Northbridge) PCI: 00:18.2 (AMD FAM15 Northbridge) PCI: 00:18.3 (AMD FAM15 Northbridge) PCI: 00:18.4 (AMD FAM15 Northbridge) PCI: 00:18.5 (AMD FAM15 Northbridge) APIC: 11 (unknown) APIC: 12 (unknown) APIC: 13 (unknown) PCI: 03:00.0 (unknown) SMBIOS tables: 336 bytes. Adding CBMEM entry as no. 8 Adding CBMEM entry as no. 9 Adding CBMEM entry as no. 10 Writing table forward entry at 0x00000500 Wrote coreboot table at: 00000500, 0x10 bytes, checksum 4de0 Table forward entry ends at 0x00000528. ... aligned to 0x00001000 Writing coreboot table at 0xbffdf200 rom_table_end = 0xbffdf200 ... aligned to 0xbffe0000 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000c0000-00000000bf11ffff: RAM 3. 00000000bf120000-00000000bfffffff: CONFIGURATION TABLES 4. 00000000c0000000-00000000dfffffff: RESERVED 5. 00000000f8000000-00000000fbffffff: RESERVED 6. 0000000100000000-000000021effffff: RAM Wrote coreboot table at: bffdf200, 0x180 bytes, checksum ddcd coreboot table: 408 bytes. FREE SPACE 0. bffe7200 00018e00 GDT 1. bf120200 00000200 CONSOLE 2. bf120400 00010000 TIME STAMP 3. bf130400 00000200 IRQ TABLE 4. bf130600 00001000 SMP TABLE 5. bf131600 00001000 ACPI 6. bf132600 0000b400 SMBIOS 7. bf13da00 00000800 ACPI RESUME 8. bf13e200 00e00000 ACPISCRATCH 9. bff3e200 000a1000 COREBOOT 10. bffdf200 00008000 BS: BS_WRITE_TABLES times (us): entry 0 run 184018 exit 0 CBFS: located payload @ ffc107b8, 56957 bytes. Loading segment from rom address 0xffc107b8 code (compression=1) New segment dstaddr 0xe4abc memsize 0x1b544 srcaddr 0xffc107f0 filesize 0xde45 (cleaned up) New segment addr 0xe4abc size 0x1b544 offset 0xffc107f0 filesize 0xde45 Loading segment from rom address 0xffc107d4 Entry Point 0x000fd076 Bounce Buffer at bee11000, 3203168 bytes Loading Segment: addr: 0x00000000000e4abc memsz: 0x000000000001b544 filesz: 0x000000000000de45 lb: [0x0000000000200000, 0x0000000000387030) Post relocation: addr: 0x00000000000e4abc memsz: 0x000000000001b544 filesz: 0x000000000000de45 using LZMA [ 0x000e4abc, 00100000, 0x00100000) <- ffc107f0 dest 000e4abc, end 00100000, bouncebuffer bee11000 Loaded segments BS: BS_PAYLOAD_LOAD times (us): entry 0 run 44794 exit 0 Jumping to boot code at 000fd076 CPU0: stack: 002c6000 - 002c7000, lowest used address 002c65e0, stack used: 2592 bytes entry = 0x000fd076 lb_start = 0x00200000 lb_size = 0x00187030 buffer = 0xbee11000

1 0

Re: [coreboot] Request for Intel Haswell info
by David Hendricks 03 Jul '14

03 Jul '14

[+jiming.sun(a)intel.com] On Wed, Jul 2, 2014 at 5:58 PM, Paul Wilcox-Baker <wilcoxbaker(a)gmail.com> wrote: > Dear coreboot, > > We have done some more research on the differences between the > supported Haswell processors and PCH parts and what we have > used in our design. > > We have designed a board with the E3-1268Lv3 device with the > 82C226 PCH part. It appears that all Haswell devices that > have been ported are the mobile variety where the PCH device is > packaged with the processor. > > Do the files to support the parts we wish to use exist anywhere > else? Is there a repository for non-GPL code perhaps? > > Can we use any of the coreboot utilities on a system with the > same processor and PCH device to generate code for a coreboot > that will support this CPU and PCH? > > Does Intel have the required files to generate coreboot for the > processor and PCH part that we wish to use? If they do how do > we get them? Perhaps they have some coreboot code that can be > obtained under NDA or licence. > > Thanks, Paul. > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Request for Intel Haswell info
by Paul Wilcox-Baker 03 Jul '14

03 Jul '14

Dear coreboot, We have done some more research on the differences between the supported Haswell processors and PCH parts and what we have used in our design. We have designed a board with the E3-1268Lv3 device with the 82C226 PCH part. It appears that all Haswell devices that have been ported are the mobile variety where the PCH device is packaged with the processor. Do the files to support the parts we wish to use exist anywhere else? Is there a repository for non-GPL code perhaps? Can we use any of the coreboot utilities on a system with the same processor and PCH device to generate code for a coreboot that will support this CPU and PCH? Does Intel have the required files to generate coreboot for the processor and PCH part that we wish to use? If they do how do we get them? Perhaps they have some coreboot code that can be obtained under NDA or licence. Thanks, Paul.

1 0

Delivery problems with some messages since a week
by Paul Menzel 02 Jul '14

02 Jul '14

Dear coreboot folks, since a week *some* of the messages from the list, like [1], are not delivered to me. Does somebody also experience such problems? On the SeaBIOS list, this happened for at least one message [2]. Logging into Mailman’s Web interface [1] there is no information about any bounces and delivery is enabled (otherwise I wouldn’t get any at all I guess). Thanks, Paul [1] http://www.coreboot.org/pipermail/coreboot/2014-June/078191.html [2] http://www.seabios.org/pipermail/seabios/2014-June/008158.html [3] http://www.coreboot.org/mailman/options/coreboot/

1 0

Re: [coreboot] Success in replicating a fast boot time to the browser on a x60
by Patrick Georgi 02 Jul '14

02 Jul '14

Am 02.07.2014 16:23, schrieb Charles Devereaux: > I use linux-3.10.45 and systemd-stable v210, and you can see the result > from a systemd-analyze - about 2.8 seconds after coreboot+grub, which > take about 3 seconds. An extension to this project would be to teach linux/systemd to read our timestamps from cbmem for a full breakdown. Patrick

2 1

Re: [coreboot] Request for Intel Haswell info
by Matt DeVillier 02 Jul '14

02 Jul '14

While a couple of the Haswell-based ChromeBooks have been added to upstream coreboot, but have not heard of anyone with them actually running yet. I know John Lewis had tried to get the HP ChromeBook 14 (falco) going but was not successful (though he does have the Chromium/falco branch working), and I assume the same is true for the Acer C720 (peppy) too, as they are nearly identical. Looking at it briefly, I'd suspect the issues are related to the display init or Google's EC, but haven't had a chance to play with one myself yet. I have upstream coreboot running on the Haswell-based Asus ChromeBox (panther), and have submitted patches for it, but they have not yet been accepted/merged in. Also works for the nearly-identical HP ChromeBox (zako). I can throw my branch up on github in the meantime if would be useful, but that's where I'd recommend starting (vs the ChromeBooks). cheers, Matt On 7/2/2014 11:09 AM, ron minnich wrote: > As always, when doing a new board, get a system that is known to work with coreboot and has your chipset in it. You should get several (never just one!) of the haswell chromebooks, build coreboot, make sure you can make it all work, then try the port to your board. > > ron > > > On Wed, Jul 2, 2014 at 12:11 AM, David Hendricks <david.hendricks(a)gmail.com <mailto:david.hendricks@gmail.com>> wrote: > > On Tue, Jul 1, 2014 at 5:50 PM, Paul Wilcox-Baker <wilcoxbaker(a)gmail.com <mailto:wilcoxbaker@gmail.com>> wrote: > > Dear coreboot, > > We are interested in coreboot for the Intel Haswell processors. > coreboot appears to be used in the Acer C720 and HP Chromebooks > that use Haswell processors. I see no reference to this processor, > or to these products in the source code that I downloaded recently. > > > Are you sure? 'git grep haswell' turns up 160 references as of 931c1d. > > > There is also no reference to these products in the "products > supported" web page of coreboot.org <http://coreboot.org>. > > > http://www.coreboot.org/Supported_Motherboards#Laptops > > > We are developing hardware using the Haswell processor and 82C226 > PCH part. How do we port coreboot to these devices? As Acer and HP > have done it, it's obviously possible. > > > Start by grepping for NORTHBRIDGE_INTEL_HASWELL in the source tree. > > Note: The following URL has a codename <--> marketing name decoder for Chromebooks: http://www.chromium.org/chromium-os/developer-information-for-chrome-os-dev… > > Any advice gratefully received! > > Thanks, Paul. > > -- > coreboot mailing list: coreboot(a)coreboot.org <mailto:coreboot@coreboot.org> > http://www.coreboot.org/mailman/listinfo/coreboot > > > > -- > coreboot mailing list: coreboot(a)coreboot.org <mailto:coreboot@coreboot.org> > http://www.coreboot.org/mailman/listinfo/coreboot > > > >

2 1

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot July 2014