Re: [coreboot] Request for Intel Haswell info
[+jiming@intel.com] On Wed, Jul 2, 2014 at 5:58 PM, Paul Wilcox-Baker wilcoxba...@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@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Re : Re: coreboot hackaton/meeting in Prague - september 2014 - date shift?
Hi Rudolf, Thank you for organizing this new hackaton and you can count me for shure among the attendees. As for the dates it doesnt matter for me.. Best regards, Florentin - Mail d'origine - De: Rudolf Marek r.ma...@assembler.cz À: ron minnich rminn...@gmail.com, David Hendricks dhend...@google.com Cc: Martin Roth martin.r...@se-eng.com, Paul Menzel paulepan...@users.sourceforge.net, Coreboot coreboot@coreboot.org Envoyé: Tue, 01 Jul 2014 08:04:38 +0200 (CEST) Objet: Re: [coreboot] coreboot hackaton/meeting in Prague - september 2014 - date shift? Hi all, What about 16 17 18 19 of October then? It is already in the university semester so there could be trouble with dormitory accommodation, but I think no trouble with some room @university. I would like to shift the date only once, if there is anyone with objections (especially those which are on the doodle list) please speak up. Thanks Rudolf -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] F2A85-M: Chassis Fan Not Working
2014-06-28 17:59 GMT+02:00 HacKurx hack...@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 = 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=0x1000, code_size=0x0031 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 03, Code Type 00 Copying VGA ROM Image from ffc00778 to 0xc, 0xfa00 bytes Real mode stub @0600: 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
Re: [coreboot] Request for Intel Haswell info
it's possible. i've worked on haswell cpu e3 series and c226 and booted win7 and linux OS. you should get rc code from intel under NDA first，then make mrc.bin，port some pch rc code（sata，pcie，usb，etc）. then it could boot. i use the basking ridge CRB code. and i got some help from aaron on this porting. roger 在 2014年7月3日，下午3:04，David Hendricks david.hendri...@gmail.com 写道： [+jiming@intel.com] On Wed, Jul 2, 2014 at 5:58 PM, Paul Wilcox-Baker wilcoxba...@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@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Request for Intel Haswell info
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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] board_status: Add serial log to `serial_console.txt`
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. Thoughts? On Wed, Feb 19, 2014 at 3:14 PM, Kyösti Mälkki kyosti.mal...@gmail.com wrote: On 02/20/2014 12:56 AM, Vladimir 'φ-coder/phcoder' Serbinenko wrote: You do not get raminit debug output printed in ramstage. Unfortunately, the case of incompatible DIMMs seems to be common one with recent AGESA ports so information from romstage what DIMMs have worked is actually relevant. Just read this data from registers and print it. Neither of us has probably looked closely what details we are missing from AGESA romstages. I very much doubt it would be just static register configuration on memory controllers that could be dumped afterwards. AMD has an amount of SMP init going on in romstage along with possibly multiple logical CPUs using CAR etc. -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] source of coreboot boot log for board-status database
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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] source of coreboot boot log for board-status database
I think it's fine. The more info we have on a given board the better, and the boot log seems to be of value to people, so why not? ron On Thu, Jul 3, 2014 at 7:30 PM, Martin Roth martin.r...@se-eng.com wrote: 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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] board_status: Add serial log to `serial_console.txt`
On Thu, Jul 3, 2014 at 4:18 PM, David Hendricks dhend...@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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
