coreboot November 2016

coreboot@coreboot.org

66 participants
187 discussions

More details about ram issues
by Charlotte Plusplus 08 Nov '16

08 Nov '16

Hello On Tue, Nov 8, 2016 at 11:30 AM, Patrick Rudolph <siro(a)das-labor.org> wrote: > Good point, I've should have mentioned that. > Well, I found out by myself the hard way after scratching my head. It is the best way to learn I suppose :-) > At the moment there's no such functionality I'm aware of. Of course you > can comment store_current_mrc_cache() and it will always do full > raminit training. > The boot is already quite slow, around 6 seconds. cbmem -t shows about 1.5 seconds are spend at the beginning of ram init and another at the end of ramstage. I don't know if there is a way to trim that safely, but I am reluctant to add anything that will cause me to stare longer at a black screen while testing this ram stuff. My best idea is make using mrc_cache conditional to having a reboot count <10 (or the largest value that can be held, or some impossible value that can still be stored there with nvramtool), and manually setting the reboot count with nvramtool when I want. That should be a simple workaround, if the nvram variables are accessible at this point (I have to check) In init_dram_ddr3(), would something like that work to replace mrc_cache = find_current_mrc_cache unsigned char byte; byte = cmos_read(RTC_BOOT_BYTE); if (boot_count(byte) < 10) { mrc_cache = find_current_mrc_cache(); } > Alternatively, a really nice thing to have would be a nvram option to > > pass max_mem_clock_mhz without having to recompile, and invalidate > > this cache if the settings do not match, to cover cases like this > > one. Also, overclockers would love that. So this option could even > > be used to pass custom SPD timings, as some bios do. It would require > > more thinking on what to do and how, but it looks like a nice feature > > to me. Would it be acceptable to add that to coreboot? > > > That's a nice idea, but there's no interface (yet). It also would be > nice to have a vendor independent solution. > If other vendors support passing ram parameters, why not? At the moment I'm thinking of a nvram option like MemoryOverride: freq, tCAS, tRCD, tRP, tRAS Why would it be an impossible interface? Just read the nvram, if you find the option, override the defaults values of ctr->tCK, ctrl->CAS, ctrl->tRCD, ctrl->tRP and ctrl->tRAS in dram_init. Do this unless the setting can't be applied by the chips. I have no idea whether this is possible, because until about a week ago I had no idea how the ram init worked. It just seems to make sense to do it this way. Another nice use: memtest could write to the nvram to increase the latencies when it finds error, update the reboot count to the value that would cause the update of the MRC cache, and issue a reboot. coreboot would then use these new values, and memtest would try again to see if the new setup is stable. That would be a nice way to automate the tedious step of making the ram work. It could also help validate ram init algorithms, since I now understand they are a bit of a black box. I mean, it's not normal that reading and applying the SPD information from my sticks results in an unstable system. An option for a safety check should be added somewhere. The raminit code is based on sandybridge, and doesn't have all ivy > bridge optimizations. For exmaple it isn't possible to use a base > frequency of 100Mhz (no DDR3-2000 or DDR3-1800 modes supported). > I didn't know that :-( After some googling I see it was reversed. There must be no documentation so no easy way to add Ivy Bridge optimizations :-( I think it's another good reason to have a way to interface ram setting with userland tools. Also, XMP would require to adjust the voltage (especially for profile 2 that is currently not read), but I don't think it is done currently. Or maybe I just don't understand it. This means the information we get from reading the XMP profile, which also contains some voltage information, can not be relied upon for stability, as only half of it is applied. Maybe using XMP should be made a config time option (with warning about stability since the voltage information is ignored, and only timings are used) until the voltages can also be applied? I will try to run more tests to see if ignoring XMP can help me with my stability issues before I go on with the overrides. Please have a look at dram_timing(). I don't think it's a good idea to > do tests without having logging output, but it's up to you. > I have no way to log output at the moment. I am waiting for my FT232. All I can do I check the stability in memtest. I also prefer memtest verdict as a final arbitrator, because all that matters is stability. > You can enable raminit logging by checking "Output verbose RAM init > debug messages" in menu Debugging. It doesn't work well with cbmem > logging. > Already done, and indeed I have truncated lines :-( Charlotte

1 0

Re: [coreboot] radare
by Riko Ho 08 Nov '16

08 Nov '16

This is what I had done and worked on : bianchi@ubuntu:~/Documents/Coreboot Column$ r2 i946gz_Edited.bin [f000:fff0]> s f000:0 [f000:0000]> pD 0xffff Do you want to print 4401484 chars? (y/N) ; [0] va=0x000f0000 pa=0x00070000 sz=65536 vsz=65536 rwx=-rwx bootblk ;-- section.bootblk: ,=< f000:0000 ead41100f0 jmp word 0xf000:0x11d4 | f000:0005 0000 add [bx+si], al | f000:0007 0000 add [bx+si], al | f000:0009 0000 add [bx+si], al | f000:000b 0000 add [bx+si], al | f000:000d 0000 add [bx+si], al | f000:000f 00e8 add al, ch | f000:0011 0c01 or al, 0x1 ,==< f000:0013 745e jz 0xf0073 and so on until the bottom 4401481 chars... On 9/11/2016 2:32 AM, Zoran Stojsavljevic wrote: > Hello to all radare2 experienced people, > > From my VM Fedora 25 x86_64 on the top of VMWorkstation 12.5.1, on > WIN10 64 Pro! > > Here is my take on radare2... And I am not getting through. Transcript > follows: > > [zoran@localhost bios]$ radare2 -e asm.bits=16 -e io.va > <http://io.va>=true BIOS_AMI_BIOS.bin > -- attempt to dissasemble Core IVB AMI BIOS > [0000:0000]> S $s-0x10000 0xF000:0x0000 0x10000 0x10000 bootblk rwx > [0000:0000]> e asm.segoff=true > [0000:0000]> e asm.syntax = intel > [0000:0000]> s 0xf000:0xfff0 > [f000:fff0]> pd 16 > f000:fff0 ff invalid > f000:fff1 ff invalid > f000:fff2 ff invalid > f000:fff3 ff invalid > f000:fff4 ff invalid > f000:fff5 ff invalid > f000:fff6 ff invalid > f000:fff7 ff invalid > f000:fff8 ff invalid > f000:fff9 ff invalid > f000:fffa ff invalid > f000:fffb ff invalid > f000:fffc ff invalid > f000:fffd ff invalid > f000:fffe ff invalid > f000:ffff ff00 inc word [bx + si] > [f000:fff0]> > > Help needed/comments appreciated. What am I doing wrong? > > Thank you, > Zoran > > On Mon, Nov 7, 2016 at 2:08 AM, Riko Ho <antonius.riko(a)gmail.com > <mailto:antonius.riko@gmail.com>> wrote: > > Hi Zoran, > I reckon that's the right radare, find *.bin or *.rom or *.hex and run > > [zoran@localhost ~]$ radare2 *.bin > and s command and pD command....for example : > > [f000:fff0]> s f000:0 > [f000:0000]> pD 0xffff > > > more info : > https://radare.gitbooks.io/radare2book/content/disassembling/intro.html > <https://radare.gitbooks.io/radare2book/content/disassembling/intro.html> > > On 7/11/2016 5:41 AM, Zoran Stojsavljevic wrote: >> Hello Riko, >> I recently also became very interested to start using radare2 >> (Raphael Machado's dissasembly attempts got involved me, to set >> the tool). Since I am very lazy person, the first was to ask my >> Fedora 25 distro does the distro have package radare2? >> Yes, it does have it, so I have installed it. And for you, here >> is the transcript of my CLI for you. >> CLI traces (radare --help) are worth 1000nd words, don't you >> agree? ;-) >> Best Regards, >> Zoran >> _______ >> [zoran@localhost ~]$ uname -r >> 4.8.6-300.fc25.x86_64 >> [zoran@localhost ~]$ which radare2 >> /usr/bin/radare2 >> */_[zoran@localhost ~]$ radare2 --help_/* >> radare2: invalid option -- '-' >> r_config_get: variable 'lp' not found >> -- open radare2 on an empty file >> - equivalent of 'r2 malloc://512' >> = read file from stdin (use -i and -c to run cmds) >> -= perform !=! command to run all commands remotely >> -0 print \x00 after init and every command >> -a [arch] set asm.arch >> -A run 'aaa' command to analyze all referenced code >> -b [bits] set asm.bits >> -B [baddr] set base address for PIE binaries >> -c 'cmd..' execute radare command >> -C file is host:port (alias for -c+=http://%s/cmd/) >> -d debug the executable 'file' or running process 'pid' >> -D [backend] enable debug mode (e cfg.debug=true) >> -e k=v evaluate config var >> -f block size = file size >> -F [binplug] force to use that rbin plugin >> -h, -hh show help message, -hh for long >> -i [file] run script file >> -I [file] run script file before the file is opened >> -k [k=v] perform sdb query into core->sdb >> -l [lib] load plugin file >> -L list supported IO plugins >> -m [addr] map file at given address (loadaddr) >> -M do not demangle symbol names >> -n, -nn do not load RBin info (-nn only load bin structures) >> -N do not load user settings and scripts >> -o [OS/kern] set asm.os (linux, macos, w32, netbsd, ...) >> -q quiet mode (no prompt) and quit after -i >> -p [prj] use project, list if no arg, load if no file >> -P [file] apply rapatch file and quit >> -R [rarun2] specify rarun2 profile to load (same as -e >> dbg.profile=X) >> -s [addr] initial seek >> -S start r2 in sandbox mode >> -t load rabin2 info in thread >> -u set bin.filter=false to get raw sym/sec/cls names >> -v, -V show radare2 version (-V show lib versions) >> -w open file in write mode >> -z, -zz do not load strings or load them even in raw >> Scripts: >> system /usr/share/radare2/radare2rc >> user ~/.radare2rc ${RHOMEDIR}/radare2/radare2rc (and >> radare2rc.d/) >> file ${filename}.r2 >> Plugins: >> plugins /usr/lib/radare2/last >> user ~/.config/radare2/plugins >> LIBR_PLUGINS /usr/lib/radare2/0.10.6-git >> Environment: >> RHOMEDIR /home/zoran/.config/radare2 >> RCFILE ~/.radare2rc (user preferences, batch script) >> MAGICPATH /usr/lib64/radare2/0.10.6-git/magic >> R_DEBUG if defined, show error messages and crash signal >> VAPIDIR path to extra vapi directory >> R2_NOPLUGINS do not load r2 shared plugins >> Paths: >> PREFIX /usr >> INCDIR /usr/include/libr >> LIBDIR /usr/lib64 >> LIBEXT so >> [zoran@localhost ~]$ >> On Sat, Nov 5, 2016 at 3:55 AM, Riko Ho <antonius.riko(a)gmail.com >> <mailto:antonius.riko@gmail.com>> wrote: >> >> Hi Rafael, For example I want to see the asm code for the >> whole 512Kbytes....is that possible ? How ? Thanks >> On 5/11/2016 3:36 AM, Rafael Machado wrote: >>> Hi >>> You can use the pd command. >>> p = Print >>> d = disassemby >>> You can also add the number of instruction you whant to see. >>> For example: >>> pd 10 >>> Thanks >>> Rafael Machado >>> Em qua, 2 de nov de 2016 às 04:01, Riko Ho >>> <antonius.riko(a)gmail.com <mailto:antonius.riko@gmail.com>> >>> escreveu: >>> >>> Everyone, Idwer, I have radare question : I played until >>> this point : c:>radare2 -e asm.bits=16 -e io.va >>> <http://io.va>=true i946gz.bin -- radare2 is WYSIWYF - >>> what you see is what you fix [f000:fff0]> S $s-0x10000 >>> 0xF000:0x0000 0x10000 0x10000 bootblk rwx [f000:fff0]> e >>> asm.segoff=true [f000:fff0]> s 0xf000:0xffff0 >>> [f000:ffff]> How can I see the assembler code from there >>> ? It's started from FFFF0....I'm sure the last byte >>> instruction is jump to 0x00000 Cheers -- coreboot >>> mailing list: coreboot(a)coreboot.org >>> <mailto:coreboot@coreboot.org> >>> https://www.coreboot.org/mailman/listinfo/coreboot >>> <https://www.coreboot.org/mailman/listinfo/coreboot> >>> >> -- */*===*/ Kind regards, Riko Ho /*===*/ * >> -- coreboot mailing list: coreboot(a)coreboot.org >> <mailto:coreboot@coreboot.org> >> https://www.coreboot.org/mailman/listinfo/coreboot >> <https://www.coreboot.org/mailman/listinfo/coreboot> >> > -- */*===*/ Kind regards, Riko Ho /*===*/ * > -- */*===*/ Kind regards, Riko Ho /*===*/ *

1 0

Re: [coreboot] Intel Braswell FSP graphics init
by Andreas Galauner 08 Nov '16

08 Nov '16

On 08.11.2016 20:04, Aaron Durbin via coreboot wrote: > You'll need a debug version of FSP so that you can see the serial > messages it spits out as to why things are failing. Talk to Intel to > get help as that's about the best you can do with FSP at this point. > You are passing things in but not getting the result you desire. I really doubt they will give this to me as a private person without being affiliated to a company which buys stuff from them and signs NDAs. I don't even have a contact point.

2 2

Re: [coreboot] radare
by Riko Ho 08 Nov '16

08 Nov '16

Hi Zoran, I reckon that's the right radare, find *.bin or *.rom or *.hex and run [zoran@localhost ~]$ radare2 *.bin and s command and pD command....for example : [f000:fff0]> s f000:0 [f000:0000]> pD 0xffff more info : https://radare.gitbooks.io/radare2book/content/disassembling/intro.html On 7/11/2016 5:41 AM, Zoran Stojsavljevic wrote: > Hello Riko, > > I recently also became very interested to start using radare2 (Raphael > Machado's dissasembly attempts got involved me, to set the tool). > Since I am very lazy person, the first was to ask my Fedora 25 distro > does the distro have package radare2? > > Yes, it does have it, so I have installed it. And for you, here is the > transcript of my CLI for you. > > CLI traces (radare --help) are worth 1000nd words, don't you agree? ;-) > > Best Regards, > Zoran > _______ > > [zoran@localhost ~]$ uname -r > 4.8.6-300.fc25.x86_64 > [zoran@localhost ~]$ which radare2 > /usr/bin/radare2 > */_[zoran@localhost ~]$ radare2 --help_/* > radare2: invalid option -- '-' > r_config_get: variable 'lp' not found > -- open radare2 on an empty file > - equivalent of 'r2 malloc://512' > = read file from stdin (use -i and -c to run cmds) > -= perform !=! command to run all commands remotely > -0 print \x00 after init and every command > -a [arch] set asm.arch > -A run 'aaa' command to analyze all referenced code > -b [bits] set asm.bits > -B [baddr] set base address for PIE binaries > -c 'cmd..' execute radare command > -C file is host:port (alias for -c+=http://%s/cmd/) > -d debug the executable 'file' or running process 'pid' > -D [backend] enable debug mode (e cfg.debug=true) > -e k=v evaluate config var > -f block size = file size > -F [binplug] force to use that rbin plugin > -h, -hh show help message, -hh for long > -i [file] run script file > -I [file] run script file before the file is opened > -k [k=v] perform sdb query into core->sdb > -l [lib] load plugin file > -L list supported IO plugins > -m [addr] map file at given address (loadaddr) > -M do not demangle symbol names > -n, -nn do not load RBin info (-nn only load bin structures) > -N do not load user settings and scripts > -o [OS/kern] set asm.os (linux, macos, w32, netbsd, ...) > -q quiet mode (no prompt) and quit after -i > -p [prj] use project, list if no arg, load if no file > -P [file] apply rapatch file and quit > -R [rarun2] specify rarun2 profile to load (same as -e dbg.profile=X) > -s [addr] initial seek > -S start r2 in sandbox mode > -t load rabin2 info in thread > -u set bin.filter=false to get raw sym/sec/cls names > -v, -V show radare2 version (-V show lib versions) > -w open file in write mode > -z, -zz do not load strings or load them even in raw > Scripts: > system /usr/share/radare2/radare2rc > user ~/.radare2rc ${RHOMEDIR}/radare2/radare2rc (and radare2rc.d/) > file ${filename}.r2 > Plugins: > plugins /usr/lib/radare2/last > user ~/.config/radare2/plugins > LIBR_PLUGINS /usr/lib/radare2/0.10.6-git > Environment: > RHOMEDIR /home/zoran/.config/radare2 > RCFILE ~/.radare2rc (user preferences, batch script) > MAGICPATH /usr/lib64/radare2/0.10.6-git/magic > R_DEBUG if defined, show error messages and crash signal > VAPIDIR path to extra vapi directory > R2_NOPLUGINS do not load r2 shared plugins > Paths: > PREFIX /usr > INCDIR /usr/include/libr > LIBDIR /usr/lib64 > LIBEXT so > [zoran@localhost ~]$ > > On Sat, Nov 5, 2016 at 3:55 AM, Riko Ho <antonius.riko(a)gmail.com > <mailto:antonius.riko@gmail.com>> wrote: > > Hi Rafael, > > For example I want to see the asm code for the whole > 512Kbytes....is that possible ? > How ? > > Thanks > > On 5/11/2016 3:36 AM, Rafael Machado wrote: >> Hi >> >> You can use the pd command. >> p = Print >> d = disassemby >> >> You can also add the number of instruction you whant to see. For >> example: >> >> pd 10 >> >> Thanks >> Rafael Machado >> >> Em qua, 2 de nov de 2016 às 04:01, Riko Ho >> <antonius.riko(a)gmail.com <mailto:antonius.riko@gmail.com>> escreveu: >> >> Everyone, Idwer, >> >> I have radare question : >> >> I played until this point : >> c:>radare2 -e asm.bits=16 -e io.va <http://io.va>=true i946gz.bin >> -- radare2 is WYSIWYF - what you see is what you fix >> [f000:fff0]> S $s-0x10000 0xF000:0x0000 0x10000 0x10000 >> bootblk rwx >> [f000:fff0]> e asm.segoff=true >> [f000:fff0]> s 0xf000:0xffff0 >> [f000:ffff]> >> >> How can I see the assembler code from there ? It's started from >> FFFF0....I'm sure the last byte instruction is jump to 0x00000 >> >> Cheers >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> <mailto:coreboot@coreboot.org> >> https://www.coreboot.org/mailman/listinfo/coreboot >> <https://www.coreboot.org/mailman/listinfo/coreboot> >> > > > -- > */*===*/ > Kind regards, > Riko Ho > /*===*/ * > > -- > coreboot mailing list: coreboot(a)coreboot.org > <mailto:coreboot@coreboot.org> > https://www.coreboot.org/mailman/listinfo/coreboot > <https://www.coreboot.org/mailman/listinfo/coreboot> > > -- */*===*/ Kind regards, Riko Ho /*===*/ *

2 1

Intel Braswell FSP graphics init
by Andreas Galauner 08 Nov '16

08 Nov '16

Hi all, I'm currently porting coreboot to a new Board with an Intel Braswell on it. I finally managed to get to a point where Coreboot wants to load a payload, so all the basic hardware initialization tasks are done. During bootup, I get a message that the FSP didn't pass back a EFI_PEI_GRAPHICS_INFO_HOB. I' supplying the FSP with a VBT that the engineer of the board sent me. I also extracted the VBT from a UEFI image that is already working on the board and the files are the same. So, I guess that the config data is valid. Still, none of the outputs seem to get configured by the FSP at all. Any hints what I can do to solve this? Is there any debug information available from the FSP why it didn't initialize the graphics hardware? Thanks, - Andy

2 1

Re: [coreboot] More details about ram issues
by Patrick Rudolph 08 Nov '16

08 Nov '16

Am Tue, 8 Nov 2016 02:15:31 -0500 schrieb Charlotte Plusplus <pluspluscharlotte(a)gmail.com>: > Hello > > I have done further ram testing. > > My first guess was to disable the XMP code - it didn't help, but I > may have done things wrong as I was trying with a normal and a > fallback mode to try more combinations of options, and apparently the > ram settings are cached and shared between normal and fallback, even > when max_mem_clock_mhz differ. > Good point, I've should have mentioned that. > That's not a good thing when working on ram issues, so I wonder, is > there any way to manually invalidate that mrc cache during tests?? (I > almost want to comment the function in raminit.c) Since I don't have > a USBDEBUG yet, I go to a linux shell to check the cbmem output > between tests. So anything I can type to disable the mrc cache would > do. > At the moment there's no such functionality I'm aware of. Of course you can comment store_current_mrc_cache() and it will always do full raminit training. > Alternatively, a really nice thing to have would be a nvram option to > pass max_mem_clock_mhz without having to recompile, and invalidate > this cache if the settings do not match, to cover cases like this > one. Also, overclockers would love that. So this option could even > be used to pass custom SPD timings, as some bios do. It would require > more thinking on what to do and how, but it looks like a nice feature > to me. Would it be acceptable to add that to coreboot? > That's a nice idea, but there's no interface (yet). It also would be nice to have a vendor independent solution. > Anyway, I tried to downclock at various frequencies: > - 666 Mhz: CAS 7-7-7-20 : all sticks work, individually and together > - 800 Mhz: CAS 9-9-9-24: 1 stick doesn't work, the others do, but I > still get errors during the memtest step 8. > > I regret it is not possible to manually enter the right SPD > information that I know to work: 11-11-11-29 for DDR3-2000, > 11-11-11-31 for DDR3-2133 - and something slightly larger for > DDR3-1600. So I have DDR3-2133 sticks that I am forced to run at > DDR3-1333 speeds because otherwise the selected SPD settings make > everything unstable :-( > The raminit code is based on sandybridge, and doesn't have all ivy bridge optimizations. For exmaple it isn't possible to use a base frequency of 100Mhz (no DDR3-2000 or DDR3-1800 modes supported). > If only I could slightly increase the latency, I could run at least at > DDR3-1600 speeds with 0 error in memtest. I'm thinking of tweaking > dram_find_common_params with: > > ctrl->tRAS = MAX(ctrl->tRAS, dimm->tRAS) +X; > Please have a look at dram_timing(). I don't think it's a good idea to do tests without having logging output, but it's up to you. > and manually trying X=1, X=2 etc. until I can finally have memtest > running without error. > > Would there be any issues with that? Any better idea? > > Here is an extract from the log: > You can enable raminit logging by checking "Output verbose RAM init debug messages" in menu Debugging. It doesn't work well with cbmem logging. Regards Patrick > find_current_mrc_cache_local: No valid MRC cache found. > Revision : 11 > Type : b > Key : 3 > Banks : 8 > Capacity : 4 Gb > Supported voltages : 1.35V 1.5V > SDRAM width : 8 > Bus extension : 0 bits > Bus width : 64 > Optional features : DLL-Off_mode RZQ/7 RZQ/6 > Thermal features : PASR ext_temp_range > Thermal sensor : no > Standard SDRAM : yes > Rank1 Address bits : normal > DIMM Reference card: B > Manufacturer ID : 9e02 > Part number : CMSX16GX3M2B2133 > Not a DDR3 SPD! > Row addr bits : 16 > Column addr bits : 10 > Number of ranks : 2 > DIMM Capacity : 8192 MB > CAS latencies : 6 7 8 9 10 11 > tCKmin : 1.000 ns > tAAmin : 10.250 ns > tWRmin : 15.000 ns > tRCDmin : 10.250 ns > tRRDmin : 6.500 ns > tRPmin : 10.250 ns > tRASmin : 29.000 ns > tRCmin : 39.375 ns > tRFCmin : 260.750 ns > tWTRmin : 7.625 ns > tRTPmin : 8.375 ns > tFAWmin : 30.875 ns > channel[0] rankmap = 0x3 > Not a DDR3 SPD! > Not a DDR3 SPD! > Starting RAM training (0). > PLL busy... PLL busy... PLL busy...done > MCU frequency is set at : 800 MHz > Selected DRAM frequency: 800 MHz > Minimum CAS latency : 9T > Selected CAS latency : 9T > Selected CWL latency : 7T > Selected tRCD : 9T > Selected tRP : 9T > Selected tRAS : 24T > Selected tWR : 12T > Selected tFAW : 25T > Selected tRRD : 6T > Selected tRTP : 7T > Selected tWTR : 7T > Selected tRFC : 209T > XOVER CLK [c14] = 3000000 > XOVER CMD [320c] = 24000 > XOVER CLK [d14] = 0 > XOVER CMD [330c] = 4000 > DBP [4000] = 187999 > RAP [4004] = cc197476 > OTHP [400c] = a08b4 > ODT stretch [400c] = 0 > ODT stretch [400c] = a08b4 > REFI [4298] = 6cd11860 > SRFTP [42a4] = 41f88200 > DBP [4400] = 187999 > RAP [4404] = cc197476 > OTHP [440c] = a08b4 > ODT stretch [440c] = 0 > ODT stretch [440c] = a08b4 > REFI [4698] = 6cd11860 > SRFTP [46a4] = 41f88200 > Done dimm mapping > > MCU frequency is set at : 800 MHz > XOVER CLK [c14] = 3000000 > XOVER CMD [320c] = 24000 > XOVER CLK [d14] = 0 > XOVER CMD [330c] = 4000 > DBP [4000] = 187999 > RAP [4004] = cc197476 > OTHP [400c] = a08b4 > ODT stretch [400c] = 0 > ODT stretch [400c] = a08b4 > REFI [4298] = 6cd11860 > SRFTP [42a4] = 41f88200 > DBP [4400] = 187999 > RAP [4404] = cc197476 > OTHP [440c] = a08b4 > ODT stretch [440c] = 0 > ODT stretch [440c] = a08b4 > REFI [4698] = 6cd11860 > SRFTP [46a4] = 41f88200 > Done dimm mapping > > > For 666: > > Trying stored timings. > Starting RAM training (1). > PLL busy... PLL busy...done > MCU frequency is set at : 666 MHz > XOVER CLK [c14] = > f000000 > > XOVER CMD [320c] = 4024000 > XOVER CLK [d14] = 0 > XOVER CMD [330c] = 4000 > DBP [4000] = 146777 > RAP [4004] = ca156465 > OTHP [400c] = a0690 > ODT stretch [400c] = 0 > REFI [4298] = 5aae1450 > SRFTP [42a4] = 41f97200 > DBP [4400] = 146777 > RAP [4404] = ca156465 > OTHP [440c] = a0690 > ODT stretch [440c] = 0 > ODT stretch [440c] = a0690 > REFI [4698] = 5aae1450 > SRFTP [46a4] = 41f97200 > Done dimm mapping > > > The timestamps are: > 0:1st timestamp 1,789 > 1:start of rom stage 59,405 (57,616) > 2:before ram initialization 1,768,793 > (1,709,388) 3:after ram initialization > 1,818,226 (49,432) 4:end of > romstage 1,828,566 (10,340) > 8:starting to load ramstage 1,833,895 (5,329) > 15:starting LZMA decompress (ignore for x86) 1,833,926 (30) > 16:finished LZMA decompress (ignore for x86) 1,848,244 > (14,317) 9:finished loading ramstage > 1,848,254 (9) 10:start of ramstage > 3,186,861 (1,338,607) 30:device > enumeration 3,186,890 (29) 40:device > configuration 3,195,250 (8,359) > 50:device enable 3,207,057 > (11,806) 60:device initialization > 3,207,563 (506) 70:device setup done > 3,378,965 (171,402) 75:cbmem > post 3,378,968 (3) 80:write > tables 3,378,972 (4) 90:load > payload 3,399,267 (20,294) > 15:starting LZMA decompress (ignore for x86) 3,399,430 (163) > 16:finished LZMA decompress (ignore for x86) 3,413,428 > (13,998) 99:selfboot jump > 3,413,449 (21) > > > Full cbmem attached from various attempts (when I have more than 1 > stick in place, the log is truncated)

1 0

Re: [coreboot] Patch: support for the Lenovo Thinkpad W520
by Pok Gu 08 Nov '16

08 Nov '16

I remembered Windows 7 was not well supported under coreboot (sometimes it boots sometimes not). A fresh install of MSDN Windows 10 can at least boot everytime. Could you try if Windows 10 works? I don't known how to fix the usb issues. So I cc the community maillist. 2016-11-08 14:54 GMT+08:00 Charlotte Plusplus <pluspluscharlotte(a)gmail.com>: > I have tried to boot a windows 7 to explore these issues, it didn't work. > > I may have residual problems. I noticed I also have USB3 not working while > I have in the devicetree: > > device pci 1c.6 on end # PCIe Port #7 USB 3.0 only W520 > > I checked the specs, it is the correct address. However, it doesn't work, > and in cbmem I can see the port is being disabled :-( > > > On Mon, Nov 7, 2016 at 9:36 PM, Pok Gu <pokgoo002(a)gmail.com> wrote: > >> Hi, I'm not sure if the issue is related to power management. I'm using >> Windows and an obvious issue is there is a yellow question mark for the >> Dynamic Platform and Thermal Framework driver PCI\VEN_8086&DEV_0153. I >> googled and found some chromebooks have the dptf.asl in their source, but >> the thinkpads do not. Is this possible to be fix and how to do it? >> >> Thanks >> Pokgu >> >> 2016-11-08 3:20 GMT+08:00 Charlotte Plusplus <pluspluscharlotte(a)gmail.com >> >: >> >> >> >> I am new to coreboot. I could try to add the missing power management >> >> states. But can I please ask for pointers and suggestions? What is >> >> missing? Is there any documentation? >> > Power management is done through ACPI. >> > You'd need to figure out which ACPI functions are used by your >> operating system and implement/fix them. >> >> I am using Linux, Arch or Ubuntu. I don't really understand what you >> mean there. I thought ACPI functions for power management were quite >> standard. After reading my dmesg, I thought the linux kernel PSTATE >> and CPUFREQ drivers were working fine. I need to do more tests with >> powertop. >> >> Is the power management state complete enough from coreboot standpoint >> to work with the current linux kernel?? >> >> If not, could you point me to an Ivy Bridge board that has the most >> complete implementation of power management, so I can use it as an >> example? >> >> I see some boards have cstates support, like >> src/mainboard/lenovo/x200/cstates.c and after googling I found that >> libreboot had "Higher battery life on GM45 (X200, T400, T500, R400) >> due to higher cstates now being supported (thanks Arthur Heymans). C4 >> power states also supported. Higher battery life on i945 (X60, T60, >> MacBook2,1) due to better CPU >> C-state settings. (Deep C4, Dynamicl L2 shrinking, C2E). >> >> Patch is in: >> https://notabug.org/vimuser/libreboot/commit/89819c5ce3cd5c9 >> a38e9e7e817573dca52cbabcb >> >> 2016-11-08 3:20 GMT+08:00 Charlotte Plusplus <pluspluscharlotte(a)gmail.com >> >: >> >>> Hello >>> >>> On 11/6/16, Patrick Rudolph <siro(a)das-labor.org> wrote: >>> > thanks for adding support for W520. >>> >>> My pleasure to help! As soon as I get the RAM issues fixed, I will try >>> to add another mainboard. This was quite fun (reading the block >>> diagram, making sure the ports match, etc) >>> >>> My only real issue at the moment is the RAM. I wish I could fix that >>> soon, because I really need my laptop to work!! And since I replaced >>> the CPU by one that is not supported in the bios, coreboot is my only >>> option :-/ >>> >>> I can't even boot reliably with more than 1 ram stick inserted :-( >>> >>> > Am 06.11.2016 um 09:33 schrieb Charlotte Plusplus: >>> > Please use git ( >>> > https://www.coreboot.org/Development_Guidelines#How_to_contribute ) >>> and >>> > gerrit ( http://review.coreboot.org/#/q/status:open ) to upload your >>> > patch. This allows easy reviewing and commenting, including an >>> automatic >>> > build for every change made. >>> >>> Sorry, I haven't used git yet ever, except to download code. I thought >>> an archive would be ok. I will read your links and prepare a >>> submission in the correct format. Thanks for the explanation! >>> >>> > Please note that I didn't test anything beyond DDR3-800. Some people >>> > reported that DDR3-1866 is working. >>> > Can you try to limit max frequency to DDR3-1333 or DDR3-1600 (using >>> > max_mem_clock_mhz) and tell if it's working ? >>> >>> Currently doing that. I have read a bit more about memory, and >>> apparently it could also be due to Intel XMP. >>> >>> > Native raminit is done in >>> > coreboot/src/northbridge/intel/sandybridge/raminit.c >>> > Please have a look at this file first. I don't think that there are SPD >>> > issues, but there might be issues with frequencies of + DDR3-1600. >>> >>> I looked at that. I see you recently added XMP support: >>> https://www.coreboot.org/pipermail/coreboot-gerrit/2016-Febr >>> uary/040779.html >>> >>> The sticks I am using are Corsair CMSX16GX3M2B2133C1, which use XMP. >>> They are dual voltage, 1.35 and 1.5V >>> >>> Here is the output from decode-dimm run in the BIOS, and from >>> coreboot. I can also add screenshots from memtest86 7.1, which showed >>> the proper SPD settings and speed. Speed tests curves gave numbers >>> compatibles with 2133, which is above DDR3-1600 as bios 1.36 did not >>> restrict their speed. I did test them for over a day in memtest86 7.1. >>> >>> Since the sticks work reliably in the default bios as confirmed by >>> memtest86 71, the problem seems to be coreboot specific: memtest86+ >>> 5.0 gives me various error that never showed up before. And with one >>> stick, coreboot won't even boot. >>> >>> I don't understand how the existing raminit code could have issues >>> with frequencies over DDR3-1600. >>> >>> My best guess is it may be due to using the CL10 profile (even if it >>> is "correct") and ignoring the XMP CL11 profile, because I see the >>> current code only select the 1st XMP profile, which could be the cause >>> of the error if say the 2nd XMP profile is the one that should be >>> used. >>> >>> It all looks innocent, but it is a serious error, as one 8G sticks >>> gives me tens of thousands of errors in memtest86. I think this could >>> cause serious data corruption :-( >>> >>> >> I am new to coreboot. I could try to add the missing power management >>> >> states. But can I please ask for pointers and suggestions? What is >>> >> missing? Is there any documentation? >>> > Power management is done through ACPI. >>> > You'd need to figure out which ACPI functions are used by your >>> operating system and implement/fix them. >>> >>> I am using Linux, Arch or Ubuntu. I don't really understand what you >>> mean there. I thought ACPI functions for power management were quite >>> standard. After reading my dmesg, I thought the linux kernel PSTATE >>> and CPUFREQ drivers were working fine. I need to do more tests with >>> powertop. >>> >>> Is the power management state complete enough from coreboot standpoint >>> to work with the current linux kernel?? >>> >>> If not, could you point me to an Ivy Bridge board that has the most >>> complete implementation of power management, so I can use it as an >>> example? >>> >>> I see some boards have cstates support, like >>> src/mainboard/lenovo/x200/cstates.c and after googling I found that >>> libreboot had "Higher battery life on GM45 (X200, T400, T500, R400) >>> due to higher cstates now being supported (thanks Arthur Heymans). C4 >>> power states also supported. Higher battery life on i945 (X60, T60, >>> MacBook2,1) due to better CPU >>> C-state settings. (Deep C4, Dynamicl L2 shrinking, C2E). >>> >>> Patch is in: >>> https://notabug.org/vimuser/libreboot/commit/89819c5ce3cd5c9 >>> a38e9e7e817573dca52cbabcb >>> >>> However, I could not need documentation or explainations for the >>> numbers used (which differ in coreboot and libreboot) >>> >>> I have found http://www.intel.com/content/w >>> ww/us/en/support/processors/000006619.html >>> but that is not super helpful. >>> >>> I would be happy to write proper power management support, but I would >>> really appreciate some links to the documentation or some examples. >>> >>> A related question: how do I write a ACPI method to receive a call >>> from userland and do something on coreboot side, like write a >>> register? I would like to add a way to turn the NVidia GPU on and off >>> from userland, for bumblebee or KVM with IOMMU GPU passthrugh. >>> >>> > I'm using BeagleBone Black for USBDEBUG. >>> >>> Ok, I will get one too. Thanks to Kyosti message I understand why I >>> can't use my existing cable. >>> >>> > Once you got USBDEBUG working, please provide a full raminit log. It >>> may >>> > help to fix the remaining issue. >>> >>> Given the output from the script, I have selected port 1 This is the >>> only external USB2 port in the laptop anyway!! >>> >>> The following PCI devices support a USB debug port (says lspci): >>> 0000:00:1a.0 0000:00:1d.0 >>> The following PCI devices support a USB debug port (says the kernel): >>> 0000:00:1a.0 0000:00:1d.0 >>> PCI device 0000:00:1a.0, USB bus 1, USB physical port 2 >>> PCI device 0000:00:1d.0, USB bus 2, USB physical port 2 >>> Currently connected high-speed devices: >>> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M >>> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M >>> |__ Port 4: Dev 3, If 12, Class=Communications, Driver=cdc_mbim, >>> 480M >>> |__ Port 4: Dev 3, If 13, Class=CDC Data, Driver=cdc_mbim, 480M >>> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M >>> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M >>> |__ Port 2: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, >>> 480M >>> >>> I have ordered the BBB. It may take a day or two to arrive. In the >>> meantime, do you know any tool to dump the XMP profiles and check them >>> manually? >>> >>> Thanks >>> Charlotte >>> >>> -- >>> coreboot mailing list: coreboot(a)coreboot.org >>> https://www.coreboot.org/mailman/listinfo/coreboot >>> >> >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot >> > >

1 0

More details about ram issues
by Charlotte Plusplus 08 Nov '16

08 Nov '16

Hello I have done further ram testing. My first guess was to disable the XMP code - it didn't help, but I may have done things wrong as I was trying with a normal and a fallback mode to try more combinations of options, and apparently the ram settings are cached and shared between normal and fallback, even when max_mem_clock_mhz differ. That's not a good thing when working on ram issues, so I wonder, is there any way to manually invalidate that mrc cache during tests?? (I almost want to comment the function in raminit.c) Since I don't have a USBDEBUG yet, I go to a linux shell to check the cbmem output between tests. So anything I can type to disable the mrc cache would do. Alternatively, a really nice thing to have would be a nvram option to pass max_mem_clock_mhz without having to recompile, and invalidate this cache if the settings do not match, to cover cases like this one. Also, overclockers would love that. So this option could even be used to pass custom SPD timings, as some bios do. It would require more thinking on what to do and how, but it looks like a nice feature to me. Would it be acceptable to add that to coreboot? Anyway, I tried to downclock at various frequencies: - 666 Mhz: CAS 7-7-7-20 : all sticks work, individually and together - 800 Mhz: CAS 9-9-9-24: 1 stick doesn't work, the others do, but I still get errors during the memtest step 8. I regret it is not possible to manually enter the right SPD information that I know to work: 11-11-11-29 for DDR3-2000, 11-11-11-31 for DDR3-2133 - and something slightly larger for DDR3-1600. So I have DDR3-2133 sticks that I am forced to run at DDR3-1333 speeds because otherwise the selected SPD settings make everything unstable :-( If only I could slightly increase the latency, I could run at least at DDR3-1600 speeds with 0 error in memtest. I'm thinking of tweaking dram_find_common_params with: ctrl->tRAS = MAX(ctrl->tRAS, dimm->tRAS) +X; and manually trying X=1, X=2 etc. until I can finally have memtest running without error. Would there be any issues with that? Any better idea? Here is an extract from the log: find_current_mrc_cache_local: No valid MRC cache found. Revision : 11 Type : b Key : 3 Banks : 8 Capacity : 4 Gb Supported voltages : 1.35V 1.5V SDRAM width : 8 Bus extension : 0 bits Bus width : 64 Optional features : DLL-Off_mode RZQ/7 RZQ/6 Thermal features : PASR ext_temp_range Thermal sensor : no Standard SDRAM : yes Rank1 Address bits : normal DIMM Reference card: B Manufacturer ID : 9e02 Part number : CMSX16GX3M2B2133 Not a DDR3 SPD! Row addr bits : 16 Column addr bits : 10 Number of ranks : 2 DIMM Capacity : 8192 MB CAS latencies : 6 7 8 9 10 11 tCKmin : 1.000 ns tAAmin : 10.250 ns tWRmin : 15.000 ns tRCDmin : 10.250 ns tRRDmin : 6.500 ns tRPmin : 10.250 ns tRASmin : 29.000 ns tRCmin : 39.375 ns tRFCmin : 260.750 ns tWTRmin : 7.625 ns tRTPmin : 8.375 ns tFAWmin : 30.875 ns channel[0] rankmap = 0x3 Not a DDR3 SPD! Not a DDR3 SPD! Starting RAM training (0). PLL busy... PLL busy... PLL busy...done MCU frequency is set at : 800 MHz Selected DRAM frequency: 800 MHz Minimum CAS latency : 9T Selected CAS latency : 9T Selected CWL latency : 7T Selected tRCD : 9T Selected tRP : 9T Selected tRAS : 24T Selected tWR : 12T Selected tFAW : 25T Selected tRRD : 6T Selected tRTP : 7T Selected tWTR : 7T Selected tRFC : 209T XOVER CLK [c14] = 3000000 XOVER CMD [320c] = 24000 XOVER CLK [d14] = 0 XOVER CMD [330c] = 4000 DBP [4000] = 187999 RAP [4004] = cc197476 OTHP [400c] = a08b4 ODT stretch [400c] = 0 ODT stretch [400c] = a08b4 REFI [4298] = 6cd11860 SRFTP [42a4] = 41f88200 DBP [4400] = 187999 RAP [4404] = cc197476 OTHP [440c] = a08b4 ODT stretch [440c] = 0 ODT stretch [440c] = a08b4 REFI [4698] = 6cd11860 SRFTP [46a4] = 41f88200 Done dimm mapping MCU frequency is set at : 800 MHz XOVER CLK [c14] = 3000000 XOVER CMD [320c] = 24000 XOVER CLK [d14] = 0 XOVER CMD [330c] = 4000 DBP [4000] = 187999 RAP [4004] = cc197476 OTHP [400c] = a08b4 ODT stretch [400c] = 0 ODT stretch [400c] = a08b4 REFI [4298] = 6cd11860 SRFTP [42a4] = 41f88200 DBP [4400] = 187999 RAP [4404] = cc197476 OTHP [440c] = a08b4 ODT stretch [440c] = 0 ODT stretch [440c] = a08b4 REFI [4698] = 6cd11860 SRFTP [46a4] = 41f88200 Done dimm mapping For 666: Trying stored timings. Starting RAM training (1). PLL busy... PLL busy...done MCU frequency is set at : 666 MHz XOVER CLK [c14] = f000000 XOVER CMD [320c] = 4024000 XOVER CLK [d14] = 0 XOVER CMD [330c] = 4000 DBP [4000] = 146777 RAP [4004] = ca156465 OTHP [400c] = a0690 ODT stretch [400c] = 0 REFI [4298] = 5aae1450 SRFTP [42a4] = 41f97200 DBP [4400] = 146777 RAP [4404] = ca156465 OTHP [440c] = a0690 ODT stretch [440c] = 0 ODT stretch [440c] = a0690 REFI [4698] = 5aae1450 SRFTP [46a4] = 41f97200 Done dimm mapping The timestamps are: 0:1st timestamp 1,789 1:start of rom stage 59,405 (57,616) 2:before ram initialization 1,768,793 (1,709,388) 3:after ram initialization 1,818,226 (49,432) 4:end of romstage 1,828,566 (10,340) 8:starting to load ramstage 1,833,895 (5,329) 15:starting LZMA decompress (ignore for x86) 1,833,926 (30) 16:finished LZMA decompress (ignore for x86) 1,848,244 (14,317) 9:finished loading ramstage 1,848,254 (9) 10:start of ramstage 3,186,861 (1,338,607) 30:device enumeration 3,186,890 (29) 40:device configuration 3,195,250 (8,359) 50:device enable 3,207,057 (11,806) 60:device initialization 3,207,563 (506) 70:device setup done 3,378,965 (171,402) 75:cbmem post 3,378,968 (3) 80:write tables 3,378,972 (4) 90:load payload 3,399,267 (20,294) 15:starting LZMA decompress (ignore for x86) 3,399,430 (163) 16:finished LZMA decompress (ignore for x86) 3,413,428 (13,998) 99:selfboot jump 3,413,449 (21) Full cbmem attached from various attempts (when I have more than 1 stick in place, the log is truncated)

1 0

Re: [coreboot] Patch: support for the Lenovo Thinkpad W520
by Pok Gu 08 Nov '16

08 Nov '16

Hi, I'm not sure if the issue is related to power management. I'm using Windows and an obvious issue is there is a yellow question mark for the Dynamic Platform and Thermal Framework driver PCI\VEN_8086&DEV_0153. I googled and found some chromebooks have the dptf.asl in their source, but the thinkpads do not. Is this possible to be fix and how to do it? Thanks Pokgu 2016-11-08 3:20 GMT+08:00 Charlotte Plusplus <pluspluscharlotte(a)gmail.com>: >> I am new to coreboot. I could try to add the missing power management >> states. But can I please ask for pointers and suggestions? What is >> missing? Is there any documentation? > Power management is done through ACPI. > You'd need to figure out which ACPI functions are used by your operating system and implement/fix them. I am using Linux, Arch or Ubuntu. I don't really understand what you mean there. I thought ACPI functions for power management were quite standard. After reading my dmesg, I thought the linux kernel PSTATE and CPUFREQ drivers were working fine. I need to do more tests with powertop. Is the power management state complete enough from coreboot standpoint to work with the current linux kernel?? If not, could you point me to an Ivy Bridge board that has the most complete implementation of power management, so I can use it as an example? I see some boards have cstates support, like src/mainboard/lenovo/x200/cstates.c and after googling I found that libreboot had "Higher battery life on GM45 (X200, T400, T500, R400) due to higher cstates now being supported (thanks Arthur Heymans). C4 power states also supported. Higher battery life on i945 (X60, T60, MacBook2,1) due to better CPU C-state settings. (Deep C4, Dynamicl L2 shrinking, C2E). Patch is in: https://notabug.org/vimuser/libreboot/commit/89819c5ce3cd5c9 a38e9e7e817573dca52cbabcb 2016-11-08 3:20 GMT+08:00 Charlotte Plusplus <pluspluscharlotte(a)gmail.com>: > Hello > > On 11/6/16, Patrick Rudolph <siro(a)das-labor.org> wrote: > > thanks for adding support for W520. > > My pleasure to help! As soon as I get the RAM issues fixed, I will try > to add another mainboard. This was quite fun (reading the block > diagram, making sure the ports match, etc) > > My only real issue at the moment is the RAM. I wish I could fix that > soon, because I really need my laptop to work!! And since I replaced > the CPU by one that is not supported in the bios, coreboot is my only > option :-/ > > I can't even boot reliably with more than 1 ram stick inserted :-( > > > Am 06.11.2016 um 09:33 schrieb Charlotte Plusplus: > > Please use git ( > > https://www.coreboot.org/Development_Guidelines#How_to_contribute ) and > > gerrit ( http://review.coreboot.org/#/q/status:open ) to upload your > > patch. This allows easy reviewing and commenting, including an automatic > > build for every change made. > > Sorry, I haven't used git yet ever, except to download code. I thought > an archive would be ok. I will read your links and prepare a > submission in the correct format. Thanks for the explanation! > > > Please note that I didn't test anything beyond DDR3-800. Some people > > reported that DDR3-1866 is working. > > Can you try to limit max frequency to DDR3-1333 or DDR3-1600 (using > > max_mem_clock_mhz) and tell if it's working ? > > Currently doing that. I have read a bit more about memory, and > apparently it could also be due to Intel XMP. > > > Native raminit is done in > > coreboot/src/northbridge/intel/sandybridge/raminit.c > > Please have a look at this file first. I don't think that there are SPD > > issues, but there might be issues with frequencies of + DDR3-1600. > > I looked at that. I see you recently added XMP support: > https://www.coreboot.org/pipermail/coreboot-gerrit/ > 2016-February/040779.html > > The sticks I am using are Corsair CMSX16GX3M2B2133C1, which use XMP. > They are dual voltage, 1.35 and 1.5V > > Here is the output from decode-dimm run in the BIOS, and from > coreboot. I can also add screenshots from memtest86 7.1, which showed > the proper SPD settings and speed. Speed tests curves gave numbers > compatibles with 2133, which is above DDR3-1600 as bios 1.36 did not > restrict their speed. I did test them for over a day in memtest86 7.1. > > Since the sticks work reliably in the default bios as confirmed by > memtest86 71, the problem seems to be coreboot specific: memtest86+ > 5.0 gives me various error that never showed up before. And with one > stick, coreboot won't even boot. > > I don't understand how the existing raminit code could have issues > with frequencies over DDR3-1600. > > My best guess is it may be due to using the CL10 profile (even if it > is "correct") and ignoring the XMP CL11 profile, because I see the > current code only select the 1st XMP profile, which could be the cause > of the error if say the 2nd XMP profile is the one that should be > used. > > It all looks innocent, but it is a serious error, as one 8G sticks > gives me tens of thousands of errors in memtest86. I think this could > cause serious data corruption :-( > > >> I am new to coreboot. I could try to add the missing power management > >> states. But can I please ask for pointers and suggestions? What is > >> missing? Is there any documentation? > > Power management is done through ACPI. > > You'd need to figure out which ACPI functions are used by your > operating system and implement/fix them. > > I am using Linux, Arch or Ubuntu. I don't really understand what you > mean there. I thought ACPI functions for power management were quite > standard. After reading my dmesg, I thought the linux kernel PSTATE > and CPUFREQ drivers were working fine. I need to do more tests with > powertop. > > Is the power management state complete enough from coreboot standpoint > to work with the current linux kernel?? > > If not, could you point me to an Ivy Bridge board that has the most > complete implementation of power management, so I can use it as an > example? > > I see some boards have cstates support, like > src/mainboard/lenovo/x200/cstates.c and after googling I found that > libreboot had "Higher battery life on GM45 (X200, T400, T500, R400) > due to higher cstates now being supported (thanks Arthur Heymans). C4 > power states also supported. Higher battery life on i945 (X60, T60, > MacBook2,1) due to better CPU > C-state settings. (Deep C4, Dynamicl L2 shrinking, C2E). > > Patch is in: > https://notabug.org/vimuser/libreboot/commit/ > 89819c5ce3cd5c9a38e9e7e817573dca52cbabcb > > However, I could not need documentation or explainations for the > numbers used (which differ in coreboot and libreboot) > > I have found http://www.intel.com/content/www/us/en/support/processors/ > 000006619.html > but that is not super helpful. > > I would be happy to write proper power management support, but I would > really appreciate some links to the documentation or some examples. > > A related question: how do I write a ACPI method to receive a call > from userland and do something on coreboot side, like write a > register? I would like to add a way to turn the NVidia GPU on and off > from userland, for bumblebee or KVM with IOMMU GPU passthrugh. > > > I'm using BeagleBone Black for USBDEBUG. > > Ok, I will get one too. Thanks to Kyosti message I understand why I > can't use my existing cable. > > > Once you got USBDEBUG working, please provide a full raminit log. It may > > help to fix the remaining issue. > > Given the output from the script, I have selected port 1 This is the > only external USB2 port in the laptop anyway!! > > The following PCI devices support a USB debug port (says lspci): > 0000:00:1a.0 0000:00:1d.0 > The following PCI devices support a USB debug port (says the kernel): > 0000:00:1a.0 0000:00:1d.0 > PCI device 0000:00:1a.0, USB bus 1, USB physical port 2 > PCI device 0000:00:1d.0, USB bus 2, USB physical port 2 > Currently connected high-speed devices: > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M > |__ Port 4: Dev 3, If 12, Class=Communications, Driver=cdc_mbim, > 480M > |__ Port 4: Dev 3, If 13, Class=CDC Data, Driver=cdc_mbim, 480M > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M > |__ Port 2: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, > 480M > > I have ordered the BBB. It may take a day or two to arrive. In the > meantime, do you know any tool to dump the XMP profiles and check them > manually? > > Thanks > Charlotte > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Fund a TALOS Secure Workstation as coreboot build system
by Martin Roth 08 Nov '16

08 Nov '16

Hi Pierre, Please email me privately with the amount of your your contribution. I'll post updates with totals every few days. My plan is to post the names of the contributors (unless you wish to remain anonymous), but I don't plan to post any amounts being contributed. I'm not actually taking any money right now. If we reach our goal, I'll contact people with information on how to make the contributions. Martin On Mon, Nov 7, 2016 at 5:01 PM, Pierre P <petrik.pierre(a)hotmail.com> wrote: > Hi, > > > I'd like to help fund a build server for coreboot, how is it done ? > > > Thanks > > > Pierre > ------------------------------ > *From:* coreboot <coreboot-bounces(a)coreboot.org> on behalf of Martin Roth > <gaumless(a)gmail.com> > *Sent:* Monday, November 7, 2016 10:22:26 PM > *To:* David Hendricks > *Cc:* Paul Menzel; coreboot > *Subject:* Re: [coreboot] Fund a TALOS Secure Workstation as coreboot > build system > > Update: > After the weekend, we're up to $3700 with 5 contributors. > > Martin > > On Sun, Nov 6, 2016 at 1:01 PM, David Hendricks <david.hendricks(a)gmail.com > > wrote: > >> >> >> On Fri, Nov 4, 2016 at 9:36 AM, Martin Roth <gaumless(a)gmail.com> wrote: >> >>> Is getting a Talos workstation as a build server something that people >>> are interested in contributing money for? >>> >> >> Yes, this needs to happen. >> >> >>> So far, we've got $2500 pledged from two contributors out of the $7500 >>> needed to get a server. >>> >> >> I'll match up to $2000 worth of small/moderate pledges ($250 or less). So >> if 10 people pledge $200 I'll chip in $2000 to bring us to $6500. >> > >

1 0

← Newer
1
...
12
13
14
15
16
17
18
19
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot November 2016