[coreboot] Re: What should we do about freenode IRC services?
On Tue, 25 May 2021 15:08:23 +0200 Jonathan Neuschäfer wrote: > As far as other IRC networks go, OFTC is another popular choice among > those leaving Freenode. > > Matrix sounds good, especially because it can be bridged to an IRC > channel. I'd be sad to see coreboot disappear from IRC entirely, but > I think a combined Matrix/IRC channel is a good way forward. +1 The important thing (for myself anyway) is that the bridge can be part of an existing network. Mattermost supports a bridge directly but you have to connect your irc client to that bridge instead of the bridge joining a channel. I am using that for one project but it's not ideal from my PoV. IIRC there was already another bridge to some MM server that worked differently in the past. What's the status of that, Patrick? I personally am already on libera and OFTC so I don't really care which of those two. AFAICT the vast majority of my channels has moved to libera. Some have not decided yet, and 0 went to OFTC. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
Re: [coreboot] 8 GB DIMMs on Nehalem (Arrandale)
On Sun, 29 Jan 2017 07:15:18 +0100 Zoran Stojsavljevic wrote: > > The current raminit for Nehalem in coreboot is not able to train the two > > 8 GB DIMMs I have tested so far. I have added a debug output to > > choose_reg178 in the first loop before the margins are compared to > > STANDARD_MIN_MARGIN that shows that all margins are 0. > > I would suggest to you to do the following: to return to the platform true > BIOS, and to see if BIOS works with your Arrandale i5-520M (Thinkpad 410). > Then you can try several different DIMM configurations, and see if BIOS > supports up to maximum of 32GB (4 X 8GB DIMM). > > Then, from these BIOS experiments, you can draw obvious conclusions in > relations with Coreboot MRC algorithm. :-) The T410s does have only two slots (NB: T410 is a completely different model with a different casing). The 4-slot system is the W510 with the clarkdale i7 CPU that does not have coreboot support at all. In the T410s the vendor firmware and coreboot work fine with 2x 4GB DIMMs but as soon as there is one 8GB DIMM even if it is the only stick and no matter in which slot it is, things go crazy with the vendor firmware and the raminit code of coreboot stops in the middle as described earlier. So there is nothing obvious left to try regarding DIMM combinations in the T410s. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] 8 GB DIMMs on Nehalem (Arrandale)
On Sat, 28 Jan 2017 17:01:05 +0100 Zoran Stojsavljevic wrote: > Hello Stefan, > > Let me ask you for some other stuff, since I would like to put what I wrote > initially to hold (sleep state, for now). > > You wrote: *The official specs are not trustworthy IMHO and cpuid(1) and > /proc/cpuinfo **show the same physical address width of 36 bits (which > would indicate a **maximum of 64 GB).* > > Question to you: are you dealing with i686 kernel, (32 bit)? It seems to me > that you have Nehalem which complies in IA32 with PAE HW extension, don't > you?! > > This is very important -> *Enabling PAE (by setting bit 5, PAE, of the > system register CR4) causes major changes to this scheme...* > Both CPUs have PAE support, yes, but I think I have never even tried to boot a 32-bit kernel on them :) However, cpuid with an x86_64 kernel shows (assumably via the cpuid op and edx): physical address extensions= true But that does only indicate support not use of PAE... I don't see how this would be relevant to memtest or the 64-bit kernels anyway. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] 8 GB DIMMs on Nehalem (Arrandale)
On Sat, 28 Jan 2017 17:01:09 +0300 Andrey Korolyov wrote: > > The chipset in the (QC version of the) W510 is actually exactly the same as > > in the X201 and T410s: Ibex Peak. > > > > But CPUs we are looking at *are* actually different Of course - I did not bring up chipsets ;) I am also not implying that it should work on Arrandale but I'd like to know why it doesn't and the usual "it doesnt support it" as seen around the internet (and apparently even here) does not cut it :) > - scale-down could > mean an exposure of a previously unaccounted design issue which > actually prevented 32nm CPU 'upgrade' to work reliably with >8G of > RAM... And AFAIR nobody ever reported to break official memory limits > within an entire family, I`ll be happy to know that this is not true. Not sure if I interpret "within an entire family" correctly, but the online specs for the 820QM are clearly wrong: https://ark.intel.com/products/43124/Intel-Core-i7-820QM-Processor-8M-Cache-1_73-GHz The datasheet (320765) is a bit more correct because it leaves room for interpretation: * Using 2-Gb device technologies, the largest memory capacity possible is 8 GB, assuming dual-channel mode with two x8, double-sided, un-buffered, non-ECC, SO-DIMM memory configuration." * Up to 32 simultaneous open pages, 16 per channel (assuming 4 Ranks of 8 Bank Devices) The ICs on my 8 GB DIMMs are 4 Gb (Hynix H5TC4G83BFR and whatever Kingston uses on their KVR16LS11/8 DIMMs but clearly specified as 4 Gb chips). Now... guess what the datasheet of corresponding to the i5-520m (322812) states. Exactly the same as above. I can see some other memory-related differences (e.g., regarding support for 1333 MT/s that's only available on the i7) though but nothing related to memory organization, addressing or the like (but the datasheets are very superficial regarding the memory controller as all corebooters know). So of course the CPUs are not equal and of course the manufacturing process or small changes in the design *could* make the difference but it is all but clear from the public documentation what the true maximum is - at least for me. And I don't yet accept that it is an architectural/digital design problem. > Just to add .02c - DDR3 interposers from tek/futureplus are appearing > on ebay relatively frequently and for moderate price, so if someone > has will to spend some effort on this task, the analyzer coupled with > interposer could provide great help, with regard to unstable behavior > with a single 8G DIMM. Definitely not worth it for this 7+ year old hardware (unless someone has a suitable scope and the knowledge already... the best scope I have access to is an Agilent MSO6104A but no idea where to even start - and no interposer obviously) but you seem to imply that the 8GB problem is an analogous one... do you think about the 16 GB problem as well? -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] 8 GB DIMMs on Nehalem (Arrandale)
On Sun, 22 Jan 2017 12:33:08 +0100 Zoran Stojsavljevic wrote: > Hello Stefan, > > In addition what Charlotte wrote to you, I would advise you the following > (as general approach for mem problems): > [1] Please, for testing the memory, use secondary Coreboot payload called > MEMTEST: > [user@localhost coreboot]$ cat .config | grep MEMTEST > CONFIG_MEMTEST_SECONDARY_PAYLOAD=y > CONFIG_MEMTEST_STABLE=y > # CONFIG_MEMTEST_MASTER is not set > > Instead going to SeaBIOS or GRUB2 as payloads. This memtest86+ could (my > best guess) show to you what is wrong with your memory configuration. > > [2] You can also (since you are able to in some cases go to Linux) stop in > GRUB2, after installing from Linux memtest86+ package into the GRUB2 boot > options (this can also help too, my best guess). > > (extra advise: if you use legacy/CSM ON, which is in Coreboot in 99.999% > cases used, it would be much easier for you to deal with memtest86+) Hi Zoran, I am not exactly sure what you are trying to convey. I mentioned that memtest did lock up after some seconds with the vendor firmware in my previous mail. Of course it's the first thing to try when memory problems arise - I just tried to boot Linux to retrieve the e820 map because Nico requested it on IRC. I presume that using memtest as primary or secondary payload or booted from GRUB2 would not produce different results (unless the binaries are different of course), no? -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] 8 GB DIMMs on Nehalem (Arrandale)
On Sat, 21 Jan 2017 18:46:00 -0500 Charlotte Plusplus wrote: > Addressing over 8G is not supported by the chipset used on nehalem thinkpad > laptops (X201) > > Stupid limitation, but it is not the CPU fault. Please don't spread FUD if you don't know what you are talking about. Neither the RAM in the T410s nor the one in the X201 is even connected to what remains of the "chipset" i.e. the southbridge in form of the PCH/southbridge but directly to the memory controller in the CPU. The chipset in the (QC version of the) W510 is actually exactly the same as in the X201 and T410s: Ibex Peak. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] 8 GB DIMMs on Nehalem (Arrandale)
Hi Vladimir, since you have REed the raminit for Nehalem I'd like you to ask if you have any knowledge, information or pointers about using 8 GB DIMMs with it or even using more than 8 GB in total. In my case it is about an Arrandale i5-520M (in a Thinkpad 410s). I know that an i7-820QM (Clarksfield) is perfectly capable of working with 8 GB DIMMs and probably up to 32 GB or even more (the Thinkpad W510 has 4 DIMM slots and I have tested it with 20 GB) and that is from around the same time as the Arrendale chips - which does not mean anything but I still refuse to accept that Nehalem is that limited. The official specs are not trustworthy IMHO and cpuid(1) and /proc/cpuinfo show the same physical address width of 36 bits (which would indicate a maximum of 64 GB). The current raminit for Nehalem in coreboot is not able to train the two 8 GB DIMMs I have tested so far. I have added a debug output to choose_reg178 in the first loop before the margins are compared to STANDARD_MIN_MARGIN that shows that all margins are 0. If there is anything I could try or information I can provide, please let me know. The (ancient) vendor firmware I've been using on the T410s does sometimes manage to boot Linux with an 8 GB DIMM (dmesg is attached including the e820 map), but it is quite broken and memtest86 locks up or reboots within seconds so that's probably not a good target for RE efforts. :) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 4.4.0-57-generic (buildd@lgw01-54) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) ) #78-Ubuntu SMP Fri Dec 9 23:50:32 UTC 2016 (Ubuntu 4.4.0-57.78-generic 4.4.35) [0.00] Command line: BOOT_IMAGE=/vmlinuz-4.4.0-57-generic root=/dev/mapper/vg-root ro recovery nomodeset [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] AMD AuthenticAMD [0.00] Centaur CentaurHauls [0.00] x86/fpu: Legacy x87 FPU detected. [0.00] x86/fpu: Using 'lazy' FPU context switches. [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009e7ff] usable [0.00] BIOS-e820: [mem 0x0009e800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000d2000-0x000d3fff] reserved [0.00] BIOS-e820: [mem 0x000dc000-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xbb27bfff] usable [0.00] BIOS-e820: [mem 0xbb27c000-0xbb281fff] reserved [0.00] BIOS-e820: [mem 0xbb282000-0xbb35efff] usable [0.00] BIOS-e820: [mem 0xbb35f000-0xbb370fff] reserved [0.00] BIOS-e820: [mem 0xbb371000-0xbb3f1fff] ACPI NVS [0.00] BIOS-e820: [mem 0xbb3f2000-0xbb40efff] reserved [0.00] BIOS-e820: [mem 0xbb40f000-0xbb46efff] usable [0.00] BIOS-e820: [mem 0xbb46f000-0xbb667fff] reserved [0.00] BIOS-e820: [mem 0xbb668000-0xbb6e7fff] ACPI NVS [0.00] BIOS-e820: [mem 0xbb6e8000-0xbb70efff] reserved [0.00] BIOS-e820: [mem 0xbb70f000-0xbb716fff] usable [0.00] BIOS-e820: [mem 0xbb717000-0xbb71efff] reserved [0.00] BIOS-e820: [mem 0xbb71f000-0xbb76afff] usable [0.00] BIOS-e820: [mem 0xbb76b000-0xbb776fff] ACPI NVS [0.00] BIOS-e820: [mem 0xbb777000-0xbb779fff] ACPI data [0.00] BIOS-e820: [mem 0xbb77a000-0xbb780fff] ACPI NVS [0.00] BIOS-e820: [mem 0xbb781000-0xbb781fff] ACPI data [0.00] BIOS-e820: [mem 0xbb782000-0xbb78afff] ACPI NVS [0.00] BIOS-e820: [mem 0xbb78b000-0xbb78bfff] ACPI data [0.00] BIOS-e820: [mem 0xbb78c000-0xbb79efff] ACPI NVS [0.00] BIOS-e820: [mem 0xbb79f000-0xbb7fefff] ACPI data [0.00] BIOS-e820: [mem 0xbb7ff000-0xbb7f] usable [0.00] BIOS-e820: [mem 0xbb80-0xbfff] reserved [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved [0.00] BIOS-e820: [mem 0xfeaff000-0xfeaf] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec0] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed003ff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed8] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0
[coreboot] Lenovo T410s
ACPI Error: Method parse/execution failed [\_PR.CP01._PPC] (Node 88012f4ad690), AE_NOT_FOUND (20150930/psparse-542) [ 239.611212] ACPI Error: [NVSA] Namespace lookup failure, AE_NOT_FOUND (20150930/psargs-359) [ 239.611217] ACPI Error: Method parse/execution failed [\_PR.CP01._TPC] (Node 88012f4ad758), AE_NOT_FOUND (20150930/psparse-542) [ 239.611250] cache: parent cpu1 should not be sleeping [ 239.611415] ACPI Error: [NVSA] Namespace lookup failure, AE_NOT_FOUND (20150930/psargs-359) [ 239.611419] ACPI Error: Method parse/execution failed [\_PR.CP01._PPC] (Node 88012f4ad690), AE_NOT_FOUND (20150930/psparse-542) [ 239.611440] CPU1 is up [ 239.628643] smpboot: Booting Node 0 Processor 2 APIC 0x4 [ 239.631102] ACPI Error: [NVSA] Namespace lookup failure, AE_NOT_FOUND (20150930/psargs-359) [ 239.631109] ACPI Error: Method parse/execution failed [\_PR.CP02._PPC] (Node 88012f4ad7f8), AE_NOT_FOUND (20150930/psparse-542) [ 239.631159] ACPI Error: [NVSA] Namespace lookup failure, AE_NOT_FOUND (20150930/psargs-359) [ 239.631164] ACPI Error: Method parse/execution failed [\_PR.CP02._TPC] (Node 88012f4ad8c0), AE_NOT_FOUND (20150930/psparse-542) [ 239.631199] cache: parent cpu2 should not be sleeping [ 239.631365] ACPI Error: [NVSA] Namespace lookup failure, AE_NOT_FOUND (20150930/psargs-359) [ 239.631369] ACPI Error: Method parse/execution failed [\_PR.CP02._PPC] (Node 88012f4ad7f8), AE_NOT_FOUND (20150930/psparse-542) [ 239.631390] CPU2 is up [ 239.648678] smpboot: Booting Node 0 Processor 3 APIC 0x5 [ 239.651193] ACPI Error: [NVSA] Namespace lookup failure, AE_NOT_FOUND (20150930/psargs-359) [ 239.651201] ACPI Error: Method parse/execution failed [\_PR.CP03._PPC] (Node 88012f4ad960), AE_NOT_FOUND (20150930/psparse-542) [ 239.651248] ACPI Error: [NVSA] Namespace lookup failure, AE_NOT_FOUND (20150930/psargs-359) [ 239.651252] ACPI Error: Method parse/execution failed [\_PR.CP03._TPC] (Node 88012f4ada28), AE_NOT_FOUND (20150930/psparse-542) [ 239.651285] cache: parent cpu3 should not be sleeping [ 239.651445] ACPI Error: [NVSA] Namespace lookup failure, AE_NOT_FOUND (20150930/psargs-359) [ 239.651449] ACPI Error: Method parse/execution failed [\_PR.CP03._PPC] (Node 88012f4ad960), AE_NOT_FOUND (20150930/psparse-542) [ 239.651471] CPU3 is up [ 239.653717] ACPI: Waking up from system sleep state S3 I tried to figure at least the latter out but couldn't. AFAICT the port uses cpu/intel/model_206ax/acpi/cpu.asl similar to other board from its era (although it hosts CPUs from the previous model_20656 generation). Another thing that I would like to add is support for 8 GB DIMMs (and thus 16 GB of total RAM) which I think should theoretically work on this hardware. I have tested an 8 GB DIMM in a W510 (with a Clarksfield i7-820QM CPU and four DIMM slots) with its vendor firmware and it's working fine there. My T410s has an Arrandale i5-520. cpuid and /proc/cpuinfo reports a maximum physical address bits of 0x24 (36) on both systems (indicating a maximum RAM of 64 GB AFAICT). The DIMM in question does not work with the Lenovo firmware in the T410s and fails during memory training with coreboot. Is this futile and simply not supported on this hardware? Why and how to tell? -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] Explicitly use C89 (was: Setting C99 by default)
On Tue, 29 Nov 2016 09:09:48 +0100 Gerd Hoffmann wrote: > On Di, 2016-11-29 at 00:41 +0100, Stefan Tauner wrote: > > Paul can you please - without looking it up - name two new features of > > C99 compared to C89? > > Named initializers. > That alone is reason enough to prefer c99 over c89 IMHO. You are not Paul. I was asking him specifically because I don't think that he could name them but still tries to argue about such things although he is not proficient enough to evaluate the implications of such decisions (and I can't stand that at all). Even with good intentions this is a dangerous approach on improving code quality and needs to be countered. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] Explicitly use C89 (was: Setting C99 by default)
Paul can you please - without looking it up - name two new features of C99 compared to C89? -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] 16GB dimm on Sandy/Ivy Bridge status
On Tue, 31 May 2016 07:07:46 +0200 Patrick Rudolph wrote: > Hi Iru, > From T420 manual [1]: > "Memory: Up to 8GB DDR3 - 1333MHz (2 DIMM Slots)" > > While it seems possible to use 16GB (2x 8GB), it isn't possible to use > 16GB DIMMs. > I haven't tested by myself, but it seems like a hardware limitation. > Please provide raminit logs, just to make sure. > Hi, it is often not but the manuals are just reflecting what the vendor has tested. Very often these test are not extended once bigger DIMMS become available hence the documentation is not reliable at all. The only hardware limitation I am aware of that could interfere is what the northbridge supports... http://ark.intel.com/products/52229/Intel-Core-i5-2520M-Processor-3M-Cache-up-to-3_20-GHz So unlike the manual (the "Up to 8 GB" are meant as total) 16 GB is the maximum. The question remains if a single channel can address the whole range but given that it does not make sense economically that point is rather moot anyway. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] autoport segfault on ibexpeak
On Wed, 4 May 2016 19:00:40 -0600 Trammell Hudson wrote: > On Thu, May 05, 2016 at 01:14:28AM +0200, Stefan Tauner wrote: > > Felix suggested that inteltool -a might be the culprit... and I can > > confirm this. However, inteltool has worked without such issues in the > > past on this machine... if nobody beats me to it I'll investigate > > further/bisect when time allows. > > inteltool -a causes a hard lockup on my X1 with Skylake (i7-6600U). > I've been slowly trying to add support for it. I could bisect the issue and it is due to the dumping of the graphics registers (in my case). See also https://review.coreboot.org/14624 https://review.coreboot.org/14627 > > autoport also fails with a null pointer in DetectGPE, due to an > unsupported Southbridge (QM170?). > Yes... I won't touch that for now. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] autoport segfault on ibexpeak
On Thu, 5 May 2016 00:14:36 +0200 Stefan Tauner wrote: > 2) about a dozen or so seconds after running autoport my laptop > completely locks up. Any ideas why this might happen? Felix suggested that inteltool -a might be the culprit... and I can confirm this. However, inteltool has worked without such issues in the past on this machine... if nobody beats me to it I'll investigate further/bisect when time allows. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] autoport segfault on ibexpeak
Hi, since the rebase of the existing t410s patch to current master was non-trivial (for me anyway) so I gave autoport a shot without knowing that it currently does not support ibexpeak (5 series). This became quite obvious from the output... but that's not the main reason why I am writing (although I'd be interested regrading support for earlier chipsets to autoport) but... 1) autoport segfaults on the t410s with vendor bios and that should definitely be fixed IMHO. 2) about a dozen or so seconds after running autoport my laptop completely locks up. Any ideas why this might happen? Stdio/err is log attached. FWIW autoport also wrote the following log files: -rw-r--r-- 1 root root 329204 May 3 23:24 acpidump.log -rw-r--r-- 1 root root 9464 May 3 23:24 codec#0 -rw-r--r-- 1 root root 3598 May 3 23:24 codec#3 -rw-r--r-- 1 root root 3444 May 3 23:24 cpuinfo.log -rw-r--r-- 1 root root 15925 May 3 23:24 dmidecode.log -rw-r--r-- 1 root root 0 May 3 23:24 ectool.log -rw-r--r-- 1 root root 75 May 3 23:24 input_bustypes.log -rw-r--r-- 1 root root 825285 May 3 23:24 inteltool.log -rw-r--r-- 1 root root 1136 May 3 23:24 ioports.log -rw-r--r-- 1 root root 150333 May 3 23:24 lspci.log -rw-r--r-- 1 root root160 May 3 23:24 pin_hwC0D0 -rw-r--r-- 1 root root 48 May 3 23:24 pin_hwC0D3 -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner Unsupported PCI device 8086:0044 Unsupported PCI device 8086:0046 Unsupported PCI device 8086:3b64 Unsupported PCI device 8086:10ea Unsupported PCI device 8086:3b3c Unsupported PCI device 8086:3b57 Unsupported PCI device 8086:3b42 Unsupported PCI device 8086:3b44 Unsupported PCI device 8086:3b48 Unsupported PCI device 8086:3b34 Unsupported PCI device 8086:2448 Unsupported PCI device 8086:3b0f Unsupported PCI device 8086:3b2f Unsupported PCI device 8086:3b30 Unsupported PCI device 8086:3b32 Unknown PCI device 8086:4238, assuming removable Unknown PCI device 1180:e230, assuming removable Unknown PCI device 8086:2c62, assuming removable Unknown PCI device 8086:2d01, assuming removable Unknown PCI device 8086:2d10, assuming removable Unknown PCI device 8086:2d11, assuming removable Unknown PCI device 8086:2d12, assuming removable Unknown PCI device 8086:2d13, assuming removable panic: runtime error: invalid memory address or nil pointer dereference [signal 0xb code=0x1 addr=0x20 pc=0x40ac5e] goroutine 1 [running]: panic(0x54a0e0, 0xc8200100e0) /usr/lib/go-1.6/src/runtime/panic.go:464 +0x3e6 main.LenovoEC(0xc8201555c0, 0x15, 0xc820155620, 0x1b, 0xc8200a368f, 0x6, 0xc8200a36ca, 0xe, 0xc8201573b0, 0x29, ...) util/autoport/ec_lenovo.go:20 +0x1c9e main.ScanRoot(0xc8201555c0, 0x15, 0xc820155620, 0x1b, 0xc8200a368f, 0x6, 0xc8200a36ca, 0xe, 0xc8201573b0, 0x29, ...) util/autoport/root.go:33 +0x6b1 main.main() util/autoport/main.go:727 +0x7fd -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] A talk about coreboot
On Sun, 10 Apr 2016 01:45:03 +0800 Iru Cai wrote: > Hi community, > > I gave a talk about coreboot in my LUG yesterday, and here's my > slides. > > https://bdwm.net/attach/boards/Linux/M.1460223002.A/coreboot-talk.pdf Hi Iru, I'll do a very similar talk in two weeks. Can I please re-use some of your stuff under a CC BY-SA license? https://creativecommons.org/licenses/by-sa/4.0/ -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] VT-d on samus proposal draft
On Wed, 23 Mar 2016 01:58:59 -0700 Huimin Zhang wrote: > I have my first draft for my GSoC proposal ready. I am quite anxious for a > bit of feedback, as I have yet to receive any so far. The link is below. > > https://docs.google.com/document/d/1R3FCSGfsmwYGU1WmeiGjafrArWN-H9n7IzBtCtMQOVo/edit?usp=sharing Hello Min, I am far from an expert on ACPI but the project you proposed seems to me as it should be doable in a few weeks maximum. Could you please explain why you think this will keep you busy for the whole programming period? What problems do you expect to encounter? -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] FlexICE github (was: Issue with internal access to the W39V040FB)
On Sat, 23 Jan 2016 17:51:27 +0100 Stefan Tauner wrote: > On Sat, 23 Jan 2016 19:32:14 +0300 > Andrey Korolyov wrote: > > > BTW, are there still any FWH-capable romulators in production? Looks > > like most of sockets from this era has been designed without bearing > > in mind possibility of the in-scheme reprogramming, but the only > > romulators I`ve seen on ebay are ancient devices bundled with software > > on floppies... > > You might be interested in https://www.coreboot.org/FlexyICE > I have just discovered that project a few weeks ago myself so I cannot > give much more information than that. It is probably not purchasable > anymore but open enough that one could build something new from that. > Sooner or later I am planning to give a related projected out as > Bachelor or Master thesis but that will take a while (and would > probably be SPI-related). I have freed the two repositories of the project from opencores (they require registration just to download and the registration process is manual!). Currently they reside in the flashrom realm of github: https://github.com/flashrom/artec_dongle_fpga https://github.com/flashrom/artec_dongle_ii_fpga -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ASRock IMB-A180-H (GfxSamuInit)
As can be seen in the board status[1] the current code triggers the respective assertion: ASSERTION FAILED: file 'src/vendorcode/amd/agesa/f16kb/Proc/GNB/Modules/GnbInitKB/GfxSamuInitKB.c', line 165 There exists a related patch[2] in gerrit and it works for me (i.e., my IMB-A180-H boots and graphics still work but the error message is gone). I am unable to quickly determine any consequences... shall we merge it? Why wasn't it yet? 1: http://review.coreboot.org/gitweb?p=board-status.git;a=blob;hb=HEAD;f=asrock/imb-a180/4.0-8877-gf34ea5f/2015-04-06T22:20:13Z/coreboot_console.txt 2: http://review.coreboot.org/#/c/5361/ -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] memtest86 reading 0k memory
On Thu, 19 Feb 2015 10:43:44 -0500 "Kevin O'Connor" wrote: > On Wed, Feb 18, 2015 at 10:26:21PM +0100, Stefan Reinauer wrote: > > * Timothy Pearson [150205 19:23]: > > > e820: BIOS-provided physical RAM map: > > > BIOS-e820: [mem 0x-0x0009fbff] usable > > > BIOS-e820: [mem 0x0009fc00-0x0009] reserved > > > BIOS-e820: [mem 0x000f-0x000f] reserved > > > BIOS-e820: [mem 0x0010-0x3ffacfff] usable > > > BIOS-e820: [mem 0x3ffad000-0x3fff] reserved > > > BIOS-e820: [mem 0xe000-0xefff] reserved > > > > One of the issues seems to be that the coreboot table space is not > > marked as reserved (i.e. the lower 4k should be marked as reserved, and > > whatever is used at the top of memory) > > coreboot tends to reserve the first 4K, but this breaks lots of > bootloaders. So, SeaBIOS always overrides coreboot and unreserves the > first 4K. My experience is that the first one megabyte of the e820 is > just "magical" and should always read as listed above. > > Separately, it is possible for SeaBIOS to remove the coreboot table > forwarder, and thus force memtest86 to not use the coreboot tables. > I'm not sure if this would affect other programs though. I ran into the problem today when trying to verify that the ASRock IMB-A180-H works correctly with coreboot. Is there any consensus on what to do? IMHO this is a bug in SeaBIOS... it creates the discrepancy between the tables and that leads to problems downstream... but that's arguable. What is not arguable: some action is required. :) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ASRock IMB-A180-H
On Mon, 06 Apr 2015 07:22:12 +0300 Kyösti Mälkki wrote: > On Mon, 2015-04-06 at 02:15 +0200, Stefan Tauner wrote: > > Hi, > > > > I am (finally) playing a bit with coreboot. Thanks to the excellent > > work of Kyösti with the BBB I have USB output in place. Unfortunately > > what I see is not what I have hoped for... :) > > > > coreboot-4.0-8859-gbfe1b41 Sun Apr 5 21:29:27 UTC 2015 ramstage starting... > > BS: BS_PRE_DEVICE times (us): entry 0 run 1 exit 0 > > BS: BS_DEV_INIT_CHIPS times (us): entry 0 run 2 exit 0 > > Enumerating buses... > > Mainboard IMB-A180 Enable. > > setup_bsp_ramtop, TOP MEM: msr.lo = 0xe000, msr.hi = 0x > > setup_bsp_ramtop, TOP MEM2: msr.lo = 0x2000, msr.hi = 0x0001 > > setup_uma_memory: uma size 0x2000, memory start 0xc000 > > CPU_CLUSTER: 0 enabled > > DOMAIN: enabled > > memalign(boundary=8, size=96): failed: Tried to round up free_mem_ptr > > 00173190 to 001731f0 > > but free_mem_end_ptr is 0017318c > > > > Same error was actually reported last week on #coreboot. Looks like our > previous crossgcc toolchain with gcc-4.8.3 creates 0-sized heap segment. > > $ grep heap build/cbfs/fallback/ramstage.map 0017318c B _eheap 0017318c B _heap yes, indeed. thanks. http://review.coreboot.org/#/c/9283/19 fixed it for me And with this I got my first coreboot hardware booting, yay. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] ASRock IMB-A180-H
Hi, I am (finally) playing a bit with coreboot. Thanks to the excellent work of Kyösti with the BBB I have USB output in place. Unfortunately what I see is not what I have hoped for... :) coreboot-4.0-8859-gbfe1b41 Sun Apr 5 21:29:27 UTC 2015 ramstage starting... BS: BS_PRE_DEVICE times (us): entry 0 run 1 exit 0 BS: BS_DEV_INIT_CHIPS times (us): entry 0 run 2 exit 0 Enumerating buses... Mainboard IMB-A180 Enable. setup_bsp_ramtop, TOP MEM: msr.lo = 0xe000, msr.hi = 0x setup_bsp_ramtop, TOP MEM2: msr.lo = 0x2000, msr.hi = 0x0001 setup_uma_memory: uma size 0x2000, memory start 0xc000 CPU_CLUSTER: 0 enabled DOMAIN: enabled memalign(boundary=8, size=96): failed: Tried to round up free_mem_ptr 00173190 to 001731f0 but free_mem_end_ptr is 0017318c This is with level DEBUG/7... will recover tomorrow and can increase it if need be. I have not looked into it yet at all... but hints are welcome anyway :) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [flashrom] New flashrom logo - fonts
On Fri, 13 Mar 2015 14:36:35 +0100 Stefan Tauner wrote: > On Fri, 13 Mar 2015 08:37:49 +0100 > Carl-Daniel Hailfinger wrote: > > > On 11.03.2015 14:30, Stefan Tauner wrote: > > > This will be the last poll that evaluates specific features of the > > > logo. There may be another one to determine the final design. > > > > > > I have selected a variety of fonts that I think are OK for a logo in > > > terms of thickness and "playfulness". Not all of them are free but I > > > have included them in the poll anyway to get a better feeling about > > > general preferences. > > > > > > http://epicdecide.com/ad3645e6-9a70-4cce-bd05-bf0e66e668e9/ > > > > This is the first poll where I think that all of the options suck. > > Traditionally, flashrom is written all lowercase and I would love to > > keep it that way. However, the letter "f" in the logos sucks in all > > lowercase variants because of a IMHO way too high lateral stroke. That's > > something I didn't like about the intermediate official logo, by the way. > > > > Does anyone know a font where the lowercase "f" doesn't look like a > > design error? > > Well, that's more than subjective because the stroke is in the upper > third or even quarter in almost all common fonts. And those where it is > lower are usually completely unusable for a logo (extremely squiggly). > > However, I am aware of one font, that might work... I have used it for > a caps lettering already: Chaerilidae > I have attached a lower-case variant with that font. What do you think > about it? > > Other suggestions for fonts are welcome... The other possibility - changing the fs in existing fonts - looks terrible IMHO (at least when I do it). See attachment for 3 attempts. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [flashrom] New flashrom logo - fonts
On Fri, 13 Mar 2015 08:37:49 +0100 Carl-Daniel Hailfinger wrote: > On 11.03.2015 14:30, Stefan Tauner wrote: > > This will be the last poll that evaluates specific features of the > > logo. There may be another one to determine the final design. > > > > I have selected a variety of fonts that I think are OK for a logo in > > terms of thickness and "playfulness". Not all of them are free but I > > have included them in the poll anyway to get a better feeling about > > general preferences. > > > > http://epicdecide.com/ad3645e6-9a70-4cce-bd05-bf0e66e668e9/ > > This is the first poll where I think that all of the options suck. > Traditionally, flashrom is written all lowercase and I would love to > keep it that way. However, the letter "f" in the logos sucks in all > lowercase variants because of a IMHO way too high lateral stroke. That's > something I didn't like about the intermediate official logo, by the way. > > Does anyone know a font where the lowercase "f" doesn't look like a > design error? Well, that's more than subjective because the stroke is in the upper third or even quarter in almost all common fonts. And those where it is lower are usually completely unusable for a logo (extremely squiggly). However, I am aware of one font, that might work... I have used it for a caps lettering already: Chaerilidae I have attached a lower-case variant with that font. What do you think about it? Other suggestions for fonts are welcome... -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [flashrom] New flashrom logo - fonts
This will be the last poll that evaluates specific features of the logo. There may be another one to determine the final design. I have selected a variety of fonts that I think are OK for a logo in terms of thickness and "playfulness". Not all of them are free but I have included them in the poll anyway to get a better feeling about general preferences. http://epicdecide.com/ad3645e6-9a70-4cce-bd05-bf0e66e668e9/ On Sun, 8 Mar 2015 18:07:51 +0100 Stefan Tauner wrote: > Do you know what we haven't done in a long time? A poll! ;) > This time it's all about a few different flash symbols summarized in > the attached image. > > http://epicdecide.com/123fe27d-a4ff-4ab1-9bcd-b5efb267bdd5/ > > > Please consider voting in the first two polls if you have not yet: > > Basic choices: > http://epicdecide.com/bac504d1-0061-46c4-ac7c-9beecaba87e0/ > > Colors: > http://epicdecide.com/3dc56f58-59f9-4921-b048-4cb89b48a09b/ -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [flashrom] New flashrom logo - flashes
Do you know what we haven't done in a long time? A poll! ;) This time it's all about a few different flash symbols summarized in the attached image. http://epicdecide.com/123fe27d-a4ff-4ab1-9bcd-b5efb267bdd5/ Please consider voting in the first two polls if you have not yet: Basic choices: http://epicdecide.com/bac504d1-0061-46c4-ac7c-9beecaba87e0/ Colors: http://epicdecide.com/3dc56f58-59f9-4921-b048-4cb89b48a09b/ -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [flashrom] New flashrom logo - colors
On Thu, 05 Mar 2015 08:58:28 +0100 Carl-Daniel Hailfinger wrote: > On 05.03.2015 02:05, Stefan Tauner wrote: > > Thanks to everyone who has voted on the initial vote! > > Are the results available? Not publicly. Apparently one CAN look at every voter's result so I won't share the link publicly. I have sent it to you yesternight already on IRC. > > Anyway... first I'd like to define the color (scheme) to use. I have > > created another poll, please vote! > > http://epicdecide.com/3dc56f58-59f9-4921-b048-4cb89b48a09b/ > > How much time do we have to vote? I had expected the old vote to stay > active for at least a week. It is still active and I monitor its activity but I don't believe that the outcome will change much anymore. I had wished for more than the mere 18 votes so far but the confidence level of the current results are high enough for me to draw conclusions. This is also true of the second poll on the color scheme. Its result are even more distinct so far. But nothing is set in stone yet and our bikeshedding of the logo will continue... :) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [flashrom] New flashrom logo - colors
Thanks to everyone who has voted on the initial vote! It has helped me a lot already to rule out a number of variations. It also showed clearly that the old logo is not popular at all and that manual kerning is preferred to default letter spaces (I am using the FreeMono font, which is monospaced so this is not too much of a surpise). There are some other variables I'd like you to decide. There was some discussion about the flash outline already so I will create at least two sets of icons for that later. Maybe I'll try different fonts too, but I'd like to use a very common one and I think the FreeMono font suites us well... command line tool etc. Anyway... first I'd like to define the color (scheme) to use. I have created another poll, please vote! http://epicdecide.com/3dc56f58-59f9-4921-b048-4cb89b48a09b/ If we go for one of the yellow schemes, an alternative for the icon would be to make it completely yellow without colored outlines like so: http://buildbot.flashrom.org/poll-colors/yellow_icon.png What do you think? -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [flashrom] New flashrom logo - please vote!
On Mon, 2 Mar 2015 09:03:59 -0800 Vadim Bendebury wrote: > Not that I care much, but I can't help it: this new symbol looks very > much like the infamous SS Bolts: > http://www.adl.org/combating-hate/hate-on-display/c/ss-bolts.html#.VPSXeFX3-iw Yes, it could be mistaken for a sig rune although it clearly differs (the rune is not formed as an arrow on the bottom but is symmetric). I would not use two of this or similar symbols side by side because it could easily be seen as a political statement I definitely don't want to make. But on the other hand there are a lot of other (admittedly less known) runes and symbols used by the SS or other Nazi organizations that we use on a daily basis probably without even knowing it... (e.g. https://en.wikipedia.org/wiki/Runic_insignia_of_the_Schutzstaffel#mediaviewer/File:Tiwaz_rune.svg) So thanks for bringing this up - it is a valid concern - but I draw the line not to cross elsewhere. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [flashrom] New flashrom logo - please vote!
Hi, I have put most of my creations online together with some of the (old) alternatives and created a poll that should help finding the most popular ones. Please vote only once (the site will not try to inhibit multiple votes). http://epicdecide.com/bac504d1-0061-46c4-ac7c-9beecaba87e0/ The images are shown in random order which makes it a bit hard to compare similar ones... just follow your gut feeling or look at them more closely here: http://buildbot.flashrom.org/poll/ You can enter a name at the bottom which I would appreciate. (I can only see the name not how anybody has voted). Any additional comments are very much welcomed! If you think all of them are crap and you have some better ideas I'd like to hear them too :) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [flashrom] New flashrom logo
On Wed, 25 Feb 2015 03:38:01 +0100 Peter Stuge wrote: > Carl-Daniel Hailfinger wrote: > > two logos > > I'd recommend avoiding that. It becomes confusing for people. Not necessarily... the facebook "f" or linkedin "in" are examples where parts of the lettering are reused in icons. Based on that idea I have created a lettering containing the SOIC chip and bolt. I doubt this would produce any confusion :) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New flashrom logo
On Mon, 23 Feb 2015 00:50:46 +0100 Peter Stuge wrote: > I don't get the description but the result is as I meant. I agree > that it is much less recognizable. Worth a shot. Maybe rotate a bit > less. logo with half of the rotation attached (15° instead of 30° backwards). -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New flashrom logo
On Sun, 22 Feb 2015 02:16:57 +0100 Peter Stuge wrote: > either make the > lightning bolt smaller or perhaps just remove it, because the > connection between lightning and memory chips isn't so obvious. Removing it (without replacement) is not an option... that would make it simply a chip icon. That by no means qualifies as a good logo for a software project :) The logo's background idea does not have to be obvious (i.e. if one doesn't know it is related to flashrom, one does not necessarily need to derive that relationship), but it should be recognizable and clear once you know it to make the whole logo<->project relation memorable... and I really think that a flash and a rom/chip qualifies to represent flashrom in such a way :) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New flashrom logo
On Sun, 22 Feb 2015 02:26:19 +0100 Peter Stuge wrote: > Peter Stuge wrote: > > Stefan Tauner wrote: > > > What do you think about my suggestions and the whole matter? > > > > soic8_30degrees is really good. I would only suggest to perhaps > > rotate > > clockwise > > > around the X axis a little bit, > > to view the chip more from the side, rather than from above. I am not sure where your X axis and origin is, but I have rotated it 30° "back" around the Y axis now :) Is that what you meant? That makes the flash look a bit stupid and makes the whole thing way less recognizable IMHO. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New flashrom logo
Hello, we have used two logos in the past for flashrom. The one most are familiar with is actually a generic icon stemming from coreboot's "Related Tools" section, i.e.: http://www.coreboot.org/images/a/ae/Chip_tools.png This is not only set up as the "Mediawiki" icon on flashrom.org but is also used on our Twitter account and other sites like openhub (https://www.openhub.net/p/flashrom) The second logo was specifically designed for this purpose and was used at various occasions in presentation slides and on marketing materials (e.g. posters). Namely http://3.bp.blogspot.com/_PTt3TWYKjnQ/TI_oZ3cqvaI/ALY/eLvM6K16Glw/s400/logo9white.png (the one described as "Different style of bolt" on http://kmacphail.blogspot.de/2010/09/flashrom-logos.html) I think that one is way lesser known since even I was not really aware about the fact that it kind of the "official" logo at the moment. I am not too happy with either. The hammer logo has grown dear to me... the hammer perfectly symbolizes the force we have to exert to get some systems to work and the logo as such is very recognizable. But... I only have it in very low quality... is there a better source for it? It also does not represent our generally gentle and cautious approach when dealing with hardware and our focus on stability. The DIP logo on the other hand is available in SVG (at least Carl-Daniel has it AFAIK), but it looks a bit inanimate. The major problems I have with it are that it is not even nearly rectangular and it is very complex. There is the text with the lightning bolt replacing the h character and the DIP32 chip. Both is ok for posters and other big displays but sucks for other uses where simple, rectangular icons are required. I have spent the last weekend with playing around with Blender and its freestyle renderer that is able to output SVG directly. I have managed to render a 3D model of a SOIC8 chip that way as a base for a possible new logo. It required some cleanup afterwards but it looks way better than everything I could draw by hand ;) I have made two logos that I think are worth sharing. They are quite similar and the only major difference is the orientation of the chip... I have created 3 versions of each: one fully colored, one with outlines only and a two-colored simple version (e.g. for PCB silkscreens). I have attached the Inkscape SVGs as well as 96 pixel-wide PNG exports. I have not decided on an appropriate license... probably something similar to how the coreboot hare is licensed. What do you think about my suggestions and the whole matter? I would love to see proposals for alternatives as well! -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC 2015
On Tue, 10 Feb 2015 10:42:27 +0100 Alexander Couzens wrote: > On Tue, 10 Feb 2015 01:16:26 +0100 > Carl-Daniel Hailfinger wrote: > > > Applications for organizations are open again. The deadline is very > > short this time: Only 10 days! > > > > http://www.google-melange.com/gsoc/homepage/google/gsoc2015 > > Who is doing the application for coreboot? Is something missing? > I would like to attend as student this year ;). So far Marc was managing GSoC (with a lot of help from Patrick). He said that coreboot will be applying again this year, so I think everything is fine at this stage. Do you have a project idea already? -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Release Engineering (again)
On Tue, 10 Feb 2015 19:22:31 +0100 Patrick Georgi wrote: > Hi, > > we had our last big discussion about building coreboot releases in > November. It quickly moved to the topic of removing boards that don't > comply to any kind of metric, and the discussion mostly went down with > that. > > So, since I really like to get a release process up and running TBH I have not followed that discussion very closely, so maybe that's clear for everybody but me... but WHY do we need releases at all? From my perspective it does not make too much sense, the board status thingy is good enough... coordinating people to obey arbitrary deadlines creates some friction that requires some rationale IMHO. I for one would rather read some changelog-like newsletters/blog posts and rely on board status than have some real changelogs + coreboot "versions". So, what advantages do you hope for? -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Plans for upcoming Broadwell Thinkpads
I should probably not post about any Thinkpads till I get to test the T410s port... but anyway has anybody considered a port for the incoming Broadwell Thinkpads - especially the T450s? It would definitely be a plus to know that there will be others hacking at it as well before buying ;) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] How to edit coreboot wiki page
On Tue, 23 Sep 2014 11:40:46 +0800 "WANG Siyuan" wrote: > Hi, all > > I want to edit this page: http://www.coreboot.org/Board:amd/olivehillplus > > But I don't have permission. It seems that I even can't register a user > name. > > > > So how can I get the permission to edit this page? By sending a message to the mailing list asking how you get the permission to edit that page ;) You should have got your login data by email now. If you have any questions regarding the wiki please post them here (or on IRC), thanks. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot hackaton/meeting in Prague - october 2014 - official date set
Hi Rudolf and everybody else preparing for Prague! I'd like to know when everybody will arrive and at which time we get access to the hacking place on Thursday. Also, do you have any specific plans? I'd like to get my t410s ported: http://www.coreboot.org/Board:lenovo/t410s and if Carl-Daniel comes too, discuss/hack on flashrom of course. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Flash access on ASUS F2A85 variants
Hello, I noticed that some F2A85 firmwares apparently block flashrom from accessing the flash correctly as noted here: http://www.coreboot.org/ASUS_F2A85-M#UEFI_builds_that_allow_flash_chip_access I could not find any details but the error message one receives: "ERROR: State of SpiAccessMacRomEn or SpiHostAccessRomEn prohibits full access." If I read the documentation of SpiHostAccessRomEn correctly then it should not bother us at all. It indicates it the ethernet firmware can access the host partition of the flash chip. If however the other bit (SpiAccessMacRomEn) is reset to 0 then we indeed have a problem. Can someone please send me the verbose output of flashrom to confirm which one it is? And I am also looking for testers with these boards, because I think the abort on SpiHostAccessRomEn is a bug in flashrom. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Life hack #37: how to make a great touchpad
Alex, you have missed something very important here: 0: Look at any Chromebook, notice the lack of a trackpoint, facepalm :P -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [flashrom] flashrom-related GSoC 2014 project
Marc Jones has replied to my GSoC proposals but I really dislike having conversations on the GSoC website and because we will probably need to discuss more than just a few corrections, I'll reply here. The first proposal is about the end user tool: http://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/stefant/5870670537818112 Marc commented: > What type of flash or coreboot images would you look at working with? I > think that the chromebook , Intel FSP and AMD systems have a number of > different blob requirements now. Would it be Intel descriptor aware? > What about EFI aware? Thank you for your questions. To be honest, I don't know the answers yet. I hope Patrick finds time to discuss this here with me in the next days/weeks so that I can write a decent specification. In general I want to investigate all possibilities to get a good overview about essential differences in the work flows and formats. That way I can make sure that even if I don't implement them all the code can be extended appropriately later. I know the Intel layout best so far due to my work on the ich_descriptors_tool (which Stepan did not know about when he started ifdtool), and flashrom's Intel support. Unifying ifdtool and ich_descriptors_tool and making it reusable/"libify" it could be one goal of this project. Basically ifdtool supports basic r/w of Intel images while ich_descriptors_tool is r/o but dumps lots of extra information (softstraps stored in the descriptor region mostly). This is not related to the VGABIOS that is (probably?) still stored somewhere in the BIOS region? The ME and GbE regions are separate and can be copied over easily AFAIK (if they are readable that is :) As you know I have an Asrock IMB-A180-H. This would be my main test target (for AMD hardware), but I don't know how the AMD flow(s) are regarding blobs. I guess the IMC and USB blobs, and the VGABIOS are relevant, anything else? For UEFI I would probably rely on https://github.com/NikolajSchlej/UEFITool The author was in #flashrom some while ago but I did not really follow his work. Regarding chromebooks I am not sure how this tool could help much. For normal builds the blobs are fetched directly from the 3rd party blob repository AFAIK? Of course editing a coreboot image afterwards would also be possible just like for all other boards. What about chipset-independent ECs? The second proposal is about general flashrom improvements: http://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/stefant/5805043437535232 Marc had mentioned that he does not like the title before the final proposal was made, and I have only changed it a little since then... > Thanks for this second proposal. I think that a number of these changes > would be very useful, but the project title leaves something to be > desired. If accepted, I wouldn't want that to be the title Google used > when they published the project list. I do understand that although it sums up the content very well ;) In its current state it is just a bunch of project ideas without anything standing out, which makes finding a good title a bit hard. Would something boring like "Flashrom enhancements" be ok or do you have a better idea? But apart from the title... I can of course only work on one of the proposals, so I would like to know before further discussions if this one even has a chance of getting selected/what the basic view of the mentors is regarding my projects. Maybe we can save everyone a bit of time by focussing on only one of the two. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On Sun, 23 Mar 2014 03:56:35 -0600 David Hubbard wrote: > Stefan appears to be missing in action. No, well, he has stated that he want to wait till everybody has calmed down (on IRC). It looks to me that he may have to wait indefinitely though, and I would also like to see some reaction from him to the harsh opinions given. I can't comment on the substance of the proposal, but the reactions from the (for me) most diligent and competent community members tells me that something in it or how it was presented is clearly flawed. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC-2014 Coreboot project
On Fri, 21 Mar 2014 23:23:51 +0800 Allen Yan wrote: > Hi, everyone, >I've sent a preliminary proposal about "Tianocore as coreboot payload". > https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/jinyiyan/5629499534213120 > I'd like to get more feedback about the goal and the test environment. Does not seem to be public. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [announce] coreboot for the 21st century
On Thu, 20 Mar 2014 22:33:21 +0100 Stefan Reinauer wrote: > dmp/vortex86ex What's exactly wrong with that one? DMP ported their SoC themselves less than half a year ago, and I seriously doubt that dropping that already would be a good marketing move for coreboot at all. :) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [flashrom] flashrom-related GSoC 2014 project
Hello again, since I only got feedback (on IRC) regarding the "end user tool" idea and my preliminary "generic flashrom improvements" proposal, I will try to formulate full proposals for these two projects and we (you) can decide later which one is preferable. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] ARM Linux kernel payload (was: GSoC-2014 Coreboot project)
On Wed, 19 Mar 2014 16:01:05 +0100 Peter Stuge wrote: > > I'd like somebody to look at doing LinuxBIOS again, i.e. getting us back to > > the point where we can embed linux in the flash as the payload. Patrick got > > us a long way back toward getting that working, and it'd be nice to see it > > finished. > > I've tested it - it works well at least in QEMU. > > A solution is still needed for ARM though. What are the problems there/what needs to be done? -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] flashrom-related GSoC 2014 project
Hi everyone, I will attempt to participate as a student again - and of course my project should be something very closely related to flashrom to exploit my knowledge in that area. I have already submitted a first alpha-stage proposal that basically includes the standard repertoire of things I do while working on flashrom in general, and also which I ended up doing in the past GSoC projects. Namely a mixture of maintenance, improvement and integration of existing patches, development of new features for flashrom. For me that worked out well and I believe it was very good for flashrom and worthwhile for the coreboot community as a whole too. I have not received too much feedback so I am not sure if everybody agrees with that and thinks that another such summer would be a good thing as well (if there are other candidates and/or proposals to choose from). If you think the GSoC slots of coreboot deserve something better, or more project-like then I could also try to work on something more confined/focused. There are a number of project ideas that might fit my profile quite well. The "End user flash tool" proposal would allow me to eventually finish libflashrom and the layout patches, maybe clean up the bios_extract repository and help those users that are fighting with vgabios extractions etc. :) Then there is the panic room idea which AFAIK is not finished and has some room for improvements, but I am not sure about its current state and if Kyösti wants to work on that this year...? Somehow related to both points above is an idea for a project I had for some time. A coreboot payload (probably)... for user flash updates that verifies a cryptographically signed image before flashing it. While currently this is relatively useless it might become interesting for distributing libreboot binary images for example. (even though I have to admit it is a bit ironic to ship binary images of a firmware that is blobfree :) IIRC the Chromebooks have a write-protected primary loader that verifies the remaining firmware etc... basically what secure boot demands. That solves a similar problem, but recovery for an end user is way more unpleasant than getting warned early before any modifications are done. Another advantage would be to have an OS-independent update mechanism... OTOH flashrom runs on every OS I deem worthy to run coreboot. :) The last project idea to be mentioned here that suits me well is what David proposed last year, see his post for details: http://www.flashrom.org/pipermail/flashrom/2013-March/010704.html So... I would be glad to get your feedback. What do you think would help us most? Do you have other ideas/wishes related to flashrom? I don't care too much on which project I work... they are all worthwhile IMHO. My preference would be to work freely on flashrom itself because it really needs it (there is no one else doing it) and I have the most knowledge in that field. But OTOH I can learn much more in every other project mentioned above and that's also very motivating. Naturally, I don't want to write multiple proposals if we can agree on one topic already... and time is rather short too :) PS: I have an asrock imb-180-h, an SPI programmer and lots of flash chips available to tinker with. There is also some ancient intel BX-based PC somewhere that I could port... I'd need to build a parallel flasher for that first though (cortex m3 board and stuff already collecting dust...) but that would probably be based on serprog and peter would veto for sure ;) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] new, need help and whatnot
On Fri, 26 Jul 2013 19:17:50 -0400 David Giard wrote: > Will remember to put a temporary jumper on the reset switch > header next time. Which will not help on new Intel-based boards AFAIK because they have edge-triggered reset inputs. I have documented the issues David mentioned and more here: http://flashrom.org/ISP -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [flashrom] Enabling Dediprog by default in flashrom
On Tue, 2 Jul 2013 00:12:28 -0300 Alexandre Pereira da Silva wrote: > I think its safe to use a read opcode by default. > > The DediProg can't reach high clock rates, well below the limit for the > normal read on most memories. > > I have a DediProg available for testing. > > Thanks. The problem is not so much the frequency but the opcode used. We just don't know what DediProg does if a chip does not provide fast read support. You do not happen to have a logic analyser and a very old SPI flash chip w/o fast read support, do you? :) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [x60s] Its alive! Its alive!
On Wed, 26 Jun 2013 15:59:54 -0700 Aaron Durbin wrote: > On Wed, Jun 26, 2013 at 3:58 PM, Stefan Tauner > wrote: > > One thing he did not mention is that cbmem seems to not work on his > > device. I don't know anything about cbmem but I looked into it a bit. > > mapping the first address (0) works fine, but cbmem does not find > > anything there and the mapping of the second address (0xf) fails > > then with: > > Looking for coreboot table at f > > Mapping 1MB of physical memory at 0xf. > > > > any ideas why this could happen? > > Could someone post the full serial log from the boot? I could take a look > then. Guess what we tried to gather from cbmem ;) I have not followed the discussion in detail, but IIRC he has no docking station and hence no serial port... and most probably no USB debugging device either. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [x60s] Its alive! Its alive!
One thing he did not mention is that cbmem seems to not work on his device. I don't know anything about cbmem but I looked into it a bit. mapping the first address (0) works fine, but cbmem does not find anything there and the mapping of the second address (0xf) fails then with: Looking for coreboot table at f Mapping 1MB of physical memory at 0xf. any ideas why this could happen? -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Enabling Dediprog by default in flashrom
Hi, the release of flashrom 0.9.7 is imminent and I would really like to enable the Dediprog programmer by default. Carl-Daniel informed me that the only problem is that we do not know which opcode is actually used for reading on the SPI bus. It could be that we initiate a fast read (0x0b) instead of a normal read (0x03). This would work with the majority of flash chips but would not with others where flashrom should normally work. Since we are not sure we don't want to enable it without further consideration/testing/warning messages. Furthermore not all chips supporting fast read have this fact noted in their datashets. So testing any apparently non-fast read chip does not suffice. We would rather be able to check the opcode on the SPI bus with a logic analyzer directly. Are there any Dediprog users who can help us with that please? -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Looking for dediprog users...
hi, if you are using an sf100 with a firmware version between 2.1.1 and 5.1.2 (non-inclusive), I would like to know from you if flashrom version r1649 or newer works for you or not. Probing for a chip (even if there is none attached) suffices as a test. Apparently earlier versions do not support setting the spi clock rate, but we always do that (since r1649) and fail programmer initialization on those versions. I try to find out which versions support setting the speed. BTW did anybody try to contact dediprog and request any information that would help flashrom to support their programmers better? I would also like to know if any dediprog sf300 or sf600 users are reading this and would like to see support for it in flashrom. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] fixed AMD SPI speed settings (leading to problems on E350M1/USB3)
Hi,
andor reported a problem where flashrom does reproducibly not work with
coreboot but does with the vendor BIOS
http://paste.flashrom.org/view.php?id=1614
Apparently it is related to fast reads and/or the frequency.
We have forced the fastReadEnable bit in the SPI_Cntrl0 from 1 to 0 and
also set NormSpeed in SPI_Cntrl1 to 16.5 Mhz (previously was 0 i.e. 66
MHz) in flashrom and the problem vanished.
Coreboot hard codes the fast read setting in
src/southbridge/amd/cimx/sb800/bootblock.c:
static void enable_spi_fast_mode(void)
{
u8 byte;
u32 dword;
device_t dev = PCI_DEV(0, 0x14, 0x03);
// set temp MMIO base
volatile u32 *spi_base = (void *)0xa000;
u32 save = pci_io_read_config32(dev, 0xa0);
pci_io_write_config32(dev, 0xa0, (u32) spi_base | 2);
// early enable of SPI 33 MHz fast mode read
byte = spi_base[3];
spi_base[3] = (byte & ~(3 << 14)) | (1 << 14);
spi_base[0] = spi_base[0] | (1 << 18); // fast read enable
pci_io_write_config32(dev, 0xa0, save);
}
Marc suggested that this should be configurable in the devicetree or by
a kconfig setting. Also, the statements using "byte" do not make a lot
of sense to me. Shouldn't that be a u32 instead?
The public documentation of the fastReadEnable is lacking any detail
and I don't have access to the NDAed version of the RRG. Is my theory
correct that the controller uses the 0x0B opcode with a fixed frequency
(33 MHz?) instead of 0x03 with the frequency set by NormSpeed?
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Summer project
Hello Martijn, On Sun, 14 Apr 2013 22:23:54 +0200 Martijn Bastiaan wrote: > For a while now, I've been interested in the development of Coreboot. > I really like the idea of an open-source firmware, which could > possibly replace all the current propriertary ones. At the same time > I'm looking for a project I can make a (ever so small) contribution > to. I hope to do that this summer vacation, in order to expand my > current skillset. You have not mentioned it at all although it might suit you very well: http://www.coreboot.org/GSoC > That last sentence implies why I'm writing to this mailing list > instead of starting right away: I feel like I (currently) lack the > necessary skills to make a meaningful contribution, or to understand > the codebase at all. I would however like to make an effort to change > that situation, but I don't know where to start. Let me start by > introducting myself so you can decide whether I'm even remotely suited > :-). Anyone putting some effort into learning some basics can help in one way or another. This is true for any (FOSS) project IMHO. The main question is usually if the open tasks that are interesting to you can be solved by you. > AmCAT allowed me to develop my Python skills to a point > where I can call myself experienced. I have no significant experience > writing in C, apart from the operating systems course[3] I took and > passed last term. Understanding and writing C is naturally one of the most important skills when working on the core parts of coreboot. But OTOH this means that one is forced to learn that quickly when trying to solve related problems. > I would love to hear your advice on the matter. What literature do you > recommend? Or would I be better suited for another project maybe? I found my lack of x86 knowledge way more challenging than anything else. The hardware in use today evolved over a very long period of time and much of this history including numerous tiny, awkward details are the reason for how things (have to) work in coreboot. Take a look at these links to understand what I mean with "challenging" :) http://www.coreboot.org/Datasheets#Intel http://lennartb.home.xs4all.nl/coreboot/coreboot.html -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Wiki cleanup (was: Request to become wiki admin)
On Wed, 3 Apr 2013 22:23:45 +0200 Stefan Reinauer wrote: > * Stefan Tauner [130402 16:50]: > > > please make Patrick and me (or at least him :) a (coreboot) wiki admin > > so that we can delete obsolete pages, thanks. > > Hi Stefan! > > done. > > Stefan, too. > Thanks! I propose the deletion of the following pages and will do so if no one vetoes within the next 4 days: http://www.coreboot.org/Flashrom http://www.coreboot.org/Flashrom/0.9.0 http://www.coreboot.org/Flashrom/0.9.1 http://www.coreboot.org/Flashrom/0.9.2 http://www.coreboot.org/Flashrom/NIC3Com http://www.coreboot.org/Flashrom/FT2232SPI_Programmer http://www.coreboot.org/Flashrom/Live_CD http://www.coreboot.org/Flashrom/Random_notes http://www.coreboot.org/Flashrom/Mailinglist http://www.coreboot.org/SerialICE [end of list] The german welcome page is somewhat outdated and not ranked favourable by google and it is not very often visited (~3500 times, which seems to be the value produced by spiders). Opinions? http://www.coreboot.org/Willkommen_bei_coreboot http://www.coreboot.org/Welcome_to_coreboot/de forwards there. Pages that need an update or deletion: http://www.coreboot.org/Viewvc ... Maybe we should create a wiki page listing them all? :P Good candidates for obsolete pages: http://www.coreboot.org/Special:AncientPages Although many of them are harmless cruft. They increase the database and may reduce usability a bit when looking at http://www.coreboot.org/Special:AllPages but there is no inherent risk for misery (e.g. http://www.coreboot.org/SHREK) I don't see the point in keeping them, but I won't touch any of them without further discussion. Then there are some ancient pages where I have no idea if they are just documenting really stable stuff or were abandoned (e.g. http://www.coreboot.org/Payload_API) Adding information that can help readers to assess the actuality would make sense (modification time of the page does not really help), because without that no one with FOSS experience would dare to think of it as valid information. For the payload API above the code location would be such an information. In general I think similar information should reside in the code itself only (as lengthy comment) anyway. I won't touch them either. If anybody else is interested in cleaning up stuff, please post your ideas... -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Request to become wiki admin
Hi, please make Patrick and me (or at least him :) a (coreboot) wiki admin so that we can delete obsolete pages, thanks. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Git
On Fri, 8 Mar 2013 16:18:35 +0100 Wolfgang Kamp - datakamp wrote: > > Hi Peter, > > I solved my first problem with git rebase -i. Now git show and git log > origin/master.. are synchronized. > Next will be git config remote.origin.url ssh://... and git config > remote.origin.push HEAD:refs/for/master. > Last step should be git push origin. > If I do that it counts 70368 objects with 3.64 MiB, but I will commit only > one little source file. > What happens here? I have aborted this git command, because I don't want to > commit may harddrive. Hi Wolfgang, maybe it is easier for everybody to debug this interactively, so feel free to join IRC for example via the webchat: http://webchat.freenode.net/?channels=coreboot&uio=d4 -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot 2013 Google Summer of Code: Call for mentors and project ideas
Thanks Marc for the kickoff mail! We (everybody else) should do a little bit more than we have done yet to make this happen ;) I'd like to participate as student again, rather doing a flashrom than a coreboot project, but we will see. I talked to Carl-Daniel and he will not have time to really mentor anybody (but me, due to obvious reasons (there was very little mentoring going on the first time) ;) If there would be another student interested in flashrom I would be able and like to mentor him. Sadly, doing both is not possible... at least not officially. I am not sure how to solve this yet (e.g. by registering as mentor only after we have found a suitable student), but OTOH I fear it will not be a problem anyway (i.e. lack of interest in flashrom). I'll try to figure out some more flashrom project ideas, talk with Carl-Daniel and update our last year's page (http://flashrom.org/GSoC) and help with the cb wiki too. I think it would be a good idea to gather information on who wants to help and how, therefore... http://www.coreboot.org/GSoC#People_involved Maybe we could also schedule an IRC meeting of these, maybe in the next days? -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] IMC on persimmon (was: Flashrom erase failure)
On Fri, 1 Mar 2013 20:48:48 + "Racine, Michel" wrote: > Thank you for the quick reply. > > I have upgraded flashrom. I did a verify, and flashrom indicated a > difference. I tried to re-flash coreboot, but I think I'm missing something: > > root@debian:~/flashrom/flashrom-0.9.6.1# ./flashrom -p internal -w > ~/coreboot.rom > flashrom v0.9.6.1-r1564 on Linux 2.6.32-5-686 (i686) > flashrom is free software, get the source code at http://www.flashrom.org > > Calibrating delay loop... OK. > coreboot table found at 0xc717d000. > Found chipset "AMD SB7x0/SB8x0/SB9x0". Enabling flash write... The SB700 IMC > is active and may interfere with SPI commands. Disabling write. > OK. > Found SST flash chip "SST25VF032B" (4096 kB, SPI) at physical address > 0xffc0. > Write/erase is not working yet on your programmer in its current > configuration. > Aborting > > > Thoughts? I have added the coreboot mailing list because I ham not familiar with the board or chipset and I am quite certain someone there knows how to handle this correctly. The new version of flashrom detects that the embedded controller on the board (IMC) accesses the SPI bus concurrently with flashrom. We disable writes for safety reasons in that case (your old version did not...). Apparently there is no way to force writing other than changing the source code (sb600.c). I don't think that is wisely though... Apart from repeating the warning to *NOT* reboot/reset/shutdown the machine (unless you have a known-working external flash programmer), I can not help you further ATM. > -Original Message- > From: Stefan Tauner [mailto:stefan.tau...@student.tuwien.ac.at] > Sent: Friday, March 01, 2013 12:09 PM > To: Racine, Michel > Cc: flash...@flashrom.org > Subject: Re: [flashrom] Flashrom erase failure > > On Fri, 1 Mar 2013 17:19:46 + > "Racine, Michel" wrote: > > > Greetings, > > > > I have an AMD Persimmon dev board. I built coreboot and flashed it > > successfully; the board was operational. > > I have attempted to flash the original rom (obtained before flashing > > coreboot with flashrom -r). > > When I attempted to flash the original rom, I get the output below. > > > > Hi, > > you are trying to write the original image while running coreboot, right? > > You are using a very old version of flashrom. Please verify that the content > of the flash is untouched (by using the -v option with the image you have > written successfully last). If it was modified try to rewrite that image. If > that still does not work, please report back, else update and retry. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Off-topic: what's a fast, easily accessible I/O (pin)?
Hi, if you would want to measure the instant in time you do something() in software with a scope or logic analyser (by toggling a pin once) on a typical x86 PC (e.g. pci, serial, lpt available, ok maybe not THAT typical anymore ;) running linux, what kind of I/O would you choose? latency should be minimal, but without major hardware hacks (no soldering to CPU pins or similar please :) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] First ROM Image
On Sat, 15 Sep 2012 16:05:56 +1000 "Rex O'Regan" wrote: > The BIOS chip is in a socket so if I brick the machine all I need to do > is remove the chip and program it again from a separate computer? A better idea is to gather replacement chips beforehand and using the hotswap technique to create backups. To do this you boot with a known-good chip, swap it for an empty one after boot and write to that one instead for experiments etc. It is usually a good idea to clearly mark the backup chip(s) ;) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [flashrom] (help me to get better) flashrom support for thinkpads with locked down opcodes
On Mon, 27 Aug 2012 06:18:53 +0200 Stefan Reinauer wrote: > * Stefan Tauner [120826 21:31]: > > As you probably all know the procedure to relieve the coreboot- > > supported thinkpads from their proprietary firmware is not completely > > trivial[1]. The main problem is that the vendor has locked down the > > available SPI opcodes that we are allowed to use and this hinders > > current flashrom to identify the flash chip. > > Have you guys considered SMI cache poisoning attacks to work around > those restrictions? > > It would pretty much be a per bios version or per machine based > workaround, but if we can provide known good coreboot images, that might > be attractive for people out there... hehe, no i did not think about that. :) although it would be really cool, i dont think that it makes a lot of sense right now. adding support on a per-mainboard base can be done way easier and safer, and we are looking for a more generic way anyway (and i lack the knowledge to implement it too). it would be very cool to see a proof of concept though... :) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] (help me to get better) flashrom support for thinkpads with locked down opcodes
Hi there! As you probably all know the procedure to relieve the coreboot- supported thinkpads from their proprietary firmware is not completely trivial[1]. The main problem is that the vendor has locked down the available SPI opcodes that we are allowed to use and this hinders current flashrom to identify the flash chip. Carl-Daniel has started to work on a patch that allows flashrom to use a lower-quality identifying opcode (RES) on such locked down computers without spoiling flashrom use on other devices. I have continued that and we now have a patch that allows probing and reading on the thinkpads. Erase (and hence write in practice) does not work yet, because the available erase opcodes are also limited, but that will be dealt with shortly(-ish :). The current version of the patch can be found here: http://patchwork.coreboot.org/patch/3726/ I would like to request the help of at least one volunteer who is able to recover from failed flash attempts and is willing to revert to the vendor firmware temporarily and spend some time testing patches we sent him. This will of course not make the coreboot conversion foolproof and is quite late... but i am pretty sure it will still be welcomed by newbies :) Also, i would like to see a flashrom -V log of any affected machine that is not a T60 (2007-GCG)[2] and is running the vendor firmware. [1]: http://www.coreboot.org/Lenovo_x60x [2]: http://paste.flashrom.org/view.php?id=635 -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [flashrom] Support for IBM/Lenovo Thinkpad T60 Flash
On Sat, 5 May 2012 02:27:20 +0200 Joerg Mayer wrote: > Hello, > > some time (> 1 year?) ago I asked on flashrom about support for the T60 > and the attached patch was sent as part of the answer. The other part of > the answer was that whoever sent this patch was not happy with it. > Unfortunately I didn't keep the mail(s) and have forgotten the reason > for this. Google also didn't really help. What I found was a similar but > not identical mail on coreboot: > http://www.coreboot.org/pipermail/coreboot/2010-December/062303.html > As the T60 is one of the few Laptop models that are supported by coreboot > and I'd like to update to it I have two requests: > 1) would someone be willing to update the patch to the current flashrom >codebase (I tried this and was able to read, but I don't trust it as >the change was done without understanding what the changes did). > 2) if possible integrate this into flashrom to make using coreboot easier. > 3) (of 2) would it be useful to integrate bucts into flashrom or move it >to coreboot/utils/? Hello Jörg, I have described the reason why patching is needed, how to do it and why it is not possible to integrate this patch into flashrom in the coreboot-wiki: http://www.coreboot.org/Lenovo_x60x -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Intel SCH CMC(Chipset Microcode) state machine binary?
On Fri, 21 Oct 2011 16:50:30 +0200 Peter Stuge wrote: > Another method is to use http://stuge.se/physrd.c to try to read from > the flash chip directly, then you do not need to do maths, but on the > other hand you must compile a special program and if you are unlucky > the address region is not accessible by the CPU without special magic > that flashom knows. btw i have submitted patches to the flashrom ml that allow layout files to be used for read operations too. layout files are small configuration files with address ranges and names that were introduced to allow writing to parts of the flash only. but of course calculation + dd is the better way to do this, especially if the data is on disk and not on a flash chip ;) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] flash-chip (and compatibles)
On Thu, 18 Aug 2011 17:15:40 +0200 Oliver Schinagl wrote: > I did find a pdf that was somewhat interesting: > > http://www.msc-ge.com/download/pcn/macronix/pcn-10-037.pdf > > it basically mentions/confirms it's an SPI/serial based 32Mb flash, > dunno if that can help me find a pin-compatible chip :S hello oliver MX25L3206EPI-12G that chip is not special at all and can be replaced by (almost?) any 25-series flash chip with the same package (300mil 8-PDIP) and voltage rating (2.7 - 3.6V). of course there are corner cases, but in general there should not be a big problem with other vendors. if you have found an offer that suits you, you could ask us again... -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] new coreboot twitter account
hi there! not so sure this justifies spam, but i have set up a twitter account for coreboot (and flashrom): http://twitter.com/coreboot_org the current plan is to setup a wordpress plugin to push headlines of new blog posts there. currently marjc, stepan and i know the password (at least)... just in case. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPI flashing
On Wed, 06 Jul 2011 13:23:47 +0200 Andreas Galauner wrote: > Hello again, > as you may have read yesterday, I'm currently trying to play with some > in-system SPI flashing and I need some additional advice. hello andreas you may wanna look at the flashrom wiki page about in-system programming: http://flashrom.org/ISP i wrote the most important stuff that i am aware of in there. if you (or anybody else without wiki access) think anything is missing, just drop me a mail. i should add the tip with standby mode probably. that one is new to me (although pretty obvious :) we are talking about S3 here i guess? -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] looking for coreboot snapshots
On Fri, 10 Jun 2011 14:34:28 -0500 "Scott Duplichan" wrote: > Hello, > > Is there a way to download an archived snapshot of recent coreboot source > code? gitweb can create snapshots on the fly. i am not sure if the gitweb integration is completed so YMMV. http://review.coreboot.org/gitweb?p=coreboot.git;a=summary -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [RFC] usb flashing protocol (was: cheapish and free usb spi flashing device)
hey! peter and i have started to discuss and lay out the details of a native usb flashing protocol. the WIP document can be found at http://titanpad.com/x8M9ZvNeMN we need to design abstract representations of a few things like erase blocks, instruction sequences for various operations etc. some of which are (probably) already implemented in flashrom in one form or another while others might be useful to have in there and have been discussed or at least thought through already by someone. so feel free to contribute please. ;) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] cheapish and free usb spi flashing device
On Fri, 22 Apr 2011 05:08:32 +0200 Peter Stuge wrote: > > right now my plan is the following: > > an avr atmegaXXu2 is connected via usb and implements the serprog > > protocol > > Please do not! Make good use of USB and design a protocol that > actually takes advantage of relevant USB features, instead of > pretending that USB is a serial port, which is really lame. > what features do you think _are_ relevant? sure serprog is pretty stupid, but that has nothing to do with its serial property. :) > At a very minimum translate the serprog protocol to native USB. > > USB is a packet bus. Making it behave like a dumb stream of bytes is > almost never a good idea. > if i had to transfer the content of a file i would choose tcp instead of udp. this is quite similar imho. of course factoring out the control messages is useful, but there are several drawbacks: - we cant tunnel it as easily (e.g. over tcp like serprog) - everything gets way more complicated on the microcontroller i dont see a lot of performance improvements from it either. dropping cdc and just stream our own protocol via usb's bulk endpoints would be fine with me. i have already done this once. maybe i am missing something though. please layout your basic ideas how an USB flashing protocol should look like, what it could do (what serprog or something similar could not (as easily)). btw do we want to support non-spi flashes at all? > Also, make a simple HAL for the AVR, so that your C firmware can be > re-used with other processors. I'll make it run on LPC1342/43. > sure. spi reads, writes and cs(/hold?/wp?) will be independent. atm i am extending serprog and character reads and writes from the serial stream are basically independent. i do use avr-specific printfs though (those fetch the strings from flash memory instead of ram... harvard architecture, which is not abstracted), but that can be dealt with if need be. > > without any level shifting. > > Yes, is a good feature. > it costs performance in the case of the avr though... about 8MHz maximum clock instead of 16 with vcc>=4.5V. > > i was also thinking about an offline mode which uses an SD-card or > > another flash to store/load an image for the target flash. > > SD is not worth the effort. SD cards are very incompatible and it > takes a lot of work to implement a well-functioning card reader. thats true, i have tried ;) > And the filesystems are buggy as well. we would not need one... wear leveling is done by the card and we only need a continuous block. > A second flash chip could be handy for offline mode - but what is > supplying the power? a usb power supply for example :) adding another connector for other power supplies wouldnt be a problem either. BUT.. since there is not really interest in _my_ new flasher anyway and everyone seem to have built his own, i think we should just concentrate on the usb protocol. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [RFC] cheapish and free usb spi flashing device
hey there! (cross-posted to both mailing lists) i am currently designing a small and cheap platform to recover from coreboot and other failures easily. the reason i am writing this is to get feedback from you regarding desired features of and interest in such a device. right now my plan is the following: an avr atmegaXXu2 is connected via usb and implements the serprog protocol to let flashrom make use of it. the avr can operate down to 3.0V which would allow easy interfacing with today's spi flashes without any level shifting. to get the desired supply voltage from usb's 5V i will use a fixed 3.3V ldo voltage regulator (ld1117). apart from a few supporting parts (caps, fuse, usb line termination etc.) the only things missing are sockets for the spi chips. at the moment i am planing to include: - soic8 pads (combined for 150 and 200mil devices) and enough room for a soic8 zif adapter (like the one from http://bios-repair.co.uk) - vias for a 24 pin zif dip/dil socket (150 and 300mil spacing combined): 8 pins for dip8 flashes and 16 for soic16 flashes (those would require a soic to dip adapter). 8pin and 16pin flashes dont share pins therefore the large socket... - vias for a single row 8pin header to allow attaching probes/test clips (e.g. http://www.pomonaelectronics.com/images/large/6109.jpg) to hook up in-situ flashes. parts for this excluding the pcb would be in the 10-25$ range. depending on how many pcbs i/we would produce the whole thing would cost probably about 40$. not THAT cheap, but quite better than the dediprog stuff :) it would also be more convenient and open than the FT2232SPI based on the DLP-USB1232H (http://flashrom.org/FT2232SPI_Programmer). the willem programmers seem to be lpt only? are there any other cheap flashers i dont know? i am not sure about what to do with soic16 chips. the solution laid out above which requires an additional adapter and wastes a lot of space is awkward. should i just include soic16 pads instead? should i drop support for them altogether and let the user hook them up with clips? are they in use anywhere? my intel desktop board has pads for it, but i am not sure if there are any boards in the wild which really use them... i was also thinking about an offline mode which uses an SD-card or another flash to store/load an image for the target flash. push buttons would activate a cloning operation. this way one could clone chips easily without a pc, but i am not sure at all if thats worth it. what do you think? -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
