Re: [coreboot] Supported laptops (again), treacherous computing
On Wed, Jul 24, 2013 at 03:51:55PM +0400, Nikita Karetnikov wrote: Would you like to try that? I'm willing to help if it's somehow possible with QEMU (and without proprietary programs). What instructions should be used? Could you provide a step-by-step guide? I don't think you can do this test with QEMU and without propietary software. You need a real CPU and the propietary software that comes inside it from factory. It's basically testing if the version of microcode shipped from factory works or needs the updated microcode. I believe we don't know the reasons the microcode was updated, so we don't know what the bugs solved, if any, were. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Microcodes
On Sat, Apr 06, 2013 at 02:47:06PM +0200, Denis 'GNUtoo' Carikli wrote: Is the inclusion of the microcode in GPLv2 source code compatible with the GPLv2? I think the correct thing legally would be to load the microcode from a file (or let the CPU work with the factory microcode and not update it). But IANAL and it all may depend on what is considered a derived work on each jurisdiction. In the end there's going to be a .rom file that will include the GPL code and the propietary microcode, but that rom file might not be regarded as a derived work of the GPL code but an aggregation of differently licensed works, at least if it is separated in a file in CBFS and not #included . Some years ago I think I suggested this potential risk but since I (or anyone) didn't write the code to load it from outside coreboot, it didn't go any further. I don't know how it is now. I was trying to have my CPU (AMD, not Intel) boot without updating its microcode. I did get further without updating microcode that updating it, but the furthest I got was to load and start booting linux-libre. The kernel wasn't able to mount the root filesystem and I run out of time trying to fix it. The thread is here (about AMD, mind you) http://marc.info/?l=linuxbiosm=129814821921378w=4 http://marc.info/?l=linuxbiosm=129880053021153w=4 The third question is the following: Which CPU(or laptop, or mainboard+CPU) still work without the microcode and which doesn't. I don't know. I'm told some don't work well without microcode updates, mine seems to work better without microcode updates, but I can't confirm it because I didn't get the whole system to work. It possibly depends on the available microcode. It's not going to be good to update a CPU with microcode for another model. I guess the microcode that comes from factory, without microcode updates, should work. It is designed to work. But then there may be bugs, and that's why they issue new versions of microcode which can reach or not coreboot. The hardware design, the microcode design and the bugs are possibly all secrets, so there's no way to know if applying the update is really needed in some scenario. So people trust the only party with the information (the CPU company) and apply the updates just in case. The kernel may also try to update microcode if you don't tell it otherwise. Just in advance of what you could find next: I was also told that some versions of Intel CPUs can't even access RAM if they don't boot some propietary signed code (the boot CPU inside the CPU checks the signature before running it). This is no microcode, but it is propietary (and unchangeable even if it could be reverse engineered, unless you find some exploitable vulnerability). If my memory serves this code is not in the coreboot repository, but must be included in the rom image to boot those intel CPUs. That suggests to me that it is an external file and does not fall under GPL, so it seems it is both legal and maybe a clue if someone wants to extract microcode so that coreboot loads it from CBFS, but I haven't checked how it is done and IANAL. http://www.coreboot.org/pipermail/coreboot/2012-April/069598.html -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] building a coreboot (and 100% free software) compatible box
On Thu, Feb 07, 2013 at 08:52:47PM +0100, Denis 'GNUtoo' Carikli wrote: on the radeon of the M4A785T-M (01:05.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RS880 [Radeon HD 4200]) it can: some time ago I commented the VGA option rom running but kept it in memory and it worked(the linux kernel initialized the card). it can also work without the firmware but has no 3D acceleration nor video acceleration(XV). I believe from linux 3.7 up there is no longer option for UMS in radeon, and KMS needs the nonfree firmware. I didn't try without the nvidia option rom yet...I really should. The nvidia card even has 3D acceleration with the free firmware. Yes I think nouveau does not need the VGA BIOS, but I haven't tried. May depend on gpu model. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] building a coreboot (and 100% free software) compatible box
On Thu, Feb 07, 2013 at 04:13:00PM +0100, Kristóf, Csillag wrote: It seems that you are right. Yes, I'm afraid we lose. I'd love to hear about any success however, I'd be interested in such a system. At least with regards to freedom my requirements are the same, performance and features are more relaxed. And a little graphics power would be fine (NV50 will do). Another secondary requirement for me would be little maintenance, so the least custom software and the more use of debian repositories or similar, the better. I am now looking at MIPS hardware built by Lemote. My yeeloong has poor performance. Maybe because of the unoptimized software, but the desktop is not very responsive and browsers regurarly crash. I think it worked better before I installed wheezy and then started to compile some packages with loongsoon flags. I don't spend enough time looking at it. I may try parabola some day. Console and some tasks are fine, though. That fulfills 1.1, but not much else... Indeed. But I've heard they're working on newer MIPS processors, not sure about the freedom requirements for those or what will be available when. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Binary blobs in the source tree (was: Re: New patch to review for coreboot: e4fc528 Add the memory reference code binary for sandybridge chipsets)
Sorry for the rant, it's not aimed at any particular person, just to blobs which I don't think should get into coreboot. On Mon, Apr 16, 2012 at 08:53:56AM +0100, Andrew Goodbody wrote: To be honest I don't see the difference between having binary blobs in a separate repo and having them in the main coreboot repo. Apart that is from the slightly meaningless saying that the whole coreboot tree is GPL compatible. It seems more relevant to be able to say that about a particular port. So AMD chipsets will be fully GPL whereas Intel chipsets will not. This is regardless of where the blobs are actually stored. And aside of the question of where and how microcode is executed. Of course it is relevant to say a whole project is GPL compatible, or free, or even any other property. Software isn't just a bunch of features and a bit string. It is a work that evolves through time, that's why people spend effort on maintanability and that's why the choice of licenses sets a shared plan on what committers agree. When you use a piece of software you invest some effort because you have some expectations not only on current features but on future possibilities. There's a capital to waste when changing directions. I've not helped this effort much so it's not for me to decide, but if coreboot starts filling with blobs it will be just another BIOS, only somewhat delayed or playing catchup with some features. In the past I've bought hardware believing it was likely to work with free firmware by looking at what coreboot supports. Recently I thought I might buy a chromebook if they finally run coreboot. But if coreboot becomes a blob loader I won't buy any hardware based on the fact that it runs coreboot. Coreboot would no longer be what it was to me. If someone forks a coreboot-libre then I may follow that, otherwise, it will be like what linux has become, you no longer know much by the statement that linux runs on something. If android is free software why should it be so hard to replace it with something else on some hardware? Does it have something to do with it accomodating too many propietary complements? It is pervasive, it has a big growth, it has many users. Yet it doesn't give them quite enough freedom. Coreboot may choose to go that route or may try to go the way of many other free software projects (GCC, Apache, debian...) So the big question is really do we allow chipset support that requires the use of binary blobs in coreboot. I don't. I try to find chipsets that don't require that. If yes then those blobs may as well reside in the coreboot repo as anywhere else because you're going to need them to build a port. I don't think such a limited port is worth people's efforts, but that's for each one to decide, of course. There are other propietary BIOSes around for that hardware, a free port to any hardware is worthwhile, a greenwashed half baked port of something that used to be free is not a big deal. I know it's still a lot of work in the free code for intel chipsets, but if the memory controller (which I hear is one of the most difficult parts) or such or such can't be understood or repaired, and the propietary BIOS you got preinstalled from factory does the job, I don't see much point in making or using a port. In my view microcode and MRC are roughly equivalent. The method of executing the microcode is just different and that microcode is executed by the CPU in a different operating mode but it most certainly does go away and come back and the CPU state has changed by doing so. Well, yes, I'm not very comfortable with microcode updates either. Yet, the fact I'm not comfortable with two things does not mean they are equal. I'm not very up to date, but if microcode is now loaded from the cbfs (it wasn't when I last looked, long ago, before git), then at least it has some legal advantages. Stuff you link at runtime is susceptible to form a derived work, at least under some interpretations (IANAL, and not sure at all calling some blob code needs any linking or anything that can be seen as creating derived works). Stuff you load from flash to hardware (from one EPROM to another, in fact) might not be construed as derived work. Besides, microcode can be redistributed even if it is not free. Does someone else besides intel and google have permission to distribute the blobs? coreboot users have usually assumed they had permission to distribute the tree freely under GPL, not necessarily sending people to a single repository because the parties with distribution rights have designated it as distribution means. I mean people can publish their git trees anywhere, can't they? Must they now prune the blobs or ask intel for permission ? People who is used to collaborate in a certain way even if it has historically meant incomplete hardware support may feel less inclined to collaborate when it is not sure their contributions will be used in the way they expect, or when they have
Re: [coreboot] M.Sc. thesis on x86 firmware alternatives
On Tue, Jan 10, 2012 at 10:41:49PM +0100, Paul Menzel wrote: Am Dienstag, den 10.01.2012, 19:50 +0100 schrieb Denis 'GNUtoo' Carikli: Thanks a lot I second that! Thank you very much and congrats for finishing your thesis. +1 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Patch set updated for coreboot: b0cd5ca Add AMD Family 10h PH-EO support
On Tue, Sep 13, 2011 at 12:18:24PM +0200, Paul Menzel wrote: src/vendorcode/amd/agesa/f12/Proc/CPU/Family/0x10/RevE /F10MicrocodePatch01bf.c 2. I do not understand the commit message. What do you mean with patch file? In this patch you are only adding a header file. It is adding microcode patches to a header file. The lines added contain binary patches for a binary interpreter/program/something stored in the CPU that is called microcode. Roughly, there's some kind of EPROM (or ROM+shadow RAM or some form of memory) in the CPU that gets indexed by x86 opcodes and other inputs and outputs control signals to drive the CPU circuitry in a way consistent with the instruction set semantics and CPU specification. The information in this EPROM is the microcode. The content in the altered source file is not a new copy of the microcode but just parts of it presumably with some control information about which version it is or which it should replace and where to apply the code portions, or whatever. That's why the original file had MicrocodePatch in its name. I don't know many more details, since neither the microcode source, the language it is written in or the CPU design are public at all, but I think it is enough to understand why QingPei Wang called it patch file. You can't say I add microcode for revision E Fam 10 CPUs because the file does not contain the whole microcode of the CPU, just some (small?) modifications to the microcode contained in the CPU as shipped from factory. patch file is not talking of a patch to the coreboot code, but of a patch to the microcode, the whole binary patch will be contained in the coreboot image if you so compile it. Call the patch set sent metapatch if you like. I agree that initial capital case is clearer, although I don't see it so important as to raise it. The only reason I can imagine for not taking the patch set (updated later) is lack of extensive tests or license compatibility, but both would apply to microcode already in coreboot so my guess is it'll be merged. Thanks for reviewing contributions. And thanks to contributors. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot support/port for Asus M3A78-EM matherboard?
On Wed, Aug 24, 2011 at 03:37:58PM -0700, SAL-e wrote: Hi, I have old Asus M3A78-EM [1] board inside my HTPC. I'm looking to speed up the boot process of my HTPC. I have heard that coreboot can boot directly into Linux or GRUB. I checked the supported list and found out that my board is not on the list, but at the same time I see that very similar board Asus M4A78-EM [2] is on and supported well. So I am wondering how difficult and how much work wold be required to port coreboot to my board. I'm not the best one to answer, I've been trying to get my M4A77TD-PRO to boot for one year or more and it only loads FILO, SeaBIOS + GRUB and then linux but linux can't find the disks (the same disk that the three payload read without problem). There's a FAQ which tells you the information you can send to the list to enable people to advise you better: http://www.coreboot.org/FAQ#Will_coreboot_work_on_my_machine.3F From what I see in the Asus web you link to, the two boards are not that similar. They have the same southbridge but they're different sockets. M3A78-EM is AM2 / AM2+ . I haven't checked the coreboot support for that, but maybe there's some other supported board more similar than M4A78-EM (AM3)? maybe mahogany_fam10 ? It might depend on the CPU model too, or the SuperIO. There's not enough info to tell, but for the existing info it does not seem a very difficult case. The socket and southbridge are used in other supported boards. But it's not going to be compile and install. You'll need spare flash chips, a serial port cable, and define a new board, mostly by copying from elsewhere, testing, etc. As far as I can tell the chips are documented and similar code to copy from should be there. Secondary question would be if I have to upgrade my HTPC witch board would be better for using with coreboot: Intel i3-2100T based system or AMD E-350 based? In general AMD works much better for coreboot, because AMD contributes much code to coreboot and has detailed documentation published in developer.amd.com . Intel does not help coreboot, usually requires NDAs (from what I hear) for disclosing documentation and it looks more like a guessing game. In particular I hear people are using E-350 with coreboot, although I don't remember the details. Thank you, SAL-e [1] http://www.asus.com/Motherboards/AMD_AM2Plus/M3A78EM/ [2] http://www.asus.com/Motherboards/AMD_AM2Plus/M4A78EM/ PS. Please replay directly or CC in your reply to me, because I am not member of the list yet. 10x -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Do they preinstall coreboot from factory already ?
I've just seen these news about a new vehicle PC with 5 seconds boot time thanks to coreboot, but there is no information on pricing, software (if any, maybe it is sold without hard disks ?) or firmware (apparently they would ship it with coreboot, but the datasheet does only say supports AMD Coreboot technology, which might mean that the user can install it and it should work, although I'd think it's more likely to mean it comes preinstalled. If so it may even be tempting. Pity my only vehicles are bicyles and I'm not sure what to use the 1.5 kg + disks + screen+ power source for while riding... I guess you can also use it at home, but I wonder about the price (no , I'm not going to ask them because I wasn't thinking of buying a new computer now, but I'm curious). http://www.linuxfordevices.com/c/a/News/Portwell-PCS8277/ http://www.portwell.com/products/detail.asp?CUSTCHAR1=PCS-8277#order In any case, congratulations all, it looks like another milestone. Time to start a new section in the web about where to buy? -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] AMD Phenom II 1055T was : Hackaton in Prague 2011
On Sat, Jul 09, 2011 at 05:04:43PM +0200, Florentin Demetrescu wrote: - my objective was to install coreboot on my new board MA785GMT-UDH2. I had bring with me a Phenom II 1055T CPU with 6 cores. Unfortunately I met big problems because: [...] coreboot and give it a run, but I will do that ASAP! Also I will investigate the problem of the 6 core Phenom II on this board.. Isn't it a fam 10 revision E CPU ? Coreboot did not have any code specific for Fam 10 rev E last time I checked (mid feb 2011) (no errata workarounds, no specific initialization, just a small untested part in fidvid.c). There wasn't even a constant defined for rev E. Back in August 2010 I asked how to extend the revision bitfield that's used as a trigger for rule based initializations and workarounds, and in a small thread it was suggested to get rid of it and use a struct, but I never did. http://www.coreboot.org/pipermail/coreboot/2010-August/059701.html -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Mail from a student who wants to apply for coreboot GSoC project
On Mon, Mar 28, 2011 at 11:06:55AM +0800, Hamo wrote: All of the free bootloaders now are focus on embedded systems, but with the development of ARM architecture, it will not only be used on embedded systems but also servers and low power consumption PCs. So we need a full-function bootloader for them. I see. Thanks for explaining. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Mail from a student who wants to apply for coreboot GSoC project
On Sat, Mar 26, 2011 at 10:58:54PM +0800, Hamo wrote: Hi lists, This is a student from China who wants to apply for coreboot GSoC project. I am now studying Computer Science and Technology in Hebei University of Technology, which is a key university in China. I ardently love low-level developing. For this project, I want to do something on ARM. So I want to help finish the idea that porting coreboot to Marvell ARM SOC's with PCIe. Can someone give me some suggestions? I don't know much and can't speak for coreboot, but have you looked at free bootloaders for ARM ? I thought coreboot was centered in x86 because it was a popular arquitecure and it usually lacks free firmware, while ARM or MIPS are most often used with free bootloaders already. Might it be better to add PCIe (if not present) to one of those, say U-boot or something ? What would be the advantages of porting coreboot to ARM ? -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [GSoC] Coreboot Spice Payload
On Mon, Mar 21, 2011 at 01:49:49PM -0400, Leandro Dorileo wrote: Excuse my ignorace, but you say : [1] - http://vps.dorilex.net/~dorileo/coreboot-spice-payload.txt 3. Coreboot Spice Payload Spice building blocks are Spice protocol, Spice server and spice client, the Coreboot Spice Payload fits on client component. The component will be an interface between the current devices(Video, keyboard, mouse, etc.) and the virtualized guest OS. Do you mean some kind of SerialICE? (which accesses hardware registers and sends the information to the serial port and applies I/O commands it gets from the serial port to the hardware, so that you can put a modified emulator at the other side and run the firmware/software that you would run on the machine SerialICE is ). If so, SerialICE isn't a payload, it's a replacement for coreboot who can proxy what a remote coreboot does. The remote side has a coreboot, payload and OS. I mean coreboot does not load serialICE, it is SerialICE who boots up and starts listening for commands. In any case, if you write some sort of network backed SerialICE, it won't allow you to have a desktop experience in a low end machine, because it will still be the low end machine executing the instructions it gets from somewhere. Those instructions might be a lightweight OS and a remote desktop client of some kind, but it won't run any faster (only slower) than if you directly installed the OS and client in the low end machine. 4. Payload Main Tasks The Coreboot Spice Payload main tasks involve hardware interruption handling, spice commands dispatching and response rendering. Beyond the hardware and command handling the payload will provide a basic configuration interface so host address and SSL can be set. 4.1 Libpayload CSPLD will rely on libpayload drivers for keyboard, serial and video. Which drivers ? Are there drivers for video in libpayload ? For which VGAs ? I think there's going to be a similar effort as to that of building an OS and its drivers if you don't want to load an OS on the client. My understanding is that coreboot/payloads only initialize the CPU, chipset, memory, buses and the minimum devices they need for debug and loading and OS. It is the OS who recognizes the different possible mouses, vgas, network cards, etc., the OS loads the appropiate drivers and applications (such as sshd, rdp, vnc, X or whatever) can then use them. If you want to get rid of the OS and applications you will have to rewrite their functionality, which isn't a summer job. Let's suppose the user want to move a window and the processing that calculates the next image (which other windows parts are shown or hidden, any animation, etc.) is done in a remote computer. The image still has to be sent (however compressed or optimized) and the client has to show it on screen. So you need a video driver, a mouse driver, knowledge of the monitor, mouse, their resolutions and protocols... I don't think there's such a thing in coreboot or libpayload. But maybe I just haven't understood the idea. In fact I know nothing about virtualization, but my notion is that with vitualization you get more than one OS in a physical machine, I don't see how you can get 0 OSes. With coreboot you can certainly avoid loading an OS, but then the payload will have to do all the useful functionality. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Support for Core i3 and better
On Fri, Mar 11, 2011 at 05:49:50PM +0200, Alex G. wrote: 1. Does Coreboot work with Phenom II Thuban CPU ? I want 6-core CPU of Phenom2 It's supported. I didn't know this had been tested. It's a little difficult for me to keep track of all mail in the list. http://www.coreboot.org/Supported_Chipsets_and_Devices says [only?] FAM10 revisions B0-B3 are supported. My Phenom II X4 910e is rev RB_C3 and still doesn't boot (although I no longer think it's the CPU but the southbridge, I can't confirm either until I can boot). According to http://en.wikipedia.org/wiki/List_of_AMD_Phenom_microprocessors#Phenom_series all Phenom II X6 would be revision E0 (one could look at more authoritative sources, maybe) In theory many revisions should work. In practice there are some constants in src/northbridge/amd/amdmct/amddefs.h which allocate one bit in a 32 bit value for each revision. Then these are used to build masks to test whether to apply workarounds for CPU errata or particular initializations (like in src/cpu/amd/model_10xxx/defaults.h). Some revisions (beyond HY_D0, I think), don't fit in these 32 bits. I suspect those revisions may not work, but maybe these revisions might work because they just don't need workarounds, etc. I even sent some patches that would only make sense for revision E and they were committed, but I couldn't test them (I sent them precisely because I thought no revision E CPU had been used with coreboot, so I couldn't break anything that worked before, just hopefully add a small part to support future work). It might be good to collect a list of tested CPU revisions and maybe any issues found or any tests performed, if the supported chipsets page is out of date for FAM10. I'm sorry I can't contribute to this list though, until my board boots. P.S. Whether E0 works or not, there's good documentation for it, so it is fixable. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] disabling microcode update
On Sat, Feb 26, 2011 at 03:53:43AM +0200, Alex G. wrote: On 02/26/2011 03:39 AM, xdrudis wrote: This patch tries to fix compilation when you select EXPERT in make menuconfig. HT Frequencies are multiples of 200MHz AFAIK, so there are no 300MHz and 500MHz. I'm not sure why the build breaks, and why this fixes it, but I don't think this is the right solution. Someone wiser should comment on this. Oh! You may well be right. All others are multiples of 200 MHz . Then we should maybe remove 2 #elif in the following code. But I wonder whether the break in the progression of values indicates that all values from there on should be changed too. I have no idea what this does, other than the Kconfig help: choice prompt HyperTransport frequency default LIMIT_HT_SPEED_AUTO help This option sets the maximum permissible HyperTransport link frequency. Use of this option will only limit the autodetected HT frequency. It will not (and cannot) increase the frequency beyond the autodetected limits. This is primarily used to work around poorly designed or laid out HT traces on certain motherboards. The code where it is used is in src/northbridge/amd/amdht/h3finit.c:1330 #if CONFIG_EXPERT CONFIG_LIMIT_HT_SPEED_200 cbPCBFreqLimit = 0x0001; #elif CONFIG_EXPERT CONFIG_LIMIT_HT_SPEED_300 cbPCBFreqLimit = 0x0003; #elif CONFIG_EXPERT CONFIG_LIMIT_HT_SPEED_400 cbPCBFreqLimit = 0x0007; #elif CONFIG_EXPERT CONFIG_LIMIT_HT_SPEED_500 cbPCBFreqLimit = 0x000F; #elif CONFIG_EXPERT CONFIG_LIMIT_HT_SPEED_600 cbPCBFreqLimit = 0x001F; #elif CONFIG_EXPERT CONFIG_LIMIT_HT_SPEED_800 cbPCBFreqLimit = 0x003F; #elif CONFIG_EXPERT CONFIG_LIMIT_HT_SPEED_1000 cbPCBFreqLimit = 0x007F; #elif CONFIG_EXPERT CONFIG_LIMIT_HT_SPEED_1200 cbPCBFreqLimit = 0x00FF; #elif CONFIG_EXPERT CONFIG_LIMIT_HT_SPEED_1400 cbPCBFreqLimit = 0x01FF; #elif CONFIG_EXPERT CONFIG_LIMIT_HT_SPEED_1600 cbPCBFreqLimit = 0x03FF; #elif CONFIG_EXPERT CONFIG_LIMIT_HT_SPEED_1800 cbPCBFreqLimit = 0x07FF; #elif CONFIG_EXPERT CONFIG_LIMIT_HT_SPEED_2000 cbPCBFreqLimit = 0x0FFF; #elif CONFIG_EXPERT CONFIG_LIMIT_HT_SPEED_2200 cbPCBFreqLimit = 0x1FFF; #elif CONFIG_EXPERT CONFIG_LIMIT_HT_SPEED_2400 cbPCBFreqLimit = 0x3FFF; #elif CONFIG_EXPERT CONFIG_LIMIT_HT_SPEED_2600 cbPCBFreqLimit = 0x7FFF; #else cbPCBFreqLimit = 0x;// Maximum allowed by autoconfiguration #endif -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] disabling microcode update
On Sat, Feb 26, 2011 at 04:01:56AM +0200, Alex G. wrote: On 02/26/2011 03:38 AM, xdrudis wrote: This is the patch for option B. You may not be able to test it without my next patch. At least for me selectiong EXPERT in make menuconfig breaks the build. Next patch fixes it. I don't like the wording for the help option. Stefan Reinauer didn't like it either and I'm not sure he does now. I got no suggestions (alternative wordings) so I changed only the particulars he pointed to. Feel free to improve it. [note: this pretty much summarised the other 120 lines, in case you don't read it all] It creates the impression that the entire reason for this option is purely philosophical. Not having the source, documentation and specific expertise is a philosophical problem but not only a philosophical problem. One of the consequences is that I can not give any satisfactory practical reasons for updating or not updating microcode. All I could write would be Select this to apply non-free patches to the cpu microcode provided by AMD to correct issues in the CPU after production, and distributed with coreboot (not necessarily the latest microcode version produced by AMD, but only applied if newer than the version in your CPU). The microcode patches are selected from mainboard Kconfig AMD_UCODE_PATCH_FILE among the src/cpu/amd/model_10xxx/mc_*.h files provided by AMD. We don't know the issues solved by each microcode patch file, the issues created by each file (possibly solved in other patches present in or absent from coreboot) or the preconditions to apply them to your particular CPU or to the set of CPUs the image you're configuring may run on. We know the intent of the patches is to solve issues and that we've had systems running well with the patches and issues also solved by not applying them. Unselect to let FAM10 CPUs run with the unpatched microcode as shipped from factory. If you unselect this, no binary microcode patches will be included in the image, so it will help you get an image which you have the entire source code for and may simplify license compliance. But since Stefan didn't like IANAL, I bet he won't like this either. And maybe others here know more than what I just wrote, or it's published somewhere, it's just that for philosophical reasons, and the practical reason that it seems to work without updating microcode for me, I'm not interested in investigating the microcode details, and I suspect as much of Ivaylo. Maybe Ivaylo and I picked the wrong mc*.h file, maybe the right one isn't there, maybe the checks before the microcode update are somehow wrong, maybe our CPU is newer than the mc*.h files and it somehow fools the checks, maybe it's just wrong to have AMD_UCODE_PATCH_FILE as a mainboard option, and a rutime check should select, for each processor, beetwen all microcode patches available, so that a coreboot image could run on any CPU revision you can put on that board and socket. But I can't get past maybe. I accepted your argument for this option because you quoted practical reasons, such as the updated microcode causing problems, and thus I would prefer a help text focusing on those reasons. The practical reasons are that not updating microcode is a shortcut through a few unknowns, and it may work better or worse than updating it (certainly better for me an Ivaylo, but I don't write the help for us). Since it has been previously stated that kconfig help shouldn't be qualified with uncertainity valuations but just express correct facts to the best of our knowledge, I'm unable to express the practical reasons without hinting at uncertain facts. The only certain facts are that in some cases it works better without updating and in some (many?) others it works updating. I think too that in some cases it doesn't work without updating, but I don't have a concrete case to show (no fool has tried?). I fail to see how saying this can help. It could maybe help to specify the details of when it works updating or when it works not updating, but since I don't have source, documentation or expertise, I cannot guess what are the circumstances that cause it, I could only give every complete setup for each collection of cases, which seems too detailed and verbose. Should I say ASUS M4A77TD-PRO with Phenom X4 910e or rev RB_C3 in SVI or DDR3 with AM3 ? That is not to say to avoid the philosophical issue altogether, but not invoke it as the main reason. I think you overestimate the philosophical nature of practical reasons such as a simpler license compliance or working with a source backed code base. Of course they carry philosophical questions of no small importance and even epistemological questions here noted, but less legal
Re: [coreboot] [PATCH] disabling microcode update
On Sat, Feb 26, 2011 at 07:17:46PM +0100, Peter Stuge wrote: xdrudis wrote: HT Frequencies are multiples of 200MHz AFAIK, so there are no 300MHz and 500MHz. .. Oh! You may well be right. All others are multiples of 200 MHz . Then we should maybe remove 2 #elif in the following code. But I wonder whether the break in the progression of values indicates that all values from there on should be changed too. A safer change might be: #elif CONFIG_EXPERT CONFIG_LIMIT_HT_SPEED_300 #elif CONFIG_EXPERT CONFIG_LIMIT_HT_SPEED_500 #elif CONFIG_EXPERT defined(CONFIG_LIMIT_HT_SPEED_300) CONFIG_LIMIT_HT_SPEED_300 #elif CONFIG_EXPERT defined(CONFIG_LIMIT_HT_SPEED_500) CONFIG_LIMIT_HT_SPEED_500 I would ack that if it builds. I'd rather wait to see if someone who understands the code knows whether 300 and 500 make sense (then we define them as in my patch) or they don't (then we eliminate the #elif and maybe modify some values around there). What you propose just defers the real question to Kconfig. Besides, without my patch, I don't think CONFIG_LIMIT_HT_SPEED_300 and CONFIG_LIMIT_HT_SPEED_500 are defined anyware, so you're solution is equivalent to eliminaing the #elif. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] disabling microcode update
On Sat, Feb 26, 2011 at 11:22:17PM +0200, Alex G. wrote: I look at the microcode as simply DIP switches used to configure the IRQ line on the hardware. If the manual (microcode updates) gives me erroneous information, then I put the switches back to their initial position (factory microcode). You will disagree and say that, as long as it can be updated, and source code exists for it, it is software, not hardware. Let's leave this aside. If it was a picture of something nice instead of microcode you would still have legal complications depending on the license. When you include a work in another you create a derivative work and need permission from the copyright holders of both. No one asks you what the works are (ok, yes, they do, but that's for details). You can translate that to ethical terms about using the work of others respecting their conditions if you wish. How about something simple, such as Unselect this option if you do not wish coreboot to update the CPU microcode, or if you experience issues arising from updating the microcode. Shouldn't we tell something about how to tell an issue arises from updating the microcode? I can't. Other than trying to disable it. Note that microcode updates are designed to fix issues and bugs in the CPU. Also most operating systems will update the automatically, so you may still end up running with an updated microcode. Good You may, at your option, select to disable microcode updating if you believe it to be in violation with your views on software freedom. If unsure, select y. This is accurate to the best of my knowleddge. I think it misses three facts: - the issues arising from the microcode updates have been observed (are not hypothetical). But this is not giving much information either. - the license of the microcode patches is not free (how can you believe it to be in violation of freedom if you're not told this?) - coreboot does not include all microcode updates ever produced by the manufacturer (my intention is to be fair if some issue is not due to something in the microcode patch but to misapplication by coreboot or lack of fresher updates). But I don't care. I can accept your text. It's an expert option, shouldn't need a perfect help. IANAL, while a fact, is irrelevant in a help menu. Your profession, or mine for that reason, has no relevance in the context of deciding whether or not to disallow microcode updates. If one reason is legal complications, and who says it is not a lawyer, it's relevant. I think the objections where more about : there's no I in a Kconfig file that can be lawyer or not, and uncertainity is to be avoided because it has an unprofessional look and is perceived as complicating usage . We want coreboot to be practical. The maybe can fill up a text file larger than the coreboot source. We don't care. If disabling microcode updates works for you, that is sufficient reason to consider this option Certainly. I wasn't pretending to put that text in the help, only explaining why I couldn't put anything useful. And yet we still do update the microcode for the majority of users, This has ethical consequences but might be made legally simpler by reading microcode patches from external files. and we even ship it to you when you download the coreboot source. in the source it is more an agregation that a derived work. It's compiling that makes the derived work. Or maybe I'm confused. There is practicality arising from thought alone, only giving you the choice to exire from the complications the rest of us subject ourselves to, if any. I didn't understand, sorry. It almost an unwritten law ,not just in coreboot, but in anythat ones first patch will not get accepted without at least a revision. It is a I hope no patch is accepted without a revision, first or otherwise. This is not exclusive of coreboot, and it is good policy. because of points of view differing, or the mud getting too deep. You should only quit if you feel you lost interest, or rather, if you stop feeling any interest. Whether you are laying down your arms from Right, I'm not interested in refining this patch further [nor in power, masculinity, initiation rites, survival by programming firmware or many other things]. It's also nice to quit when you feel you cannot offer anything useful. We only live so long. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] disabling microcode update
This is the patch for option B. You may not be able to test it without my next patch. At least for me selectiong EXPERT in make menuconfig breaks the build. Next patch fixes it. Make patching cpu microcode optional (for experts). It's been requested to not link update_microcode.c in that case, and therefore we have to comment all uses. Signed-off-by: Xavi Drudis Ferran xdru...@tinet.cat --- Please apply with -p 1 --- coreboot-r6380/src/cpu/amd/model_10xxx/init_cpus.c 2011-02-25 23:54:12.0 +0100 +++ coreboot-disupducode/src/cpu/amd/model_10xxx/init_cpus.c 2011-02-26 01:46:19.0 +0100 @@ -325,7 +325,9 @@ * This happens after HTinit. * The BSP runs this code in it's own path. */ +#if CONFIG_UPDATE_CPU_MICROCODE == 1 update_microcode(cpuid_eax(1)); +#endif cpuSetAMDMSR(); #if CONFIG_SET_FIDVID diff -ru coreboot-r6380/src/cpu/amd/model_10xxx/Kconfig coreboot-disupducode/src/cpu/amd/model_10xxx/Kconfig --- coreboot-r6380/src/cpu/amd/model_10xxx/Kconfig 2011-02-25 23:54:12.0 +0100 +++ coreboot-disupducode/src/cpu/amd/model_10xxx/Kconfig 2011-02-26 00:59:20.0 +0100 @@ -50,3 +50,26 @@ endif endif + +config UPDATE_CPU_MICROCODE + bool + default y + +config UPDATE_CPU_MICROCODE +bool Update cpu microcode +default y +depends on EXPERT CPU_AMD_MODEL_10XXX +help + Select this to apply non-free patches to the cpu + microcode provided by AMD to correct issues in the CPU after + production, and distributed with coreboot (not necessarily + the latest microcode version produced by AMD, but only + applied if newer than the version in your CPU). + + Unselect to let FAM10 CPUs run with the unpatched microcode + as shipped from factory. If you unselect this, no binary + microcode patches will be included in the image, so it will + help you get an image which you have the entire source code + for and may simplify license compliance. + + diff -ru coreboot-r6380/src/cpu/amd/model_10xxx/Makefile.inc coreboot-disupducode/src/cpu/amd/model_10xxx/Makefile.inc --- coreboot-r6380/src/cpu/amd/model_10xxx/Makefile.inc 2011-02-25 23:54:12.0 +0100 +++ coreboot-disupducode/src/cpu/amd/model_10xxx/Makefile.inc 2011-02-26 00:04:56.0 +0100 @@ -1,5 +1,4 @@ -# no conditionals here. If you include this file from a socket, then you get all the binaries. driver-y += model_10xxx_init.c -ramstage-y += update_microcode.c +ramstage-$(CONFIG_UPDATE_CPU_MICROCODE) += update_microcode.c ramstage-y += apic_timer.c ramstage-y += processor_name.c diff -ru coreboot-r6380/src/mainboard/amd/bimini_fam10/romstage.c coreboot-disupducode/src/mainboard/amd/bimini_fam10/romstage.c --- coreboot-r6380/src/mainboard/amd/bimini_fam10/romstage.c 2011-02-25 23:54:27.0 +0100 +++ coreboot-disupducode/src/mainboard/amd/bimini_fam10/romstage.c 2011-02-26 00:14:15.0 +0100 @@ -66,7 +66,11 @@ #include cpu/amd/quadcore/quadcore.c #include cpu/amd/car/post_cache_as_ram.c #include cpu/amd/microcode/microcode.c + +#if CONFIG_UPDATE_CPU_MICROCODE==1 #include cpu/amd/model_10xxx/update_microcode.c +#endif + #include cpu/amd/model_10xxx/init_cpus.c #include northbridge/amd/amdfam10/early_ht.c @@ -132,7 +136,10 @@ /* Setup sysinfo defaults */ set_sysinfo_in_ram(0); +#if CONFIG_UPDATE_CPU_MICROCODE==1 update_microcode(val); +#endif + post_code(0x33); cpuSetAMDMSR(); diff -ru coreboot-r6380/src/mainboard/amd/mahogany_fam10/romstage.c coreboot-disupducode/src/mainboard/amd/mahogany_fam10/romstage.c --- coreboot-r6380/src/mainboard/amd/mahogany_fam10/romstage.c 2011-02-25 23:54:27.0 +0100 +++ coreboot-disupducode/src/mainboard/amd/mahogany_fam10/romstage.c 2011-02-26 00:15:29.0 +0100 @@ -66,7 +66,11 @@ #include cpu/amd/quadcore/quadcore.c #include cpu/amd/car/post_cache_as_ram.c #include cpu/amd/microcode/microcode.c + +#if CONFIG_UPDATE_CPU_MICROCODE==1 #include cpu/amd/model_10xxx/update_microcode.c +#endif + #include cpu/amd/model_10xxx/init_cpus.c #include northbridge/amd/amdfam10/early_ht.c #include southbridge/amd/sb700/early_setup.c @@ -125,7 +129,11 @@ /* Setup sysinfo defaults */ set_sysinfo_in_ram(0); + +#if CONFIG_UPDATE_CPU_MICROCODE==1 update_microcode(val); +#endif + post_code(0x33); cpuSetAMDMSR(); diff -ru coreboot-r6380/src/mainboard/amd/serengeti_cheetah_fam10/romstage.c coreboot-disupducode/src/mainboard/amd/serengeti_cheetah_fam10/romstage.c --- coreboot-r6380/src/mainboard/amd/serengeti_cheetah_fam10/romstage.c 2011-02-25 23:54:27.0 +0100 +++ coreboot-disupducode/src/mainboard/amd/serengeti_cheetah_fam10/romstage.c 2011-02-26 00:16:25.0 +0100 @@ -87,7 +87,11 @@ #include cpu/amd/quadcore/quadcore.c #include cpu/amd/car/post_cache_as_ram.c #include cpu/amd/microcode/microcode.c + +#if CONFIG_UPDATE_CPU_MICROCODE==1 #include
Re: [coreboot] [PATCH] disabling microcode update
This patch tries to fix compilation when you select EXPERT in make menuconfig. If I select Expert mode in make menuconfig I couldn't compile because it complained of 2 missing configuration constants. I hope this is the right solution, but haven't really checked that the related code in src/northbridge/amd/amdht/h3finit.c is correct. Signed-off-by: Xavi Drudis Ferran xdru...@tinet.cat --- --- coreboot-disupducode/src/northbridge/amd/Kconfig 2011-02-26 00:01:01.0 +0100 +++ coreboot-expert/src/northbridge/amd/Kconfig 2011-02-26 03:02:15.0 +0100 @@ -24,8 +24,12 @@ config LIMIT_HT_SPEED_200 bool Limit HT frequency to 200MHz +config LIMIT_HT_SPEED_300 + bool Limit HT frequency to 300MHz config LIMIT_HT_SPEED_400 bool Limit HT frequency to 400MHz +config LIMIT_HT_SPEED_500 + bool Limit HT frequency to 500MHz config LIMIT_HT_SPEED_600 bool Limit HT frequency to 600MHz config LIMIT_HT_SPEED_800 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Fam10 FIDVID in SVI 01/25
On Thu, Feb 24, 2011 at 02:31:29PM +0100, Georgi, Patrick wrote: Am Donnerstag, den 17.02.2011, 07:35 +0100 schrieb xdrudis: see patch Any opinion on these patches? Patch 1-8 seem to be refactorings only, and splitting functions into smaller logical units looks good to me, but I'd like to hear from someone deeper in the AMD code. Yes, if these 8 are not refactorings, then it's a bug. I know it's a little work to review it all, but it does not have to be one person. You can review just one patch, maybe. Testing is maybe better to do with all of them, or all without negative reviews, or something. I've tested them one by one and it is a little a waste of time. And I haven't found a single one that fixes it for me. Must be a combination, possibly not all but not sure which ones. They're secuential although not each and every one needs all previous ones. By the way testing for both SVI and PVI is welcome (for AMD FAM 10). I don't intend to break PVI, but I can't test it. Some of the later ones may be a little paranoid or a matter of taste but I tried to split them in small pieces so they can be rejected or modified. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] disabling microcode update
On Mon, Feb 21, 2011 at 08:44:35AM -0600, Scott Duplichan wrote: This really isn't relevant, but microcode patch source code certainly exists, as does source code for the main microcode that the patch modifies. A microcode assembler converts the source code into binary form. I think it's relevant. In any case, thank you for the information. Think about what it would take for public microcode patch source code to be useful. First, the processor vendor would have to publish the thousands of lines of source code for the microcode that will be patched. Next, the microcode assembler and related tools would have to be published. At that point, a lot of training is needed to even understand the microcode. Microcode is not written in any standard programming language. The language is completely different for different processor vendors, and even for different processor models in some cases. Anyway, assume that somehow a non-employee became a microcode expert for a particular processor model. Why would the patch need to be modified? The patch corrects a processor erratum. To modify microcode in a way that works around a processor erratum usually requires details of the processor design that are not published. Yes, I know the processor is not open hardware. Yet, the issue does not vanish just because of this. You say it would require an expert. Well, that's what average people think of free software, it takes an expert to modify a program, so who needs software freedom. I won't untangle that fallacy here to avoid preaching to the choir. Sure, there may be more experts apt at modifying emacs than certain microcode source, but so what? Before I knew coreboot I didn't think the expertise necessary to write firmware could be had in a free software project, and now I'm arguing with one of those experts I thought didn't exist. There are several free software projects that work around or reverse engineer secret designs. The fact that it is unlikely or difficult is no excuse to use other people's work against the license they have choosen. It's not me you have to convince or you I have to convince, it's any copyright holder to code linked to this microcode if we want to make a derivative work. When a processor is purchased, its source code is not provided. The microcode patch is a modification of the processor design, so it is not surprising the source code is not supplied. That's a particular point of view, seeing microcode patches as some kind of binary soldering iron of sorts. I don't see it like that. Changing microcode does not change the microprocessor design any more than changing documentation or firmware. The circuits are so that given some microcode perfom some function. They'd do something else with a different microcode but they would still be the same circuits. Otherwise any software would be a circuit metamorphoser. I see microcode as a preloaded propietary program for a VLIW processor whose purpose is to emulate a CISC processor that happens to have more application software available. The x86, amd64 or whatever instruction set works just like an ABI, similar to parrot or java bytecodes allowing people to write once and run anywhere, and makes economic sense. But it does not change the nature of the VLIW processor. The processor design is information, VHDL programs if you like. The only thing that distinguishes the logic that goes to silicon from what goes to software is the possibility to change it without building another device. Therefore, microcode is software for a (nondocumented) machine as soon as it can be modified. This VLIW nondocumented machine could have compilers for any language that generate microcode or interpreters for other instruction sets, and maybe I could have the compiler generate a new opcode to optimize a tight loop or run ARM or PPC binaries in my Phenom. Not that I'm interested, I'd rather recompile free software for amd64. And not that it would be economic to build such a compiler backend for such a small number of CPUs out there. All this is not trying to bash any cpu vendor or imply any wrongdoing by anyone. When I bought my CPU it was advertised as amd64, x86 , MMX , etc. compatible, not as a VLIW processor I could reprogram by microcode patches. And I'm not claiming I have a great business model for paying the engineers and factories to build open hardware of similar power (although if someone does, I'd like to get some advertising). And I'm not saying that I'm surprised to know that sources or documentation for microcode or cpu designs are not published. I'm just surprised to find microcode linked into GPL binaries. My intent is just to explain that those wanting these binary parts left out of their coreboot image are not some kind of luddite zealots, simply people that like to apply uniform criteria to their free software. And this is just too much for a rationale for a 69 lines patch, so I'll leave it here and sorry for the
[coreboot] [PATCH] disabling microcode update
On Fri, Feb 18, 2011 at 10:19:31AM -0500, Ward Vandewege wrote:
Hi Xavi,
On Wed, Feb 16, 2011 at 02:45:02PM +0100, Xavi Drudis Ferran wrote:
Should I send a patch making a Kconfig option to not upgrade microcode for
fam10? Is there any interest in that ?
Yes, please. I would test and ack that.
Thanks,
Ward.
Here it is. It's limited to fam10. I don't know about other families nor can
test.
Sorry about having missed the request from Ivaylo, for a moment I
thought I was the only one interested.
It works in my board (but my board still does not boot, so tests in
functional boards are welcome).
Thanks. Allow the user to disable cpu microcode updating
(only for AMD model_10xxx cpus) in make menuconfig.
If disabled the microcode is not included in
update_microcode.c and therefore the generate image
does not include it.
Signed-off-by: Xavi Drudis Ferran xdru...@tinet.cat
---
I've abuild tested it with default y and default n,
not sure if abuild build with all default options and
so both cases are tested or I should do something else.
--- src/cpu/amd/model_10xxx/Kconfig 2011-02-19 21:56:44.0 +0100
+++ src/cpu/amd/model_10xxx/Kconfig 2011-02-19 19:48:20.0 +0100
@@ -50,3 +50,22 @@
endif
endif
+
+config UPDATE_CPU_MICROCODE
+ bool Update cpu microcode
+ default y
+ depends on CPU_AMD_MODEL_10XXX
+help
+ Select this to apply (propietary?) patches to the cpu
+ microcode provided by AMD to correct issues in the CPU after
+ production, and distributed with coreboot (not necessarily
+ the latest microcode version produced by AMD, but only
+ applied if newer than the version in your CPU).
+
+ Unselect to let FAM10 CPUs run with factory microcode. If
+ you unselect this, no binary microcode patches will be
+ included in the image, so it will help you get an image
+ which you have the entire source code for and may simplify
+ license compliance (IANAL).
+
+
--- src/cpu/amd/model_10xxx/update_microcode.c 2011-02-19 21:56:44.0 +0100
+++ src/cpu/amd/model_10xxx/update_microcode.c 2011-02-19 22:09:17.0 +0100
@@ -29,6 +29,7 @@
#include cpu/amd/microcode.h
#endif
+#if CONFIG_UPDATE_CPU_MICROCODE
static const u8 microcode_updates[] __attribute__ ((aligned(16))) = {
#ifdef __PRE_RAM__
@@ -93,9 +94,11 @@
return new_id;
}
+#endif
void update_microcode(u32 cpu_deviceid)
{
+#if CONFIG_UPDATE_CPU_MICROCODE
u32 equivalent_processor_rev_id;
/* Update the microcode */
@@ -105,5 +108,6 @@
} else {
printk(BIOS_DEBUG, microcode: rev id not found. Skipping microcode patch!\n);
}
+#endif
}
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] Fam10 FIDVID in SVI 01/25
see patchPrepare for next patches (Improving BKDG implementation of P-states,
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode). No change of behaviour intended.
Refactor FAM10 fidvid . prep_fid_change was already long and it'd
get longer with forthcoming patches. We now take apart VSRamp in step b
of 2.4.1.7 BKDG to its own function.
Signed-off-by: Xavi Drudis Ferran xdru...@tinet.cat
--- src/cpu/amd/model_10xxx/fidvid.c 2011-02-16 20:51:55.0 +0100
+++ src/cpu/amd/model_10xxx/fidvid.c 2011-02-16 20:51:55.0 +0100
@@ -66,6 +66,21 @@ static void enable_fid_change(u8 fid)
}
}
+static void setVSRamp(device_t dev) {
+ /* BKDG r31116 2010-04-22 2.4.1.7 step b F3xD8[VSRampTime]
+ * If this field accepts 8 values between 10 and 500 us why
+ * does page 324 say BIOS should set this field to 001b.
+ * (20 us) ?
+ * Shouldn't it depend on the voltage regulators, mainboard
+ * or something ?
+ */
+u32 dword;
+ dword = pci_read_config32(dev, 0xd8);
+ dword = VSRAMP_MASK;
+ dword |= VSRAMP_VALUE;
+ pci_write_config32(dev, 0xd8, dword);
+}
+
static void recalculateVsSlamTimeSettingOnCorePre(device_t dev)
{
u8 pviModeFlag;
@@ -179,11 +194,8 @@ static void prep_fid_change(void)
printk(BIOS_DEBUG, Prep FID/VID Node:%02x \n, i);
dev = NODE_PCI(i, 3);
- dword = pci_read_config32(dev, 0xd8);
- dword = VSRAMP_MASK;
- dword |= VSRAMP_VALUE;
- pci_write_config32(dev, 0xd8, dword);
-
+ setVSRamp(dev);
+ /* BKDG r31116 2010-04-22 2.4.1.7 step b F3xD8[VSSlamTime] */
/* Figure out the value for VsSlamTime and program it */
recalculateVsSlamTimeSettingOnCorePre(dev);
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] Fam10 FIDVID in SVI 02/25
see patch
Prepare for next patches (Improving BKDG implementation of P-states,
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode).
No change of behaviour intended.
Refactor FAM10 fidvid . prep_fid_change was already long and it'd
get longer with forthcoming patches. We now take apart F3xD4,
Clock Power/Timing Control 0 to its own function.
Signed-off-by: Xavi Drudis Ferran xdru...@tinet.cat
--- src/cpu/amd/model_10xxx/fidvid.c 2011-02-16 20:51:55.0 +0100
+++ src/cpu/amd/model_10xxx/fidvid.c 2011-02-16 20:51:55.0 +0100
@@ -179,6 +179,58 @@ static void recalculateVsSlamTimeSetting
pci_write_config32(dev, 0xd8, dtemp);
}
+static void config_clk_power_ctrl_reg0(int node) {
+u32 dword;
+ device_t dev = NODE_PCI(node, 3);
+ /* Program fields in Clock Power/Control register0 (F3xD4) */
+
+ /* set F3xD4 Clock Power/Timing Control 0 Register
+ * NbClkDidApplyAll=1b
+ * NbClkDid=100b
+ * PowerStepUp= platform dependent
+ * PowerStepDown= platform dependent
+ * LinkPllLink=01b
+ * ClkRampHystSel=HW default
+ */
+ /* check platform type */
+ if (!(get_platform_type() AMD_PTYPE_SVR)) {
+ /* For non-server platform
+ * PowerStepUp=01000b - 50nS
+ * PowerStepDown=01000b - 50ns
+ */
+ dword = pci_read_config32(dev, 0xd4);
+ dword = CPTC0_MASK;
+ dword |= NB_CLKDID_ALL | NB_CLKDID | PW_STP_UP50 | PW_STP_DN50 | LNK_PLL_LOCK; /* per BKDG */
+ pci_write_config32(dev, 0xd4, dword);
+ } else {
+ dword = pci_read_config32(dev, 0xd4);
+ dword = CPTC0_MASK;
+ /* get number of cores for PowerStepUp PowerStepDown in server
+ 1 core - 400nS - b
+ 2 cores - 200nS - 0010b
+ 3 cores - 133nS - 100nS - 0011b
+ 4 cores - 100nS - 0011b
+ */
+ switch (get_core_num_in_bsp(node)) {
+ case 0:
+ dword |= PW_STP_UP400 | PW_STP_DN400;
+ break;
+ case 1:
+ case 2:
+ dword |= PW_STP_UP200 | PW_STP_DN200;
+ break;
+ case 3:
+ dword |= PW_STP_UP100 | PW_STP_DN100;
+ break;
+ default:
+ dword |= PW_STP_UP100 | PW_STP_DN100;
+ break;
+ }
+ dword |= NB_CLKDID_ALL | NB_CLKDID | LNK_PLL_LOCK;
+ pci_write_config32(dev, 0xd4, dword);
+ }
+}
+
static void prep_fid_change(void)
{
u32 dword, dtemp;
@@ -199,52 +251,7 @@ static void prep_fid_change(void)
/* Figure out the value for VsSlamTime and program it */
recalculateVsSlamTimeSettingOnCorePre(dev);
- /* Program fields in Clock Power/Control register0 (F3xD4) */
- /* set F3xD4 Clock Power/Timing Control 0 Register
- * NbClkDidApplyAll=1b
- * NbClkDid=100b
- * PowerStepUp= platform dependent
- * PowerStepDown= platform dependent
- * LinkPllLink=01b
- * ClkRampHystSel=HW default
- */
- /* check platform type */
- if (!(get_platform_type() AMD_PTYPE_SVR)) {
- /* For non-server platform
- * PowerStepUp=01000b - 50nS
- * PowerStepDown=01000b - 50ns
- */
- dword = pci_read_config32(dev, 0xd4);
- dword = CPTC0_MASK;
- dword |= NB_CLKDID_ALL | NB_CLKDID | PW_STP_UP50 | PW_STP_DN50 | LNK_PLL_LOCK; /* per BKDG */
- pci_write_config32(dev, 0xd4, dword);
- } else {
- dword = pci_read_config32(dev, 0xd4);
- dword = CPTC0_MASK;
- /* get number of cores for PowerStepUp PowerStepDown in server
- 1 core - 400nS - b
- 2 cores - 200nS - 0010b
- 3 cores - 133nS - 100nS - 0011b
- 4 cores - 100nS - 0011b
- */
- switch (get_core_num_in_bsp(i)) {
- case 0:
-dword |= PW_STP_UP400 | PW_STP_DN400;
-break;
- case 1:
- case 2:
-dword |= PW_STP_UP200 | PW_STP_DN200;
-break;
- case 3:
-dword |= PW_STP_UP100 | PW_STP_DN100;
-break;
- default:
-dword |= PW_STP_UP100 | PW_STP_DN100;
-break;
- }
- dword |= NB_CLKDID_ALL | NB_CLKDID | LNK_PLL_LOCK;
- pci_write_config32(dev, 0xd4, dword);
- }
+ config_clk_power_ctrl_reg0(i);
/* check PVI/SVI */
dword = pci_read_config32(dev, 0xA0);
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] Fam10 FIDVID in SVI 03/25
see patch
Prepare for next patches (Improving BKDG implementation of P-states,
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode).
No change of behaviour intended.
Refactor FAM10 fidvid . prep_fid_change was already long and it'd
get longer with forthcoming patches. We now take apart F3xA0,
Power Control Misc Register to its own function.
Signed-off-by: Xavi Drudis Ferran xdru...@tinet.cat
--- src/cpu/amd/model_10xxx/fidvid.c 2011-02-16 20:51:55.0 +0100
+++ src/cpu/amd/model_10xxx/fidvid.c 2011-02-16 20:51:55.0 +0100
@@ -231,9 +231,36 @@ static void config_clk_power_ctrl_reg0(i
}
}
+static void config_power_ctrl_misc_reg(device_t dev) {
+ /* check PVI/SVI */
+ u32 dword = pci_read_config32(dev, 0xA0);
+ if (dword PVI_MODE) { /* PVI */
+ /* set slamVidMode to 0 for PVI */
+ dword = VID_SLAM_OFF | PLLLOCK_OFF;
+ dword |= PLLLOCK_DFT_L;
+ pci_write_config32(dev, 0xA0, dword);
+ } else { /* SVI */
+ /* set slamVidMode to 1 for SVI */
+ dword = PLLLOCK_OFF;
+ dword |= PLLLOCK_DFT_L | VID_SLAM_ON;
+ pci_write_config32(dev, 0xA0, dword);
+
+ u32 dtemp = dword;
+
+ /* Program F3xD8[PwrPlanes] according F3xA0[DulaVdd] */
+ dword = pci_read_config32(dev, 0xD8);
+
+ if (dtemp DUAL_VDD_BIT)
+ dword |= PWR_PLN_ON;
+ else
+ dword = PWR_PLN_OFF;
+ pci_write_config32(dev, 0xD8, dword);
+ }
+}
+
static void prep_fid_change(void)
{
- u32 dword, dtemp;
+u32 dword;
u32 nodes;
device_t dev;
int i;
@@ -253,31 +280,8 @@ static void prep_fid_change(void)
config_clk_power_ctrl_reg0(i);
- /* check PVI/SVI */
- dword = pci_read_config32(dev, 0xA0);
- if (dword PVI_MODE) { /* PVI */
- /* set slamVidMode to 0 for PVI */
- dword = VID_SLAM_OFF | PLLLOCK_OFF;
- dword |= PLLLOCK_DFT_L;
- pci_write_config32(dev, 0xA0, dword);
- } else { /* SVI */
- /* set slamVidMode to 1 for SVI */
- dword = PLLLOCK_OFF;
- dword |= PLLLOCK_DFT_L | VID_SLAM_ON;
- pci_write_config32(dev, 0xA0, dword);
-
- dtemp = dword;
-
- /* Program F3xD8[PwrPlanes] according F3xA0[DulaVdd] */
- dword = pci_read_config32(dev, 0xD8);
-
- if (dtemp DUAL_VDD_BIT)
-dword |= PWR_PLN_ON;
- else
-dword = PWR_PLN_OFF;
- pci_write_config32(dev, 0xD8, dword);
- }
-
+config_power_ctrl_misc_reg(dev);
+
/* Note the following settings are additional from the ported
* function setFidVidRegs()
*/
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] Fam10 FIDVID in SVI 04/25
see patch
Prepare for next patches (Improving BKDG implementation of P-states,
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode).
No change of behaviour intended.
Refactor FAM10 fidvid . prep_fid_change was already long and it'd
get longer with forthcoming patches. We now take apart F3xDC[NbsynPtrAdj],
Northbridge/core synchronization FIFO pointer adjust, to its own function.
Signed-off-by: Xavi Drudis Ferran xdru...@tinet.cat
--- src/cpu/amd/model_10xxx/fidvid.c 2011-02-16 20:51:55.0 +0100
+++ src/cpu/amd/model_10xxx/fidvid.c 2011-02-16 20:51:55.0 +0100
@@ -258,6 +258,17 @@ static void config_power_ctrl_misc_reg(d
}
}
+
+static void config_nb_syn_ptr_adj(device_t dev) {
+ /* Note the following settings are additional from the ported
+ * function setFidVidRegs()
+ */
+ u32 dword = pci_read_config32(dev, 0xDc);
+ dword |= 0x5 12; /* NbsynPtrAdj set to 0x5 per BKDG (needs reset) */
+ pci_write_config32(dev, 0xdc, dword);
+
+}
+
static void prep_fid_change(void)
{
u32 dword;
@@ -281,13 +292,8 @@ static void prep_fid_change(void)
config_clk_power_ctrl_reg0(i);
config_power_ctrl_misc_reg(dev);
-
- /* Note the following settings are additional from the ported
- * function setFidVidRegs()
- */
- dword = pci_read_config32(dev, 0xDc);
- dword |= 0x5 12; /* NbsynPtrAdj set to 0x5 per BKDG (needs reset) */
- pci_write_config32(dev, 0xdc, dword);
+
+ config_nb_syn_ptr_adj(dev);
/* Rev B settings - FIXME: support other revs. */
dword = 0xA0E641E6;
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] Fam10 FIDVID in SVI 05/25
see patch
Prepare for next patches (Improving BKDG implementation of P-states,
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode).
No change of behaviour intended.
Refactor FAM10 fidvid . prep_fid_change was already long and it'd
get longer with forthcoming patches. We now take apart F3x[84:80],
ACPI Power State Control Registers, to its own function.
Signed-off-by: Xavi Drudis Ferran xdru...@tinet.cat
--- src/cpu/amd/model_10xxx/fidvid.c 2011-02-16 20:51:55.0 +0100
+++ src/cpu/amd/model_10xxx/fidvid.c 2011-02-16 20:51:55.0 +0100
@@ -257,7 +257,6 @@ static void config_power_ctrl_misc_reg(d
pci_write_config32(dev, 0xD8, dword);
}
}
-
static void config_nb_syn_ptr_adj(device_t dev) {
/* Note the following settings are additional from the ported
@@ -269,6 +268,14 @@ static void config_nb_syn_ptr_adj(device
}
+static void config_acpi_pwr_state_ctrl_regs(device_t dev) {
+ /* Rev B settings - FIXME: support other revs. */
+ u32 dword = 0xA0E641E6;
+ pci_write_config32(dev, 0x84, dword);
+ dword = 0xE600A681;
+ pci_write_config32(dev, 0x80, dword);
+}
+
static void prep_fid_change(void)
{
u32 dword;
@@ -295,12 +302,7 @@ static void prep_fid_change(void)
config_nb_syn_ptr_adj(dev);
- /* Rev B settings - FIXME: support other revs. */
- dword = 0xA0E641E6;
- pci_write_config32(dev, 0x84, dword);
-
- dword = 0xE600A681;
- pci_write_config32(dev, 0x80, dword);
+config_acpi_pwr_state_ctrl_regs(dev);
dword = pci_read_config32(dev, 0x80);
printk(BIOS_DEBUG, F3x80: %08x \n, dword);
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] Fam10 FIDVID in SVI 06/25
see patch
Prepare for next patches (Improving BKDG implementation of P-states,
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode).
No change of behaviour intended.
Refactor FAM10 fidvid. Factor out a little common code.
Also, our earlier config_clk_power_ctrl_reg0
was still too long and it'd get longer with forthcoming patches.
We now take apart F3xD4[PowerStepUp,PowerStepDown]
to its own function.
Signed-off-by: Xavi Drudis Ferran xdru...@tinet.cat
--- src/cpu/amd/model_10xxx/fidvid.c 2011-02-16 20:51:55.0 +0100
+++ src/cpu/amd/model_10xxx/fidvid.c 2011-02-16 20:51:55.0 +0100
@@ -179,32 +179,16 @@ static void recalculateVsSlamTimeSetting
pci_write_config32(dev, 0xd8, dtemp);
}
-static void config_clk_power_ctrl_reg0(int node) {
-u32 dword;
- device_t dev = NODE_PCI(node, 3);
- /* Program fields in Clock Power/Control register0 (F3xD4) */
-
- /* set F3xD4 Clock Power/Timing Control 0 Register
- * NbClkDidApplyAll=1b
- * NbClkDid=100b
- * PowerStepUp= platform dependent
- * PowerStepDown= platform dependent
- * LinkPllLink=01b
- * ClkRampHystSel=HW default
- */
+static u32 power_up_down(int node) {
+ u32 dword=0;
/* check platform type */
if (!(get_platform_type() AMD_PTYPE_SVR)) {
/* For non-server platform
* PowerStepUp=01000b - 50nS
* PowerStepDown=01000b - 50ns
*/
- dword = pci_read_config32(dev, 0xd4);
- dword = CPTC0_MASK;
- dword |= NB_CLKDID_ALL | NB_CLKDID | PW_STP_UP50 | PW_STP_DN50 | LNK_PLL_LOCK; /* per BKDG */
- pci_write_config32(dev, 0xd4, dword);
+ dword |= PW_STP_UP50 | PW_STP_DN50 ;
} else {
- dword = pci_read_config32(dev, 0xd4);
- dword = CPTC0_MASK;
/* get number of cores for PowerStepUp PowerStepDown in server
1 core - 400nS - b
2 cores - 200nS - 0010b
@@ -226,9 +210,31 @@ static void config_clk_power_ctrl_reg0(i
dword |= PW_STP_UP100 | PW_STP_DN100;
break;
}
- dword |= NB_CLKDID_ALL | NB_CLKDID | LNK_PLL_LOCK;
- pci_write_config32(dev, 0xd4, dword);
}
+return dword;
+}
+
+static void config_clk_power_ctrl_reg0(int node) {
+ device_t dev = NODE_PCI(node, 3);
+
+
+ /* Program fields in Clock Power/Control register0 (F3xD4) */
+
+ /* set F3xD4 Clock Power/Timing Control 0 Register
+ * NbClkDidApplyAll=1b
+ * NbClkDid=100b
+ * PowerStepUp= platform dependent
+ * PowerStepDown= platform dependent
+ * LinkPllLink=01b
+ * ClkRampHystSel=HW default
+ */
+u32 dword= pci_read_config32(dev, 0xd4);
+ dword = CPTC0_MASK;
+ dword |= NB_CLKDID_ALL | NB_CLKDID | LNK_PLL_LOCK; /* per BKDG */
+dword |= power_up_down(node);
+
+ pci_write_config32(dev, 0xd4, dword);
+
}
static void config_power_ctrl_misc_reg(device_t dev) {
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] Fam10 FIDVID in SVI 07/25
see patch
Prepare for next patches (Improving BKDG implementation of P-states,
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode).
No change of behaviour intended.
Refactor FAM10 fidvid . Factor out the decision whether
to update northbridge frequency and voltage because there
was the same code in 3 places and so we can later modify it
in one place.
Signed-off-by: Xavi Drudis Ferran xdru...@tinet.cat
--- src/cpu/amd/model_10xxx/fidvid.c 2011-02-16 20:51:55.0 +0100
+++ src/cpu/amd/model_10xxx/fidvid.c 2011-02-16 20:51:55.0 +0100
@@ -280,6 +280,7 @@ static void config_acpi_pwr_state_ctrl_r
pci_write_config32(dev, 0x84, dword);
dword = 0xE600A681;
pci_write_config32(dev, 0x80, dword);
+
}
static void prep_fid_change(void)
@@ -503,18 +504,33 @@ static void transitionVid(u32 targetVid,
}
}
+static u32 needs_NB_COF_VID_update(void)
+{
+ u8 nb_cof_vid_update;
+ u8 nodes;
+ u8 i;
+
+ /* If any node has nb_cof_vid_update set all nodes need an update. */
+ nodes = get_nodes();
+ nb_cof_vid_update = 0;
+ for (i = 0; i nodes; i++) {
+ if (pci_read_config32(NODE_PCI(i, 3), 0x1FC) 1) {
+ nb_cof_vid_update = 1;
+ break;
+ }
+ }
+ return nb_cof_vid_update;
+}
static void init_fidvid_ap(u32 bsp_apicid, u32 apicid, u32 nodeid, u32 coreid)
{
device_t dev;
u32 vid_max;
u32 fid_max;
- u8 nb_cof_vid_update;
+ u8 nb_cof_vid_update = needs_NB_COF_VID_update();
u8 pvimode;
u32 reg1fc;
u32 send;
- u8 nodes;
- u8 i;
printk(BIOS_DEBUG, FIDVID on AP: %02x\n, apicid);
@@ -522,15 +538,7 @@ static void init_fidvid_ap(u32 bsp_apici
* for SVI and Single-Plane PVI Systems.
*/
- /* If any node has nb_cof_vid_update set all nodes need an update. */
- nodes = get_nodes();
- nb_cof_vid_update = 0;
- for (i = 0; i nodes; i++) {
- if (pci_read_config32(NODE_PCI(i, 3), 0x1FC) 1) {
- nb_cof_vid_update = 1;
- break;
- }
- }
+
dev = NODE_PCI(nodeid, 3);
pvimode = (pci_read_config32(dev, 0xA0) 8) 1;
@@ -710,23 +718,13 @@ static void init_fidvid_stage2(u32 apici
u32 reg1fc;
u32 dtemp;
u32 nbvid;
- u8 nb_cof_vid_update;
- u8 nodes;
+ u8 nb_cof_vid_update = needs_NB_COF_VID_update();
u8 NbVidUpdateAll;
- u8 i;
u8 pvimode;
/* After warm reset finish the fid/vid setup for all cores. */
/* If any node has nb_cof_vid_update set all nodes need an update. */
- nodes = get_nodes();
- nb_cof_vid_update = 0;
- for (i = 0; i nodes; i++) {
- if (pci_read_config32(NODE_PCI(i, 3), 0x1FC) 1) {
- nb_cof_vid_update = 1;
- break;
- }
- }
dev = NODE_PCI(nodeid, 3);
pvimode = (pci_read_config32(dev, 0xA0) 8) 1;
@@ -788,7 +786,7 @@ static int init_fidvid_bsp(u32 bsp_apici
device_t dev;
u32 vid_max;
u32 fid_max=0;
- u8 nb_cof_vid_update;
+ u8 nb_cof_vid_update = needs_NB_COF_VID_update();
u32 reg1fc;
u8 pvimode;
@@ -801,15 +799,6 @@ static int init_fidvid_bsp(u32 bsp_apici
* for SVI and Single-Plane PVI Systems.
*/
- /* If any node has nb_cof_vid_update set all nodes need an update. */
- nb_cof_vid_update = 0;
- for (i = 0; i nodes; i++) {
- if (pci_read_config32(NODE_PCI(i, 3), 0x1FC) 1) {
- nb_cof_vid_update = 1;
- break;
- }
- }
-
dev = NODE_PCI(0, 3);
pvimode = (pci_read_config32(dev, 0xA0) 8) 1;
reg1fc = pci_read_config32(dev, 0x1FC);
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] Fam10 FIDVID in SVI 08/25
see patch
Prepare for next patches (Improving BKDG implementation of P-states,
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode).
As suggested by a FIXME, factor out the common code in init_fidvid_ap
and init_fidvid_core and put it into a new function init_fidvid_core
that both call. So we can later modify it in one place.
No change of behaviour intended, but the compiler had me initialize
fid_max to 0, while previously it wasn't so in one of the two places.
Signed-off-by: Xavi Drudis Ferran xdru...@tinet.cat
--- src/cpu/amd/model_10xxx/fidvid.c 2011-02-16 20:51:55.0 +0100
+++ src/cpu/amd/model_10xxx/fidvid.c 2011-02-16 20:51:55.0 +0100
@@ -280,7 +280,6 @@ static void config_acpi_pwr_state_ctrl_r
pci_write_config32(dev, 0x84, dword);
dword = 0xE600A681;
pci_write_config32(dev, 0x80, dword);
-
}
static void prep_fid_change(void)
@@ -522,24 +521,19 @@ static u32 needs_NB_COF_VID_update(void)
return nb_cof_vid_update;
}
-static void init_fidvid_ap(u32 bsp_apicid, u32 apicid, u32 nodeid, u32 coreid)
+static u32 init_fidvid_core(u32 nodeid, u32 coreid)
{
device_t dev;
u32 vid_max;
- u32 fid_max;
+ u32 fid_max=0;
u8 nb_cof_vid_update = needs_NB_COF_VID_update();
u8 pvimode;
u32 reg1fc;
- u32 send;
-
- printk(BIOS_DEBUG, FIDVID on AP: %02x\n, apicid);
/* Steps 1-6 of BIOS NB COF and VID Configuration
* for SVI and Single-Plane PVI Systems.
*/
-
-
dev = NODE_PCI(nodeid, 3);
pvimode = (pci_read_config32(dev, 0xA0) 8) 1;
reg1fc = pci_read_config32(dev, 0x1FC);
@@ -565,7 +559,17 @@ static void init_fidvid_ap(u32 bsp_apici
UpdateSinglePlaneNbVid();
}
- send = (nb_cof_vid_update 16) | (fid_max 8);
+ return ((nb_cof_vid_update 16) | (fid_max 8));
+
+}
+
+static void init_fidvid_ap(u32 bsp_apicid, u32 apicid, u32 nodeid, u32 coreid)
+{
+ u32 send;
+
+ printk(BIOS_DEBUG, FIDVID on AP: %02x\n, apicid);
+
+send = init_fidvid_core(nodeid,coreid);
send |= (apicid 24); // ap apicid
// Send signal to BSP about this AP max fid
@@ -783,48 +787,15 @@ static int init_fidvid_bsp(u32 bsp_apici
u32 i;
#endif
struct fidvid_st fv;
- device_t dev;
- u32 vid_max;
- u32 fid_max=0;
- u8 nb_cof_vid_update = needs_NB_COF_VID_update();
- u32 reg1fc;
- u8 pvimode;
printk(BIOS_DEBUG, FIDVID on BSP, APIC_id: %02x\n, bsp_apicid);
- /* FIXME: The first half of this function is nearly the same as
- * init_fidvid_bsp() and the code could be combined.
- */
/* Steps 1-6 of BIOS NB COF and VID Configuration
* for SVI and Single-Plane PVI Systems.
*/
- dev = NODE_PCI(0, 3);
- pvimode = (pci_read_config32(dev, 0xA0) 8) 1;
- reg1fc = pci_read_config32(dev, 0x1FC);
-
- if (nb_cof_vid_update) {
- if (pvimode) {
- vid_max = (reg1fc 7) 0x7F;
- fid_max = (reg1fc 2) 0x1F;
-
- /* write newNbVid to P-state Reg's NbVid always if NbVidUpdatedAll=1 */
- fixPsNbVidBeforeWR(vid_max, 0);
- } else { /* SVI */
- vid_max = ((reg1fc 7) 0x7F) - ((reg1fc 17) 0x1F);
- fid_max = ((reg1fc 2) 0x1F) + ((reg1fc 14) 0x7);
- transitionVid(vid_max, dev, IS_NB);
- }
-
- /* fid setup is handled by the BSP at the end. */
-
- } else { /* ! nb_cof_vid_update */
- /* Use max values */
- if (pvimode)
- UpdateSinglePlaneNbVid();
- }
+ fv.common_fid = init_fidvid_core(0,0);
- fv.common_fid = (nb_cof_vid_update 16) | (fid_max 8);
print_debug_fv(BSP fid = , fv.common_fid);
#if CONFIG_SET_FIDVID_STORE_AP_APICID_AT_FIRST !CONFIG_SET_FIDVID_CORE0_ONLY
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] Fam10 FIDVID in SVI 09/25
see patch
Improving BKDG implementation of P-states,
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode.
Bring F3xD4 (Clock/Power Control Register 0) more in line
with BKDG i more cases. It requires looking at the CPU package type
so I add a function for that (in the wrong place?) and some
new constants
Signed-off-by: Xavi Drudis Ferran xdru...@tinet.cat
--- src/cpu/amd/model_10xxx/fidvid.c 2011-02-13 14:37:34.0 +0100
+++ src/cpu/amd/model_10xxx/fidvid.c 2011-02-13 18:24:15.0 +0100
@@ -179,16 +179,51 @@
pci_write_config32(dev, 0xd8, dtemp);
}
-static u32 power_up_down(int node) {
+static u32 nb_clk_did(int node, u32 cpuRev,u8 procPkg) {
+u8 link0isGen3 = 0;
+u8 offset;
+if (AMD_CpuFindCapability(node, 0, offset)) {
+ link0isGen3 = (AMD_checkLinkType(node, 0, offset) HTPHY_LINKTYPE_HT3 );
+ }
+/* FIXME: NB_CLKDID should be 101b for AMD_DA_C2 in package
+ S1g3 in link Gen3 mode, but I don't know how to tell
+ package S1g3 from S1g4 */
+ if ((cpuRev AMD_DA_C2) (procPkg AMD_PKGTYPE_S1gX)
+link0isGen3) {
+ return 5 ; /* divide clk by 128*/
+} else {
+ return 4 ; /* divide clk by 16 */
+}
+}
+
+
+static u32 power_up_down(int node, u8 procPkg) {
u32 dword=0;
- /* check platform type */
- if (!(get_platform_type() AMD_PTYPE_SVR)) {
- /* For non-server platform
- * PowerStepUp=01000b - 50nS
- * PowerStepDown=01000b - 50ns
- */
- dword |= PW_STP_UP50 | PW_STP_DN50 ;
+/* from CPU rev guide #41322 rev 3.74 June 2010 Table 26 */
+u8 singleLinkFlag = ((procPkg == AMD_PKGTYPE_AM3_2r2)
+ || (procPkg == AMD_PKGTYPE_S1gX)
+ || (procPkg == AMD_PKGTYPE_ASB2));
+
+if (singleLinkFlag) {
+ /*
+ * PowerStepUp=01000b - 50nS
+ * PowerStepDown=01000b - 50ns
+ */
+ dword |= PW_STP_UP50 | PW_STP_DN50;
} else {
+ u32 dispRefModeEn = (pci_read_config32(NODE_PCI(node,0),0x68) 24) 1;
+ u32 isocEn = 0;
+ int j;
+ for(j=0 ; (j4) (!isocEn) ; j++ ) {
+ u8 offset;
+ if (AMD_CpuFindCapability(node, j, offset)) {
+ isocEn = (pci_read_config32(NODE_PCI(node,0),offset+4) 12) 1;
+ }
+ }
+
+ if (dispRefModeEn || isocEn) {
+ dword |= PW_STP_UP50 | PW_STP_DN50 ;
+ } else {
/* get number of cores for PowerStepUp PowerStepDown in server
1 core - 400nS - b
2 cores - 200nS - 0010b
@@ -210,28 +245,31 @@
dword |= PW_STP_UP100 | PW_STP_DN100;
break;
}
+ }
}
return dword;
}
-static void config_clk_power_ctrl_reg0(int node) {
+static void config_clk_power_ctrl_reg0(int node, u32 cpuRev, u8 procPkg) {
device_t dev = NODE_PCI(node, 3);
-
/* Program fields in Clock Power/Control register0 (F3xD4) */
/* set F3xD4 Clock Power/Timing Control 0 Register
* NbClkDidApplyAll=1b
- * NbClkDid=100b
+ * NbClkDid=100b or 101b
* PowerStepUp= platform dependent
* PowerStepDown= platform dependent
* LinkPllLink=01b
- * ClkRampHystSel=HW default
+ * ClkRampHystCtl=HW default
+ * ClkRampHystSel=b
*/
u32 dword= pci_read_config32(dev, 0xd4);
dword = CPTC0_MASK;
- dword |= NB_CLKDID_ALL | NB_CLKDID | LNK_PLL_LOCK; /* per BKDG */
-dword |= power_up_down(node);
+dword |= NB_CLKDID_ALL | LNK_PLL_LOCK | CLK_RAMP_HYST_SEL_VAL;
+dword |= (nb_clk_did(node,cpuRev,procPkg) NB_CLKDID_SHIFT);
+
+dword |= power_up_down(node, procPkg);
pci_write_config32(dev, 0xd4, dword);
@@ -296,13 +334,15 @@
for (i = 0; i nodes; i++) {
printk(BIOS_DEBUG, Prep FID/VID Node:%02x \n, i);
dev = NODE_PCI(i, 3);
+u32 cpuRev = mctGetLogicalCPUID(0xFF) ;
+ u8 procPkg = mctGetProcessorPackageType();
setVSRamp(dev);
/* BKDG r31116 2010-04-22 2.4.1.7 step b F3xD8[VSSlamTime] */
/* Figure out the value for VsSlamTime and program it */
recalculateVsSlamTimeSettingOnCorePre(dev);
- config_clk_power_ctrl_reg0(i);
+config_clk_power_ctrl_reg0(i,cpuRev,procPkg);
config_power_ctrl_misc_reg(dev);
--- src/northbridge/amd/amdfam10/raminit_amdmct.c 2011-02-13 14:37:10.0 +0100
+++ src/northbridge/amd/amdfam10/raminit_amdmct.c 2011-02-13 14:41:48.0 +0100
@@ -214,6 +214,11 @@
return ret;
}
+static u8 mctGetProcessorPackageType(void) {
+ /* FIXME: I guess this belongs wherever mctGetLogicalCPUID ends up ? */
+ u32 BrandId = cpuid_ebx(0x8001);
+ return (u8)((BrandId 28) 0x0F);
+}
static void raminit_amdmct(struct sys_info *sysinfo)
{
--- src/northbridge/amd/amdht/AsPsDefs.h 2011-02-13 14:37:10.0 +0100
+++ src/northbridge/amd/amdht/AsPsDefs.h 2011-02-13 18:23:12.0 +0100
@@ -111,6 +111,7 @@
#define NB_FID_EN 0x20 /* NbFidEn bit ON */
#define NB_CLKDID_ALL
[coreboot] [PATCH] Fam10 FIDVID in SVI 10/25
see patch
Improving BKDG implementation of P-states,
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode.
I didn't understand quite why it did that iwth F3xA0 (Power
Control Misc Register) so I moved Pll Lock time to rules in defaults.h
and reimplemented F3xA0 programming. A later patch will remove
a part I don't know what's mean to do.
Signed-off-by: Xavi Drudis Ferran xdru...@tinet.cat
--- src/cpu/amd/model_10xxx/fidvid.c 2011-02-13 18:49:54.0 +0100
+++ src/cpu/amd/model_10xxx/fidvid.c 2011-02-13 19:20:08.0 +0100
@@ -275,19 +275,18 @@
}
-static void config_power_ctrl_misc_reg(device_t dev) {
+static void config_power_ctrl_misc_reg(device_t dev,u32 cpuRev, u8 procPkg) {
/* check PVI/SVI */
u32 dword = pci_read_config32(dev, 0xA0);
+
+/* BKDG r31116 2010-04-22 2.4.1.7 step b F3xA0[VSSlamVidMod] */
+/* PllLockTime and PsiVidEn set in ruleset in defaults.h */
if (dword PVI_MODE) { /* PVI */
/* set slamVidMode to 0 for PVI */
- dword = VID_SLAM_OFF | PLLLOCK_OFF;
- dword |= PLLLOCK_DFT_L;
- pci_write_config32(dev, 0xA0, dword);
+ dword = VID_SLAM_OFF ;
} else { /* SVI */
/* set slamVidMode to 1 for SVI */
- dword = PLLLOCK_OFF;
- dword |= PLLLOCK_DFT_L | VID_SLAM_ON;
- pci_write_config32(dev, 0xA0, dword);
+ dword |= VID_SLAM_ON;
u32 dtemp = dword;
@@ -299,7 +298,27 @@
else
dword = PWR_PLN_OFF;
pci_write_config32(dev, 0xD8, dword);
- }
+
+dword = dtemp;
+}
+/* set the rest of A0 since we're at it... */
+
+if (cpuRev (AMD_DA_Cx | AMD_RB_C3 )) {
+ dword |= NB_PSTATE_FORCE_ON;
+ } // else should we clear it ?
+
+
+if ((procPkg == AMD_PKGTYPE_G34) || (procPkg == AMD_PKGTYPE_C32) ) {
+ dword |= BP_INS_TRI_EN_ON ;
+ }
+
+ /* TODO: look into C1E state and F3xA0[IdleExitEn]*/
+#if CONFIG_SVI_HIGH_FREQ
+ if (cpuRev AMD_FAM10_C3) {
+ dword |= SVI_HIGH_FREQ_ON;
+ }
+#endif
+ pci_write_config32(dev, 0xA0, dword);
}
static void config_nb_syn_ptr_adj(device_t dev) {
@@ -344,8 +363,7 @@
config_clk_power_ctrl_reg0(i,cpuRev,procPkg);
-config_power_ctrl_misc_reg(dev);
-
+config_power_ctrl_misc_reg(dev,cpuRev,procPkg);
config_nb_syn_ptr_adj(dev);
config_acpi_pwr_state_ctrl_regs(dev);
--- src/northbridge/amd/amdfam10/Kconfig 2011-02-13 18:49:54.0 +0100
+++ src/northbridge/amd/amdfam10/Kconfig 2011-02-13 18:59:55.0 +0100
@@ -112,4 +112,12 @@
endif
endif
+config SVI_HIGH_FREQ
+ bool
+ default n
+ depends on NORTHBRIDGE_AMD_AMDFAM10
+help
+ Select this for boards with a Voltage Regulator able to operate
+ at 3.4 MHz in SVI mode. Ignored unless the AMD CPU is rev C3.
+
source src/northbridge/amd/amdfam10/root_complex/Kconfig
--- src/northbridge/amd/amdht/AsPsDefs.h 2011-02-13 18:49:54.0 +0100
+++ src/northbridge/amd/amdht/AsPsDefs.h 2011-02-13 19:17:58.0 +0100
@@ -198,11 +198,19 @@
#define PVI_MODE 0x100 /* PviMode bit mask */
#define VID_SLAM_OFF 0x0dfff /* set VidSlamMode OFF */
#define VID_SLAM_ON 0x02000 /* set VidSlamMode ON */
+#define NB_PSTATE_FORCE_ON 0x01000 /* set Northbridge P-state
+ force on next LDTSTOP
+ assertion on, in F3xA0 */
+#define BP_INS_TRI_EN_ON 0x4000 /* breakpoint pins tristate
+ enable in F3xA0 */
#define PLLLOCK_OFF 0x0c7ff /* PllLockTime Mask OFF */
#define PLLLOCK_DFT 0x1800 /* PllLockTime default value = 011b */
#define PLLLOCK_DFT_L 0x2800 /* PllLockTime long value = 101b */
-/* P-state Specification register base in PCI sapce */
+#define SVI_HIGH_FREQ_ON 0x0200 /* F3xA0[SviHighFreqSel] for
+ 3.4 MHz SVI in rev. C3 */
+
+/* P-state Specification register base in PCI space */
#define PS_SPEC_REG 0x1e0 /* PS Spec register base address */
#define PCI_REG_LEN 4 /* PCI register length */
#define NB_DID_MASK 0x1 /* NbDid bit mask */
--- src/northbridge/amd/amdmct/amddefs.h 2011-02-13 18:49:54.0 +0100
+++ src/northbridge/amd/amdmct/amddefs.h 2011-02-13 19:11:45.0 +0100
@@ -64,7 +64,9 @@
#define AMD_DR_ALL (AMD_DR_Bx)
#define AMD_FAM10_ALL (AMD_DR_ALL | AMD_RB_C2 | AMD_HY_D0 | AMD_DA_C3 | AMD_DA_C2 | AMD_RB_C3 )
#define AMD_FAM10_GT_B0 (AMD_FAM10_ALL ~(AMD_DR_B0))
-#define AMD_DR_Cx (AMD_RB_C2 | AMD_DA_C2 | AMD_RB_C3 | AMD_DA_C3)
+#define AMD_DA_Cx (AMD_DA_C2 | AMD_DA_C3)
+#define AMD_DR_Cx (AMD_RB_C2 | AMD_RB_C3 | AMD_DA_Cx)
+#define AMD_FAM10_C3 (AMD_RB_C3 | AMD_DA_C3)
#define AMD_DR_Dx (AMD_HY_D0)
#define AMD_DRBH_Cx (AMD_DR_Cx | AMD_HY_D0 )
#define AMD_DRBA23_RBC2 (AMD_DR_BA | AMD_DR_B2 | AMD_DR_B3 | AMD_RB_C2 )
--- src/cpu/amd/model_10xxx/defaults.h (revision 6323)
+++ src/cpu/amd/model_10xxx/defaults.h (working copy)
@@ -68,7 +68,7 @@ static const struct {
1 24,
[coreboot] [PATCH] Fam10 FIDVID in SVI 11/25
see patch
Improving BKDG implementation of P-states,
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode.
BKDG says nbSynPtrAdj may also be 6 sometimes.
Signed-off-by: Xavi Drudis Ferran xdru...@tinet.cat
--- src/cpu/amd/model_10xxx/fidvid.c 2011-02-13 19:30:42.0 +0100
+++ src/cpu/amd/model_10xxx/fidvid.c 2011-02-13 20:23:12.0 +0100
@@ -321,14 +321,26 @@
pci_write_config32(dev, 0xA0, dword);
}
-static void config_nb_syn_ptr_adj(device_t dev) {
+static void config_nb_syn_ptr_adj(device_t dev, u32 cpuRev) {
/* Note the following settings are additional from the ported
* function setFidVidRegs()
*/
+/* adjust FIFO between nb and core clocks to max allowed
+ values (min latency) */
+ u32 nbPstate = pci_read_config32(dev,0x1f0) NB_PSTATE_MASK;
+u8 nbSynPtrAdj;
+ if ((cpuRev (AMD_DR_Bx|AMD_DA_Cx) )
+ || ( (cpuRev AMD_RB_C3) (nbPstate!=0))) {
+ nbSynPtrAdj = 5;
+ } else {
+ nbSynPtrAdj = 6;
+ }
+
u32 dword = pci_read_config32(dev, 0xDc);
- dword |= 0x5 12; /* NbsynPtrAdj set to 0x5 per BKDG (needs reset) */
+dword = ~ NB_SYN_PTR_ADJ_MASK;
+ dword |= nbSynPtrAdj NB_SYN_PTR_ADJ_POS;
+/* NbsynPtrAdj set to 5 or 6 per BKDG (needs reset) */
pci_write_config32(dev, 0xdc, dword);
-
}
static void config_acpi_pwr_state_ctrl_regs(device_t dev) {
@@ -364,7 +376,7 @@
config_clk_power_ctrl_reg0(i,cpuRev,procPkg);
config_power_ctrl_misc_reg(dev,cpuRev,procPkg);
- config_nb_syn_ptr_adj(dev);
+ config_nb_syn_ptr_adj(dev,cpuRev);
config_acpi_pwr_state_ctrl_regs(dev);
--- src/northbridge/amd/amdht/AsPsDefs.h 2011-02-13 19:30:47.0 +0100
+++ src/northbridge/amd/amdht/AsPsDefs.h 2011-02-13 20:12:44.0 +0100
@@ -181,6 +181,8 @@
#define CPTC2 0xdc /* Clock Power/Timing Control2 Register*/
#define PS_MAX_VAL_POS 8 /* PstateMaxValue bit shift */
#define PS_MAX_VAL_MASK 0xf8ff /* PstateMaxValue Mask off */
+#define NB_SYN_PTR_ADJ_POS 12/* NbsynPtrAdj bit shift */
+#define NB_SYN_PTR_ADJ_MASK (0x7 NB_SYN_PTR_ADJ_POS) /* NbsynPtrAdj bit mask */
#define PRCT_INFO 0x1fc /* Product Info Register */
#define UNI_NB_FID_BIT 2 /* UniNbFid bit position */
@@ -224,6 +226,10 @@
/* F4x1F4 Northbridge P-state spec register */
#define NB_PS_SPEC_REG 0x1f4 /* Nb PS spec reg */
+/* F3x1F0 Product Information Register */
+#define NB_PSTATE_MASK 0x0007 /* NbPstate for CPU rev C3 */
+
+
#define NM_PS_REG 5 /* number of P-state MSR registers */
/* sFidVidInit.outFlags defines */
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] Fam10 FIDVID in SVI 12/25
see patch
Improving BKDG implementation of P-states,
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode.
Configuration of F3x[84:80] was hardcoded for rev B.
I change that for some code that checks for revision
and configures according to BKDG. Unfinished but
hopefully better than it was.
Signed-off-by: Xavi Drudis Ferran xdru...@tinet.cat
--- src/cpu/amd/model_10xxx/fidvid.c 2011-02-13 20:36:10.0 +0100
+++ src/cpu/amd/model_10xxx/fidvid.c 2011-02-13 20:43:41.0 +0100
@@ -343,11 +343,59 @@
pci_write_config32(dev, 0xdc, dword);
}
-static void config_acpi_pwr_state_ctrl_regs(device_t dev) {
- /* Rev B settings - FIXME: support other revs. */
- u32 dword = 0xA0E641E6;
+static void config_acpi_pwr_state_ctrl_regs(device_t dev, u32 cpuRev, u8 procPkg) {
+/* step 1, chapter 2.4.2.6 of AMD Fam 10 BKDG #31116 Rev 3.48 22.4.2010 */
+u32 dword;
+ u32 c1= 1;
+if (cpuRev (AMD_DR_Bx)) {
+// will coreboot ever enable cache scrubbing ?
+// if it does, will it be enough to check the current state
+// or should we configure for what we'll set up later ?
+dword = pci_read_config32(dev, 0x58);
+u32 scrubbingCache = dword
+ ( (0x1F 16) // DCacheScrub
+ | (0x1F 8) ); // L2Scrub
+ if (scrubbingCache) {
+ c1 = 0x80;
+ } else {
+ c1 = 0xA0;
+ }
+ } else { // rev C or later
+ // same doubt as cache scrubbing: ok to check current state ?
+dword = pci_read_config32(dev, 0xDC);
+u32 cacheFlushOnHalt = dword (7 16);
+if (!cacheFlushOnHalt) {
+ c1 = 0x80;
+ }
+ }
+ dword = (c1 24) | (0xE641E6);
pci_write_config32(dev, 0x84, dword);
- dword = 0xE600A681;
+
+
+/* FIXME: BKDG Table 100 says if the link is at a Gen1
+frequency and the chipset does not support a 10us minimum LDTSTOP
+assertion time, then { If ASB2 SVI then smaf001 = F6h else
+smaf001=87h. } else ... I hardly know what it means or how to check
+it from here, so I bluntly assume it is false and code here the else,
+which is easier */
+
+u32 smaf001 = 0xE6;
+if (cpuRev AMD_DR_Bx ) {
+ smaf001 = 0xA6;
+} else {
+#if CONFIG_SVI_HIGH_FREQ
+if (cpuRev (AMD_RB_C3 | AMD_DA_C3)) {
+ smaf001 = 0xF6;
+}
+#endif
+}
+u32 fidvidChange = 0;
+if (((cpuRev AMD_DA_Cx) (procPkg AMD_PKGTYPE_S1gX))
+ || (cpuRev AMD_RB_C3) ) {
+ fidvidChange=0x0B;
+}
+ dword = (0xE6 24) | (fidvidChange 16)
+| (smaf001 8) | 0x81;
pci_write_config32(dev, 0x80, dword);
}
@@ -378,7 +426,7 @@
config_power_ctrl_misc_reg(dev,cpuRev,procPkg);
config_nb_syn_ptr_adj(dev,cpuRev);
-config_acpi_pwr_state_ctrl_regs(dev);
+config_acpi_pwr_state_ctrl_regs(dev,cpuRev,procPkg);
dword = pci_read_config32(dev, 0x80);
printk(BIOS_DEBUG, F3x80: %08x \n, dword);
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] Fam10 FIDVID in SVI 13/25
see patch
Improving BKDG implementation of P-states,
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode.
Contemplate the possibility of nbCofVidUpdate not being
defined, trying to get closer to BKDG
Signed-off-by: Xavi Drudis Ferran xdru...@tinet.cat
--- src/cpu/amd/model_10xxx/fidvid.c 2011-02-13 21:09:15.0 +0100
+++ src/cpu/amd/model_10xxx/fidvid.c 2011-02-13 21:12:48.0 +0100
@@ -631,7 +631,11 @@
nodes = get_nodes();
nb_cof_vid_update = 0;
for (i = 0; i nodes; i++) {
- if (pci_read_config32(NODE_PCI(i, 3), 0x1FC) 1) {
+u32 cpuRev = mctGetLogicalCPUID(i) ;
+u32 nbCofVidUpdateDefined = (cpuRev (AMD_FAM10_LT_D));
+ if (nbCofVidUpdateDefined
+ (pci_read_config32(NODE_PCI(i, 3), 0x1FC)
+ NB_COF_VID_UPDATE_MASK)) {
nb_cof_vid_update = 1;
break;
}
--- src/northbridge/amd/amdht/AsPsDefs.h 2011-02-13 21:09:20.0 +0100
+++ src/northbridge/amd/amdht/AsPsDefs.h 2011-02-13 21:15:16.0 +0100
@@ -229,6 +229,8 @@
/* F3x1F0 Product Information Register */
#define NB_PSTATE_MASK 0x0007 /* NbPstate for CPU rev C3 */
+/* F3x1FC Product Information Register */
+#define NB_COF_VID_UPDATE_MASK 1 /* for CPU rev = C */
#define NM_PS_REG 5 /* number of P-state MSR registers */
--- src/northbridge/amd/amdmct/amddefs.h 2011-02-13 21:09:21.0 +0100
+++ src/northbridge/amd/amdmct/amddefs.h 2011-02-13 21:20:44.0 +0100
@@ -63,6 +63,7 @@
#define AMD_DR_GT_B0 (AMD_DR_ALL ~(AMD_DR_B0))
#define AMD_DR_ALL (AMD_DR_Bx)
#define AMD_FAM10_ALL (AMD_DR_ALL | AMD_RB_C2 | AMD_HY_D0 | AMD_DA_C3 | AMD_DA_C2 | AMD_RB_C3 )
+#define AMD_FAM10_LT_D (AMD_FAM10_ALL ~(AMD_HY_D0))
#define AMD_FAM10_GT_B0 (AMD_FAM10_ALL ~(AMD_DR_B0))
#define AMD_DA_Cx (AMD_DA_C2 | AMD_DA_C3)
#define AMD_DR_Cx (AMD_RB_C2 | AMD_RB_C3 | AMD_DA_Cx)
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] Fam10 FIDVID in SVI 14/25
see patch
Improving BKDG implementation of P-states,
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode.
Factor out some common expressions.
Add an error message when coreboots hangs waiting for a pstate
that never comes (it happened to me), and throw some
paranoia at it for good mesure.
If I understood BKDG fam10 CPUs never need a software initiated vid transition,
because the hardware knows what to do when you just request
a Pstate change if the cpu is properly configured. In fact
unifying a little what PVI and SVI do was better for my board (SVI).
So I drop transitionVid, which I didn't understand either (why
did it have a case for PVI if it is never called for PVI ?
Why did the PVI case distinguigh cpu or nb when PVI is
theoretically single voltage plane ? ).
Signed-off-by: Xavi Drudis Ferran xdru...@tinet.cat
--- src/cpu/amd/model_10xxx/fidvid.c 2011-02-13 21:29:50.0 +0100
+++ src/cpu/amd/model_10xxx/fidvid.c 2011-02-13 23:08:32.0 +0100
@@ -443,6 +443,62 @@
}
}
+static void waitCurrentPstate(u32 target_pstate){
+ msr_t initial_msr = rdmsr(TSC_MSR);
+ msr_t pstate_msr = rdmsr(CUR_PSTATE_MSR);
+ msr_t tsc_msr;
+ u8 timedout ;
+
+ /* paranoia ? I fear when we run fixPsNbVidBeforeWR we can enter a
+ * P1 that is a copy of P0, therefore has the same NB DID but the
+ * TSC will count twice per tick, so we have to wait for twice the
+ * count to achieve the desired timeout. But I'm likely to
+ * misunderstand this...
+ */
+ u32 corrected_timeout = ((pstate_msr.lo==1)
+ (!(rdmsr(0xC0010065).lo NB_DID_M_ON)) ) ?
+ WAIT_PSTATE_TIMEOUT*2 : WAIT_PSTATE_TIMEOUT ;
+ msr_t timeout;
+
+ timeout.lo = initial_msr.lo + corrected_timeout ;
+ timeout.hi = initial_msr.hi;
+ if ( (((u32)0x) - initial_msr.lo) corrected_timeout ) {
+ timeout.hi++;
+ }
+
+ // assuming TSC ticks at 1.25 ns per tick (800 MHz)
+ do {
+ pstate_msr = rdmsr(CUR_PSTATE_MSR);
+ tsc_msr = rdmsr(TSC_MSR);
+ timedout = (tsc_msr.hi timeout.hi)
+ || ((tsc_msr.hi == timeout.hi) (tsc_msr.lo timeout.lo ));
+ } while ( (pstate_msr.lo != target_pstate) (! timedout) ) ;
+
+ if (pstate_msr.lo != target_pstate) {
+msr_t limit_msr = rdmsr(0xc0010061);
+printk(BIOS_ERR, *** Time out waiting for P-state %01x. Current P-state %01x P-state current limit MSRC001_0061=%02x\n, target_pstate, pstate_msr.lo, limit_msr.lo);
+
+do { // should we just go on instead ?
+ pstate_msr = rdmsr(CUR_PSTATE_MSR);
+} while ( pstate_msr.lo != target_pstate ) ;
+ }
+}
+
+static void set_pstate(u32 nonBoostedPState) {
+ msr_t msr;
+
+ // Transition P0 for calling core.
+ msr = rdmsr(0xC0010062);
+
+ msr.lo = nonBoostedPState;
+ wrmsr(0xC0010062, msr);
+
+ /* Wait for P0 to set. */
+waitCurrentPstate(nonBoostedPState);
+}
+
+
+
static void UpdateSinglePlaneNbVid(void)
{
@@ -468,56 +524,62 @@
}
}
-static void fixPsNbVidBeforeWR(u32 newNbVid, u32 coreid)
-{
- msr_t msr;
- u8 startup_pstate;
-
- /* This function sets NbVid before the warm reset.
- * Get StartupPstate from MSRC001_0071.
- * Read Pstate register pionted by [StartupPstate].
- * and copy its content to P0 and P1 registers.
- * Copy newNbVid to P0[NbVid].
- * transition to P1 on all cores,
- * then transition to P0 on core 0.
- * Wait for MSRC001_0063[CurPstate] = 000b on core 0.
- */
-
- msr = rdmsr(0xc0010071);
+static void fixPsNbVidBeforeWR(u32 newNbVid, u32 coreid, u32 dev, u8 pviMode)
+ {
+ msr_t msr;
+ u8 startup_pstate;
+
+ /* This function sets NbVid before the warm reset.
+ * Get StartupPstate from MSRC001_0071.
+ * Read Pstate register pointed by [StartupPstate].
+ * and copy its content to P0 and P1 registers.
+ * Copy newNbVid to P0[NbVid].
+ * transition to P1 on all cores,
+ * then transition to P0 on core 0.
+ * Wait for MSRC001_0063[CurPstate] = 000b on core 0.
+ * see BKDG rev 3.48 2.4.2.9.1 BIOS NB COF and VID Configuration
+ * for SVI and Single-Plane PVI Systems
+ */
+
+ msr = rdmsr(0xc0010071);
startup_pstate = (msr.hi (32 - 32)) 0x07;
- /* Copy startup pstate to P1 and P0 MSRs. Set the maxvid for this node in P0.
- * Then transition to P1 for corex and P0 for core0.
- * These setting will be cleared by the warm reset
+ /* Copy startup pstate to P1 and P0 MSRs. Set the maxvid for
+ * this node in P0. Then transition to P1 for corex and P0
+ * for core0. These setting will be cleared by the warm reset
*/
msr = rdmsr(0xC0010064 + startup_pstate);
wrmsr(0xC0010065, msr);
wrmsr(0xC0010064, msr);
+
+/* missing step 2 from BDKG , F3xDC[PstateMaxVal] =
+ * max(1,F3xDC[PstateMaxVal] ) because it would take
+ * synchronization between cores and we don't think
+ * PstatMaxVal is going to be 0 on cold
[coreboot] [PATCH] Fam10 FIDVID in SVI 15/25
see patch
Improving BKDG implementation of P-states,
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode.
Looking at BKDG the process for updating
Pstate Nb vid after warn reset seemed
more similar to the codethat was there fo
pvi than the one for svi, so I called the
pvi function passing a pvi/svi flag. I don't
find documentation on why should UpdateSinglePlaneNbVid()
be called in PVI, but since I can't test it,
I leave it as it was.
This patch showed some progress beyond fidvid in my
boar,d but only sometimes, most times it just didn't
work.
Signed-off-by: Xavi Drudis Ferran xdru...@tinet.cat
--- src/cpu/amd/model_10xxx/fidvid.c 2011-02-13 23:08:32.0 +0100
+++ src/cpu/amd/model_10xxx/fidvid.c 2011-02-14 01:10:08.0 +0100
@@ -732,36 +732,17 @@
}
-static void updateSviPsNbVidAfterWR(u32 newNbVid)
-{
- msr_t msr;
- u8 i;
-
- /* This function copies newNbVid to NbVid bits in P-state Registers[4:0]
- * for SVI mode.
- */
-
- for (i = 0; i 5; i++) {
- msr = rdmsr(0xC0010064 + i);
- if ((msr.hi 31) 1) { /* PstateEn? */
- msr.lo = ~(0x7F 25);
- msr.lo |= (newNbVid 0x7F) 25;
- wrmsr(0xC0010064 + i, msr);
- }
- }
-}
-
-
-static void fixPsNbVidAfterWR(u32 newNbVid, u8 NbVidUpdatedAll)
+static void fixPsNbVidAfterWR(u32 newNbVid, u8 NbVidUpdatedAll,u8 pviMode)
{
msr_t msr;
u8 i;
u8 StartupPstate;
- /* This function copies newNbVid to NbVid bits in P-state
- * Registers[4:0] if its NbDid bit=0 and PstateEn bit =1 in case of
- * NbVidUpdatedAll =0 or copies copies newNbVid to NbVid bits in
- * P-state Registers[4:0] if its and PstateEn bit =1 in case of
+ /* BKDG 2.4.2.9.1 11-12
+ * This function copies newNbVid to NbVid bits in P-state
+ * Registers[4:0] if its NbDid bit=0, and IddValue!=0 in case of
+ * NbVidUpdatedAll =0 or copies newNbVid to NbVid bits in
+ * P-state Registers[4:0] if its IddValue!=0 in case of
* NbVidUpdatedAll=1. Then transition to StartPstate.
*/
@@ -769,26 +750,28 @@
for (i = 0; i 5; i++) {
msr = rdmsr(0xC0010064 + i);
/* NbDid (bit 22 of P-state Reg) == 0 or NbVidUpdatedAll = 1 */
- if msr.lo 22) 1) == 0) || NbVidUpdatedAll) {
- msr.lo = ~(0x7F 25);
- msr.lo |= (newNbVid 0x7F) 25;
+ if ( (msr.hi PS_IDD_VALUE_MASK)
+ (msr.hi PS_EN_MASK)
+(((msr.lo PS_NB_DID_MASK) == 0) || NbVidUpdatedAll)) {
+ msr.lo = PS_NB_VID_M_OFF;
+ msr.lo |= (newNbVid 0x7F) PS_NB_VID_SHFT;
wrmsr(0xC0010064 + i, msr);
}
}
- UpdateSinglePlaneNbVid();
-
+/* Not documented. Would overwrite Nb_Vids just copied
+ * should we just update cpu_vid or nothing at all ?
+ */
+ if (pviMode) { //single plane
+UpdateSinglePlaneNbVid();
+ }
/* For each core in the system, transition all cores to StartupPstate */
msr = rdmsr(0xC0010071);
StartupPstate = msr.hi 0x07;
- msr = rdmsr(0xC0010062);
- msr.lo = StartupPstate;
- wrmsr(0xC0010062, msr);
-
- /* Wait for StartupPstate to set. */
- do {
- msr = rdmsr(0xC0010063);
- } while (msr.lo != StartupPstate);
+
+ /* Set and wait for StartupPstate to set. */
+set_pstate(StartupPstate);
+
}
static void finalPstateChange(void)
@@ -823,15 +806,12 @@
NbVidUpdateAll = (reg1fc 1) 1;
if (nb_cof_vid_update) {
- if (pvimode) {
- nbvid = (reg1fc 7) 0x7F;
- /* write newNbVid to P-state Reg's NbVid if its NbDid=0 */
- fixPsNbVidAfterWR(nbvid, NbVidUpdateAll);
- } else { /* SVI */
- nbvid = ((reg1fc 7) 0x7F) - ((reg1fc 17) 0x1F);
- updateSviPsNbVidAfterWR(nbvid);
+ if (!pvimode) { /* SVI */
+ nbvid = nbvid - ((reg1fc 17) 0x1F);
}
- } else { /* !nb_cof_vid_update */
+ /* write newNbVid to P-state Reg's NbVid if its NbDid=0 */
+ fixPsNbVidAfterWR(nbvid, NbVidUpdateAll,pvimode);
+ } else { /* !nb_cof_vid_update */
if (pvimode)
UpdateSinglePlaneNbVid();
}
--- src/northbridge/amd/amdht/AsPsDefs.h 2011-02-13 22:19:01.0 +0100
+++ src/northbridge/amd/amdht/AsPsDefs.h 2011-02-14 01:10:13.0 +0100
@@ -44,6 +44,10 @@
#define PS_REG3 3 /* offset for P3 */
#define PS_REG4 4 /* offset for P4 */
+#define PS_IDD_VALUE_SHFT 0/* IddValue: current value
+ field offset for msr.hi */
+#define PS_IDD_VALUE_MASK 0xFF /* IddValue: current value
+ field mask for msr.hi */
#define PS_PSDIS_MASK 0x7fff /* disable P-state register */
#define PS_EN_MASK 0x8000 /* P-state register enable mask */
#define PS_NB_DID_MASK 0x40 /* P-state Reg[NbDid] Mask */
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] Fam10 FIDVID in SVI 16/25
see patch
Improving BKDG implementation of P-states,
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode.
Add to init_fidvid_stage2 some step for my CPU (rev C3)
mentioned in BKDG 2.4.2.6 (5) that was missing
Signed-off-by: Xavi Drudis Ferran xdru...@tinet.cat
--- src/cpu/amd/model_10xxx/fidvid.c 2011-02-14 01:10:08.0 +0100
+++ src/cpu/amd/model_10xxx/fidvid.c 2011-02-14 23:11:05.0 +0100
@@ -65,6 +65,25 @@
dword);
}
}
+static void enableNbPState1( device_t dev ) {
+ u32 cpuRev = mctGetLogicalCPUID(0xFF);
+ if (cpuRev AMD_FAM10_C3) {
+u32 nbPState = (pci_read_config32(dev, 0x1F0) NB_PSTATE_MASK);
+if ( nbPState){
+ u32 nbVid1 = (pci_read_config32(dev, 0x1F4) NB_VID1_MASK) NB_VID1_SHIFT;
+ u32 i;
+ for (i = nbPState; i NM_PS_REG; i++) {
+ msr_t msr = rdmsr(PS_REG_BASE + i);
+ if (msr.hi PS_EN_MASK ) {
+msr.hi |= NB_DID_M_ON;
+msr.lo = NB_VID_MASK_OFF;
+ msr.lo |= ( nbVid1 NB_VID_POS);
+ wrmsr(PS_REG_BASE + i, msr);
+ }
+ }
+}
+ }
+}
static void setVSRamp(device_t dev) {
/* BKDG r31116 2010-04-22 2.4.1.7 step b F3xD8[VSRampTime]
@@ -820,6 +839,7 @@
dtemp |= PLLLOCK_DFT_L;
pci_write_config32(dev, 0xA0, dtemp);
+enableNbPState1(dev);
finalPstateChange();
/* Set TSC to tick at the P0 ndfid rate */
--- src/northbridge/amd/amdht/AsPsDefs.h 2011-02-14 01:10:13.0 +0100
+++ src/northbridge/amd/amdht/AsPsDefs.h 2011-02-14 23:11:11.0 +0100
@@ -153,6 +153,8 @@
#define PS_2 0x0002 /* P-state 2 */
#define PS_CPU_DID_1 0x40 /* Cpu Did 1 */
+#define NB_VID1_MASK 0x3f80 /* F3x1F4[NbVid1]*/
+#define NB_VID1_SHIFT 7 /* F3x1F4[NbVid1] */
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] Fam10 FIDVID in SVI 17/25
see patch
Improving BKDG implementation of P-states,
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode.
Add to init_fidvid_stage2 some step
mentioned in BKDG 2.4.2.7 that was missing . Some lines
are dead code now, but may handy if one day we support
revison E CPUs.
Signed-off-by: Xavi Drudis Ferran xdru...@tinet.cat
--- src/cpu/amd/model_10xxx/fidvid.c 2011-02-14 23:11:05.0 +0100
+++ src/cpu/amd/model_10xxx/fidvid.c 2011-02-15 00:13:25.0 +0100
@@ -85,6 +85,58 @@
}
}
+static u8 setPStateMaxVal( device_t dev ) {
+ u8 i,maxpstate=0;
+ for (i = 0; i NM_PS_REG; i++) {
+ msr_t msr = rdmsr(PS_REG_BASE + i);
+ if (msr.hi PS_IDD_VALUE_MASK) {
+ msr.hi |= PS_EN_MASK ;
+ wrmsr(PS_REG_BASE + i, msr);
+ }
+ if (msr.hi | PS_EN_MASK) {
+ maxpstate = i;
+ }
+ }
+ //FIXME: CPTC2 and HTC_REG should get max per node, not per core ?
+ u32 reg = pci_read_config32(dev, CPTC2);
+ reg = PS_MAX_VAL_MASK;
+ reg |= (maxpstate PS_MAX_VAL_POS);
+ pci_write_config32(dev, CPTC2,reg);
+ return maxpstate;
+}
+
+static void dualPlaneOnly( device_t dev ) {
+ // BKDG 2.4.2.7
+
+ u32 cpuRev = mctGetLogicalCPUID(0xFF);
+ if ((mctGetProcessorPackageType() == AMD_PKGTYPE_AM3_2r2)
+ (cpuRev AMD_DR_Cx)) { // should be rev C or rev E but there's no constant for E
+if ( (pci_read_config32(dev, 0x1FC) DUAL_PLANE_ONLY_MASK)
+ (pci_read_config32(dev, 0xA0) PVI_MODE) ){
+ if (cpuid_edx(0x8007) CPB_MASK) {
+ // revision E only, but E is apparently not supported yet, therefore untested
+ msr_t minPstate = rdmsr(0xC0010065);
+ wrmsr(0xC0010065, rdmsr(0xC0010068) );
+ wrmsr(0xC0010068,minPstate);
+ } else {
+ msr_t msr;
+ msr.lo=0; msr.hi=0;
+ wrmsr(0xC0010064, rdmsr(0xC0010068) );
+ wrmsr(0xC0010068, msr );
+ }
+
+ //FIXME: CPTC2 and HTC_REG should get max per node, not per core ?
+ u8 maxpstate = setPStateMaxVal(dev);
+
+ u32 reg = pci_read_config32(dev, HTC_REG);
+ reg = HTC_PS_LMT_MASK;
+ reg |= (maxpstate PS_LIMIT_POS);
+ pci_write_config32(dev, HTC_REG,reg);
+
+}
+ }
+}
+
static void setVSRamp(device_t dev) {
/* BKDG r31116 2010-04-22 2.4.1.7 step b F3xD8[VSRampTime]
* If this field accepts 8 values between 10 and 500 us why
@@ -839,6 +891,7 @@
dtemp |= PLLLOCK_DFT_L;
pci_write_config32(dev, 0xA0, dtemp);
+dualPlaneOnly(dev);
enableNbPState1(dev);
finalPstateChange();
--- src/northbridge/amd/amdht/AsPsDefs.h 2011-02-14 23:11:11.0 +0100
+++ src/northbridge/amd/amdht/AsPsDefs.h 2011-02-15 00:13:30.0 +0100
@@ -191,6 +191,7 @@
#define NB_SYN_PTR_ADJ_MASK (0x7 NB_SYN_PTR_ADJ_POS) /* NbsynPtrAdj bit mask */
#define PRCT_INFO 0x1fc /* Product Info Register */
+#define DUAL_PLANE_ONLY_MASK 0x8000 /* F3x1FC[DualPlaneOnly] */
#define UNI_NB_FID_BIT 2 /* UniNbFid bit position */
#define UNI_NB_VID_BIT 7 /* UniNbVid bit position */
#define SPLT_NB_FID_OFFSET 14 /* SpltNbFidOffset value bit position */
@@ -199,6 +200,8 @@
#define NB_VID_UPDATE_ALL 0x02 /* F3x1FC[NbVidUpdatedAll] bit mask */
#define C_FID_DID_M_OFF 0xfe00 /* mask off Core FID DID */
+#define CPB_MASK 0x0020 /* core performance
+ boost. CPUID Fn8000 0007 edx */
#define PW_CTL_MISC 0x0a0 /* Power Control Miscellaneous Register */
#define COF_VID_PROG_BIT 0x8000 /* CofVidProg bit. 0= unfused part */
#define DUAL_VDD_BIT 0x4000 /* DualVdd bit. */
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] Fam10 FIDVID in SVI 18/25
see patch
Improving BKDG implementation of P-states,
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode.
Add an untested step in BKDG 2.4.2.8. I don't
have the hardware with Core Performance Boost and
I think it's only available in revision E that does
not even have a constant yet.
Signed-off-by: Xavi Drudis Ferran xdru...@tinet.cat
--- src/cpu/amd/model_10xxx/fidvid.c 2011-02-15 00:13:25.0 +0100
+++ src/cpu/amd/model_10xxx/fidvid.c 2011-02-15 00:37:07.0 +0100
@@ -65,6 +65,24 @@
dword);
}
}
+
+static void applyBoostFIDOffset( device_t dev ) {
+ // BKDG 2.4.2.8
+ // revision E only, but E is apparently not supported yet, therefore untested
+ if ((cpuid_edx(0x8007) CPB_MASK)
+((cpuid_ecx(0x8008) NC_MASK) ==5) ) {
+ u32 core = get_node_core_id_x().coreid;
+ u32 asymetricBoostThisCore = ((pci_read_config32(dev, 0x10C) (core*2))) 3;
+ msr_t msr = rdmsr(PS_REG_BASE);
+ u32 cpuFid = msr.lo PS_CPU_FID_MASK;
+ cpuFid = cpuFid + asymetricBoostThisCore;
+ msr.lo = ~PS_CPU_FID_MASK;
+ msr.lo |= cpuFid ;
+ wrmsr(PS_REG_BASE , msr);
+
+ }
+}
+
static void enableNbPState1( device_t dev ) {
u32 cpuRev = mctGetLogicalCPUID(0xFF);
if (cpuRev AMD_FAM10_C3) {
@@ -892,7 +910,9 @@
pci_write_config32(dev, 0xA0, dtemp);
dualPlaneOnly(dev);
+applyBoostFIDOffset(dev);
enableNbPState1(dev);
+
finalPstateChange();
/* Set TSC to tick at the P0 ndfid rate */
--- src/northbridge/amd/amdht/AsPsDefs.h 2011-02-15 00:13:30.0 +0100
+++ src/northbridge/amd/amdht/AsPsDefs.h 2011-02-15 00:37:13.0 +0100
@@ -61,6 +61,8 @@
#define PS_NB_VID_SHFT 25 /* P-state NBVID shift */
#define PS_DIS 0x7fff /* disable P-state reg */
#define PS_EN 0x8000 /* enable P-state reg */
+#define PS_CPU_FID_MASK 0x03f /* MSRC001_00[68:64][CpuFid]
+ Core Frequency Id */
#define PS_CURDIV_SHFT 8 /* P-state Current Divisor shift position */
#define PS_CPUDID_SHIFT 6 /* P-state CPU DID shift position */
@@ -202,6 +204,8 @@
#define CPB_MASK 0x0020 /* core performance
boost. CPUID Fn8000 0007 edx */
+#define NC_MASK 0x00FF /* number of cores - 1. CPUID
+ Fn8000 0008 ecx */
#define PW_CTL_MISC 0x0a0 /* Power Control Miscellaneous Register */
#define COF_VID_PROG_BIT 0x8000 /* CofVidProg bit. 0= unfused part */
#define DUAL_VDD_BIT 0x4000 /* DualVdd bit. */
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] Fam10 FIDVID in SVI 19/25
see patch
Improving BKDG implementation of P-states,
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode.
Well, I understand it better like this, but maybe
it's only me, part of the changes are paranoic, and
the only effective change is for a factor depending on
mobile or not that I can't test.
Signed-off-by: Xavi Drudis Ferran xdru...@tinet.cat
--- src/cpu/amd/model_10xxx/fidvid.c 2011-02-15 00:37:07.0 +0100
+++ src/cpu/amd/model_10xxx/fidvid.c 2011-02-15 01:23:40.0 +0100
@@ -155,6 +155,18 @@
}
}
+static int vidTo100uV(u8 vid)
+{// returns voltage corresponding to vid in tenths of mV, i.e. hundreds of uV
+ // BKDG #31116 rev 3.48 2.4.1.6
+ int voltage;
+ if (vid = 0x7c) {
+voltage = 0;
+ } else {
+voltage = (15500 - (125*vid));
+ }
+ return voltage;
+}
+
static void setVSRamp(device_t dev) {
/* BKDG r31116 2010-04-22 2.4.1.7 step b F3xD8[VSRampTime]
* If this field accepts 8 values between 10 and 500 us why
@@ -181,12 +193,14 @@
/* This function calculates the VsSlamTime using the range of possible
* voltages instead of a hardcoded 200us.
- * Note:This function is called from setFidVidRegs and setUserPs after
- * programming a custom Pstate.
+ * Note: his function is called only from prep_fid_change,
+ * and that from init_cpus.c finalize_node_setup()
+ * (after set AMD MSRs and init ht )
*/
+/* BKDG r31116 2010-04-22 2.4.1.7 step b F3xD8[VSSlamTime] */
/* Calculate Slam Time
- * Vslam = 0.4us/mV * Vp0 - (lowest out of Vpmin or Valt)
+ * Vslam = (mobileCPU?0.2:0.4)us/mV * (Vp0 - (lowest out of Vpmin or Valt)) mV
* In our case, we will scale the values by 100 to avoid
* decimals.
*/
@@ -200,8 +214,17 @@
pviModeFlag = 0;
/* Get P0's voltage */
+/* MSRC001_00[68:64] are not programmed yet when called from
+ prep_fid_change, one might use F4x1[F0:E0] instead, but
+ theoretically MSRC001_00[68:64] are equal to them after
+ reset. */
msr = rdmsr(0xC0010064);
highVoltageVid = (u8) ((msr.lo PS_CPU_VID_SHFT) 0x7F);
+if (!(msr.hi 0x8000)) {
+ printk(BIOS_ERR,P-state info in MSRC001_0064 is invalid !!!\n);
+highVoltageVid = (u8) ((pci_read_config32(dev, 0x1E0)
+ PS_CPU_VID_SHFT) 0x7F);
+ }
/* If SVI, we only care about CPU VID.
* If PVI, determine the higher voltage b/t NB and CPU
@@ -212,17 +235,23 @@
highVoltageVid = bValue;
}
- /* Get Pmin's index */
+ /* Get PSmax's index */
msr = rdmsr(0xC0010061);
- bValue = (u8) ((msr.lo PS_CUR_LIM_SHFT) BIT_MASK_3);
-
- /* Get Pmin's VID */
+ bValue = (u8) ((msr.lo PS_MAX_VAL_SHFT) BIT_MASK_3);
+
+ /* Get PSmax's VID */
msr = rdmsr(0xC0010064 + bValue);
lowVoltageVid = (u8) ((msr.lo PS_CPU_VID_SHFT) 0x7F);
+if (!(msr.hi 0x8000)) {
+ printk(BIOS_ERR,P-state info in MSR%8x is invalid !!!\n,0xC0010064 + bValue);
+lowVoltageVid = (u8) ((pci_read_config32(dev, 0x1E0+(bValue*4))
+ PS_CPU_VID_SHFT) 0x7F);
+ }
/* If SVI, we only care about CPU VID.
* If PVI, determine the higher voltage b/t NB and CPU
- */
+ * BKDG 2.4.1.7 (a)
+ */
if (pviModeFlag) {
bValue = (u8) ((msr.lo PS_NB_VID_SHFT) 0x7F);
if (lowVoltageVid bValue)
@@ -237,20 +266,9 @@
if (lowVoltageVid bValue)
lowVoltageVid = bValue;
- /* If Vids are 7Dh - 7Fh, force 7Ch to keep calculations linear */
- if (lowVoltageVid 0x7C) {
- lowVoltageVid = 0x7C;
- if (highVoltageVid 0x7C)
- highVoltageVid = 0x7C;
- }
+u8 mobileFlag = get_platform_type() AMD_PTYPE_MOB;
+ minimumSlamTime = (mobileFlag?2:4) * (vidTo100uV(highVoltageVid) - vidTo100uV(lowVoltageVid)); /* * 0.01 us */
- bValue = (u8) (lowVoltageVid - highVoltageVid);
-
- /* Each Vid increment is 12.5 mV. The minimum slam time is:
- * vidCodeDelta * 12.5mV * 0.4us/mV
- * Scale by 100 to avoid decimals.
- */
- minimumSlamTime = bValue * (125 * 4);
/* Now round up to nearest register setting.
* Note that if we don't find a value, we
--- src/northbridge/amd/amdht/AsPsDefs.h 2011-02-15 00:37:13.0 +0100
+++ src/northbridge/amd/amdht/AsPsDefs.h 2011-02-15 01:23:46.0 +0100
@@ -25,7 +25,7 @@
#define APIC_BAR_BP 0x100 /* APIC_BAR BSP bit */
#define PS_LIM_REG 0xC0010061 /* P-state Current Limit Register */
-#define PS_CUR_LIM_SHFT 4 /* P-state Current Limit shift position */
+#define PS_MAX_VAL_SHFT 4 /* P-state Maximum Value shift position */
#define PS_CTL_REG 0xC0010062 /* P-state Control Register */
#define PS_CMD_MASK_OFF 0xfff8 /* P-state Control Register CMD Mask OFF */
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] Fam10 FIDVID in SVI 20/25
see patch Improving BKDG implementation of P-states, CPU and northbridge frequency and voltage handling for Fam 10 in SVI mode. bits 13 - 15 of F3xd4 (StutterScrubEn, CacheFlushImmOnAllHalt and MTC1eEn are reserved for revisions D0 and earlier, so whe should not set them to 0 in fidvid.c config_clk_power_ctrl_reg0(...), called from prep_fid_change. For revisions D0 (when we support them) it is ok not ot clear them, because they are documented as 0 on reset. bit 12 should be left alone according to BKDG. Should I set 11:8 ClkRampHystSel to 0 in the mask too, just to indicate we're touching them ? We'll OR them to anyway... Signed-off-by: Xavi Drudis Ferran xdru...@tinet.cat --- src/northbridge/amd/amdht/AsPsDefs.h 2011-02-15 23:05:01.0 +0100 +++ src/northbridge/amd/amdht/AsPsDefs.h 2011-02-15 01:23:46.0 +0100 @@ -111,7 +111,7 @@ #define STC_PS_LMT_MASK 0x8fff /* StcPstateLimit mask off */ #define CPTC0 0x0d4 /* Clock Power/Timing Control0 Register*/ -#define CPTC0_MASK 0x000c0fff /* Reset mask for this register */ +#define CPTC0_MASK 0x000c /* Reset mask for this register */ #define CPTC0_NBFID_MASK 0xffe0 /* NbFid mask off for this register */ #define CPTC0_NBFID_MON 0x1f /* NbFid mask on for this register */ #define NB_FID_EN 0x20 /* NbFidEn bit ON */ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] Fam10 FIDVID in SVI 23/25
see patch
Improving BKDG implementation of P-states,
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode.
I remove an unused parameter and a duplicated constant.
Signed-off-by: Xavi Drudis Ferran xdru...@tinet.cat
--- src/cpu/amd/model_10xxx/fidvid.c 2011-02-16 01:08:16.0 +0100
+++ src/cpu/amd/model_10xxx/fidvid.c 2011-02-16 09:20:39.0 +0100
@@ -772,7 +772,7 @@
}
-static void init_fidvid_ap(u32 bsp_apicid, u32 apicid, u32 nodeid, u32 coreid)
+static void init_fidvid_ap(u32 apicid, u32 nodeid, u32 coreid)
{
u32 send;
--- src/cpu/amd/model_10xxx/init_cpus.c 2011-02-16 01:08:16.0 +0100
+++ src/cpu/amd/model_10xxx/init_cpus.c 2011-02-16 09:20:39.0 +0100
@@ -157,7 +157,7 @@
}
#if CONFIG_SET_FIDVID
-static void init_fidvid_ap(u32 bsp_apicid, u32 apicid, u32 nodeid, u32 coreid);
+static void init_fidvid_ap(u32 apicid, u32 nodeid, u32 coreid);
#endif
static inline __attribute__ ((always_inline))
@@ -344,8 +344,7 @@
printk(BIOS_DEBUG,
init_fidvid_ap(stage1) apicid: %02x\n,
apicid);
-init_fidvid_ap(bsp_apicid, apicid, id.nodeid,
- id.coreid);
+init_fidvid_ap(apicid, id.nodeid, id.coreid);
}
}
#endif
--- src/northbridge/amd/amdht/AsPsDefs.h 2011-02-16 01:08:22.0 +0100
+++ src/northbridge/amd/amdht/AsPsDefs.h 2011-02-16 09:20:44.0 +0100
@@ -58,7 +58,6 @@
#define PS_NB_VID_SHFT 25 /* P-state bit shift for NbVid */
#define PS_BOTH_VID_OFF 0x01ff01ff /* Mask NbVid CpuVid */
#define PS_CPU_NB_VID_SHFT 16 /* P-state bit shift from CpuVid to NbVid */
-#define PS_NB_VID_SHFT 25 /* P-state NBVID shift */
#define PS_DIS 0x7fff /* disable P-state reg */
#define PS_EN 0x8000 /* enable P-state reg */
#define PS_CPU_FID_MASK 0x03f /* MSRC001_00[68:64][CpuFid]
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] Fam10 FIDVID in SVI 24/25
see patch Improving BKDG implementation of P-states, CPU and northbridge frequency and voltage handling for Fam 10 in SVI mode. Documentation only. Adding a checklist to tell which function takes care of which requirement of BKDG . Signed-off-by: Xavi Drudis Ferran xdru...@tinet.cat --- src/cpu/amd/model_10xxx/fidvid.c (revision 6323) +++ src/cpu/amd/model_10xxx/fidvid.c (working copy) @@ -16,8 +16,93 @@ * along with this program; if not, write to the Free Software * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ +/* + * This file initializes the CPU cores for voltage and frequency settings + * in the different power states. + */ +/* +checklist (functions are in this file if no source file named) +Fam10 Bios and Kernel Development Guide #31116, rev 3.48, April 22, 2010 + +2.4.2.6 Requirements for p-states + +1.- F3x[84:80] According to table 100 : prep_fid_change + +2.- COF/VID : + 2.4.2.9.1 Steps 1,3-6 and warning for 2,7 if they apply + fixPsNbVidBeforeWR(...) + 2.4.2.9.1 Step 8 enable_fid_change + We do this for all nodes, I don't understand BKDG 100% on + whether this is or isn't meant by on the local + processor. Must be OK. + 2.4.2.9.1 Steps 9-10 (repeat 1-7 and reset) romstage.c/init_cpus ? + 2.4.2.9.1 Steps 11-12 init_fidvid_stage2 + 2.4.2.9.2 DualPlane PVI : Not supported, don't know how to detect, + needs specific circuitry. + +3.- 2.4.2.7 dualPlaneOnly(dev) + +4.- 2.4.2.8 applyBoostFIDOffset(dev) + +5.- enableNbPState1(dev) + +6.- 2.4.1.7 +a) UpdateSinglePlaneNbVid() +b) setVSRamp(), called from prep_fid_change +c) prep_fid_change +d) improperly, for lack of voltage regulator details?, +F3xA0[PsiVidEn] in defaults.h +F3xA0[PsiVid] in init_cpus.c AMD_SetupPSIVID_d (before prep_fid_change) + +7.- TODO (Core Performance Boost is only available in revision E cpus, and we + don't seem to support those yet, at least they don't have any + constant in amddefs.h ) + +8.- FIXME ? Transition to min Pstate according to 2.4.2.15.3 is required +by 2.4.2.6 after warm reset. But 2.4.2.15 states that it is not required +if the warm reset is issued by coreboot to update NbFid. So it is required +or not ? How can I tell who issued warm reset ? +Coreboot transitions to P0 instead, which is not recommended, and does +not follow 2.4.2.15.2 to do so. + +9.- TODO Requires information on current delivery capability +(depends on mainboard and maybe power supply ?). One might use a config +option with the maximum number of Ampers that the board can deliver to CPU. + +10.- [Multiprocessor] TODO 2.4.2.12 + [Uniprocessor] FIXME ? We call setPStateMaxVal() in init_fidvid_stage2, + but not sure this is what is meant by Determine the valid set of + P-states based on enabled P-states indicated + in MSRC001_00[68:64][PstateEn] in 2.4.2.6-10 + +11.- finalPstateChange() from init_fidvid_Stage2 (BKDG says just may, anyway) + +12.- generate ACPI for p-states. FIXME + Needs more assesment. There's some kind of fixed support that + does not seem to depend on CPU revision or actual MSRC001_00[68:64] + as BKDG apparently requires. + http://www.coreboot.org/ACPI#CPU_Power_Management + At least for Tilapia board: + src/mainboard/vendor/model/acpi_tables.c write_acpi_tables(...) calls + acpi_add_ssdt_pstates(...) + in /src/northbridge/amd/amdfam10/amdfam10_acpi.c + which apparently copies them from static info in + src/mainboard/vendor/model/acpi/cpstate.asl + +must also be completed + +a.- PllLockTime set in ruleset in defaults.h + BKDG says set it If MSRC001_00[68:64][CpuFid] is different between + any two enabled P-states, but since it does not say only if + I guess it is safe to do it always. + +b.- prep_fid_change(...) + + */ + #if CONFIG_SET_FIDVID + #include northbridge/amd/amdht/AsPsDefs.h static inline void print_debug_fv(const char *str, u32 val) -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] Fam10 FIDVID in SVI 25/25
see patch -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] searching volunteer to install coreboot on asus m4a78 pro
On Sat, Feb 12, 2011 at 05:33:44PM +0100, xdrudis wrote: http://search.digikey.com/scripts/DkSearch/dksus.dll?Detailname=W25Q80BVDAIG-ND Forgot to say: this is the one I bought (thanks to Rudolf Marek for the advice) and it's working here with flashrom. The original chip in my board was not yours, it was by Macronix, but yours seems even more similar, to my limited knowledge. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] searching volunteer to install coreboot on asus m4a78 pro
My setup is similar to yours, I bought it trying to get easy coreboot support (easy, not immediate, and also some features), I've spent some 6 months trying to install coreboot and it still does not boot. But I'm not experienced in low level programming and I don't have that much spare time to experiment. So don't count on me as a volunteer. It's also not something I'd like to do on ssh. You have to do a lot of trying and exchange one chip for another, and it's already slighty tiresome if you're there physically, let alone having to wait for someone on IRC... There's also some risk of breaking something that I wouldn't like to take. On Thu, Feb 10, 2011 at 04:09:18PM +0100, Jelle de Jong wrote: [1] http://debian.pastebin.com/mqphUf5U # details ASUSTeK M4A78 PRO Features I would like: * Serial Console Redirection Does your board have a serial port (RS232)? The photos look a lot like my board. Mine has one but I don't see it in yours http://www.mail-archive.com/coreboot@coreboot.org/msg24572.html Try to see the marking on the EPROM chip. I bet is the small chip on a 300MIL 8-PDIP socket between the red connectors (IDE and SATA ?) follow that thread in case it is the same chip, I finally bought the winbond chips from digikey in June 2010 Idx Box Ordered Cancelled Shipped Item Number/Description Back Unit Price Amount Order Euro Euro 1 1 3 0 3 W25Q80BVDAIG-ND 2.38000 7.14 SPI FLASH 8MBIT 8-DIP SCHED B: 854232 ECCN: EAR99 LEAD: LEAD FREEROHS: ROHS COMP COUNTRY/ORIGIN: TAIWAN And have worked perfectly with flashrom for me all these months. * AMD Athlon II X4 615e support I have a Phenom II X4 910e Looks quite similar. Yours is revision RB_C3 also, I think? I found fidvid.c did not suppport this version and coreboot hanged while setting frequency and voltage of the CPU. I've apparently fixed it but I have a 1600 lines patch, and I really should see how to break it up in chunks that can be reasonably reviewed . In fact for fidvid.c itself the patch is bigger than the file. I hope I can do something this weekend to break into decent patches... My board still doesn't boot though. It currently gets to ram stage and hangs while enabling pci devices. It's similar to a problem I found in romstage and I worked around it with a patch that wasn't probably the right approach (it wasn't commited). This time I'll have to see what's causing it (likely that I have an RX781, not an RS780, it's more or less the same without graphics, but I may have to tweak something somehow). * ECC Memory support Not sure this works * Readout volt,temp,rpm sensors * Boot 2.6 kernel support * Grub 2 (lvm, mdadm, ext4) support I think this will work I got two M4A78 PRO motherboards that I would like to give new life by getting coreboot on them. New life ? They are not so old as to have died yet... There're similar boards already that might work: src/mainboard/asus/m4a785-m src/mainboard/asus/m4a78-em -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] [sort of] multiplex console output from each core
On Sat, Jan 29, 2011 at 11:09:05AM +0100, xdrudis wrote: is what I have. My board does not get to ramstage, so it might not work there. It works for my serial console but should work for net or Ok, now I see it. It won't work with sprintf in ramstage. I shouldn't have modified vtxprintf but maybe console.c, either calling calc_id_buffer for each byte in __console_tx_byte (too expensive ?) or passing around id_buffer by more extensive modification (like changing tx_byte signature to add a channel parameter or something, maybe not worth it) Forget it and sorry for the noise. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] [sort of] multiplex console output from each core
On Sat, Jan 29, 2011 at 11:09:05AM +0100, xdrudis wrote: formats output. If someone has more than 16 cores does she really want to see ouput from all at a time? Redefining the weak function calc_id_buffer you can choose to have some of them mix into the same buffer or just filter out the output for some of them. Also wrong. Having several concurrent outputs with the same buffer id is not safe, demuxing could join the wrong half-characters. Filtering out some cores would be an option. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] [sort of] multiplex console output from each core
On Sun, Jan 30, 2011 at 08:32:58PM +0100, Stefan Reinauer wrote: * xdrudis xdru...@tinet.cat [110130 15:46]: On Sat, Jan 29, 2011 at 11:09:05AM +0100, xdrudis wrote: is what I have. My board does not get to ramstage, so it might not work there. It works for my serial console but should work for net or Ok, now I see it. It won't work with sprintf in ramstage. It should not be needed in ram stage, as we have locking there. Yes, it'd be mostly unneeded, but anyway the patch I sent does not disable it in ramstage. So it still causes sprintf to consume the double of bytes maybe beyond its buffers (and produce unreadable messages). The idea can work, the perl script may be usable, but the patches to C should be redone from scratch. In fact I think there's some subtle breakage already in romstage.c, since I didn't realise console_tx will check for \n to add \r and that won't work with CONFIG_DEBUX_MUXED in that patch, although it won't be noticed unless you have 16 cores (I think an \n from the 16th core would produce a \n). But continuing with the idea, the perl script might be changed to detect some string in the input and stop demultiplexing. Sonner or later coreboot may stop multiplexing or simply stop running and have some other software writing to serial port, and it'd be nice if the script would then simply copy the input unchanged (to all outputs if it's not writing to stdout only ?). -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] [sort of] multiplex console output from each core
On Sun, Jan 30, 2011 at 09:07:52PM +0100, Stefan Reinauer wrote: * xdrudis xdru...@tinet.cat [110130 20:59]: Yes, it'd be mostly unneeded, but anyway the patch I sent does not disable it in ramstage. So it still causes sprintf to consume the double of bytes maybe beyond its buffers (and produce unreadable messages). The idea can work, the perl script may be usable, but the patches to C should be redone from scratch. Can't you just hack up the muxing in console_tx_byte instead? That should solvle the problem and make the patch a tad less intrusive. yes, console_tx_byte or __console_tx_byte . The only drawback is that then I have to call calc_id_buffer for each byte, I guess it doesn't matter, but it was less overhead calling it once per call to vtxprintf (in fact there was another call in number(...) but still fewer than one per byte. But I just got past fidvid now, and I should clean up the mess of code I've been changing all these months and see what exactly fixed it, or if I can have a decent patch. Not sure it'll be much help for other CPU revisions beyond C3, though. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] [sort of] multiplex console output from each core
On Sun, Jan 30, 2011 at 01:05:54PM -0700, Marc Jones wrote: I think that the locking can be added via the BSPs cache. All multicore should use CAR and it is a matter of adding it where it won't get stepped on by the normal use of CAR. For AMD fam10, the sysinfo setup would need to be fixed up. Marc That is a little over my head, I believe. I thought in general the cache was a different memory for each core (let alone each node). My phenom has L3 cache common to all cores but I thought romstage is not using it. And I guess the functionality is slightly different : with muxing you get the node number in the output so you can format things in columns, etc. And it is not dependent on the architecture (except to find out the core number to use as buffer id). With locking you just separate output but don't know which core it comes from (but it becomes feasible to include the core number in the messages where appropiate, and you don't need demuxing, get less serial traffic...). locking in romstage might be useful for other things beyond console output, though. So both approaches have advantages. I'm just not sure how to implement locking. That's the main reason I didn't, even if some comment suggested it somewhere. Secondary excuses were that it seemed less alteration of the runtime behaviour not to lock, and that I could also set it up to filter out some output. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] [sort of] multiplex console output from each core
Hello.
This patch works for me but needs a small function calc_id_buffer for
each board/cpu/whatever. I only made one for amd quadcore because it
is what I have. My board does not get to ramstage, so it might not
work there. It works for my serial console but should work for net or
usb if I'm not mistaken. Also my tree is not up to date with svn
head. Likely things could be placed elsewhere or done better, so it
is mostly an idea.
But I'm unlikely to have more time for it and it works for me so far,
so I'm sending it so that it does not get lost and in case somebody
likes the idea and wants to commit or do it better.
Signed-off-by: Xavi Drudis Ferran xdru...@tinet.cat
My problem was with having serial output like
[...]
init node: 00 cores: 03
Start other core - nodeid: 00 cores: 03
start_other_cores() retuPPPrOOOnSSSeTTTd:::
P000OxxxST3:330 00
0
x3 7cc
cosootrrraeeexxxr:::t ed-- --a---p--{{a{ p iAAAPPPcIIIiCCdCI:IID DD
=== 000231 NNNOOODDDEEEIIIDDD === 00 CCCOOORRREEEIIIDDD ===
000312}}} -
[...]
So I changed it because I like it better like this:
[...]
[...]
which is ugly, slow, etc. but I can pipe it to a little script which turns it
back into
almost the original (boooh!!! :( )
or writes it a little nicer ( :) )
[...]
core0:init node: 00 cores: 03
core0:Start other core - nodeid: 00 cores: 03
core0:start_other_cores() returned
core1:POST:
core2:POST:
core3:POST:
core0:POST:
core1: 0x30
core2: 0x30
core3: 0x30
core0:0
core0:x37
core2: c
core3: c
core0:started ap apicid:
core1:corex: --- { APICID = 01 NODEID = 00 COREID = 01} ---
core2:orex: --- { APICID = 02 NODEID = 00 COREID = 02} ---
core3:orex: --- { APICID = 03 NODEID = 00 COREID = 03} ---
[...]
or even ( :) )
[...]
init node: 00 cores: 03|||
|||
Start other core - nodei|||
d: 00 cores: 03|||
start_other_cores() retu|P |P |P
rned|OST:|OST:|OST:
POST: | 0x30 | 0x30 |
0x30
0 |||
|||
x37 || c | c
started ap apicid: |corex: --- { APICID = 0|orex: --- { APICID =
02|orex: --- { APICID = 03
|1 NODEID = 00 COREID = 0| NODEID = 00 COREID = 0 |
NODEID = 00 COREID = 03
|1} --- |2} --- |}
---
|||
[...]
or other options to if you fancy.
I observed characters from each core got mixed but bits from each
character not, so the superIO or someone probably did alreday
synchronize bytes correctly. So I could split each byte in two, add a
4 bit buffer id and pretend each core has a different serial port and
I'm multiplexing up to 16 channels for up to 16 cores into one
physical serial port, by sending together the channel/buffer id with
the character (4 bits buffer id, 4 bits half character). Then a small
perl script demultiplexes each channel into a different buffer and
formats output. If someone has more than 16 cores does she really
want to see ouput from all at a time? Redefining the weak function
calc_id_buffer you can choose to have some of them mix into the same
buffer or just filter out the output for some of them.
Hope the patch is simple enough, else I can explain more later.
I must leave now.
diff -u -r coreboot-nomux/src/console/Kconfig coreboot/src/console/Kconfig
--- coreboot-nomux/src/console/Kconfig 2011-01-16 15:35:29.0 +0100
+++ coreboot/src/console/Kconfig2011-01-29 01:24:21.0 +0100
@@ -335,5 +335,18 @@
usually displayed using a so-called POST card ISA/PCI/PCI-E
device) on the serial console.
+config DEBUG_MUXED
+ bool Multiplex debug output from each core
+ default n
+ help
+ Transmit core number with each nibble of coreboot debug output,
+ causing the debug output to be unintelligible at naked eye but
+ filtrable piping it to demux_debug to separate output from each
+ core instead of watching the garbage produced by simultaneous
+ transmission from each core. It will duplicate
Re: [coreboot] enabling expert mode - build fails (warnings treated as errors) on fam10 boards
On Wed, Jan 12, 2011 at 11:57:39PM +0100, Stefan Reinauer wrote: Looks like a piece of Kconfig patch went missing? I don't know but I think I already saw this last august. I didn't care because I didn't know what I wanted expert mode for, so I just disabled it. I was never sure whether it might be some local modification. I guess it wasn't. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] To bin or not to bin. was: Allow components to add files to CBFS
Warning: long, personal, philosophical, not even very original or insightful. Read at your leisure or not at all. On Thu, Dec 16, 2010 at 05:14:29AM +0100, Stefan Reinauer wrote: While that last conclusion might sound logical, loading something at runtime rather than onto a masked rom or FPGA or ASIC does not necessarily mean it can be changed or makes sense to be changed. I only partially understand you. What it makes sense to change or not should not be a reason to stop people from changing it. What makes sense or not is not related to freedom, and what makes sense to someone may not make sense to someone else. What can or cannot be changed is a different story. Things that cannot be modified do not need to carry freedom to modify them. It's like the declaration of human rights: it would make sense to include the right of all humans to flap their wings and fly to the moon if only we could, the reason it's not there is that it's not possible, not that it would be wrong to have that right. You don't need the freedom to do something impossible but you need the freedom to do something that does not make sense (to whom?) unless there is an ethical reason to restrict that freedom. Yes, we are already including microcode, and I think it would make sense to separate it more obviously (also, putting it in some CBFS file instead of linking it into RAM stage) I'm not sure I understand how microcode is produced. I faintly remember some blackboard exercises at college with some toy CPUs and instruction sets where we wrote microcode by hand. There I guess microcode was source if there was any source at all. In reality microcode is possibly compiled from some source with some tool which also gives some circuit designs. Both circuits and microcode is just logic, with the difference that the microcode can be changed and the circuit can't. The microcode can be modified without changing the circuit (I guess), at least to disable some nasty feature. The question for me is whether there is a source for the microcode that can be modified without altering the circuits in order to get some change in behaviour, performance, etc. If the only source there is can't do that (because if modified it would give different microcode but also different circuits, so back to factory), then it's likely not necessary to have that source. Now the question is what about some other conceivable source which could be used with some other tool to modify the microcode and still run it on the same circuit? That would be desirable, but possibly unrelated to the microcode at question. So the microcode would be acceptable or not depending on how it was produced, which I don't know. The fact that the vendor provides updates to the microcode that don't require to change the hardware suggests there may exist some source like we would need, but it does not prove it. If you ever know there was a source and you don't have it then you'll know you're not in compliance with GPL if you link the microcode with someone else's GPL code in a derived work. If you have an option of avoiding that, it's nice to take it. Putting the microcode in external files would possibly be cleaner legally, although it would not help much philosophically. I agree help about that may not belong in coreboot but other free projects. And that drove me to coreboot. This is why the project would lose all interest for me if this market trend would be accepted as an excuse for including sourceless stuff. But I guess that the project wouldn't lose much from my loss of interest in it. Actually the direction is to move stuff that was previously done in an ASIC to some kind of firmware. The situation didn't really become more closed than it was before, just hardware became more complex. Not necessarily more complex, but more general. If there are two designs for the same functionality, design A with an ASIC and design B with firmware, then the hardware (unchangeable part) is more general with design B, because it can at least do as much as A and potentially more by changing the firmware (which is not hardware). If you think of the hardware has the circuits + firmware, then it may be getting more complex, but I think the hardware may be getting even simpler (at least the logic in it, I'm not talking quantum physics or electronics here), there's just more of it, and so the increased complexity is more manageable in firmware. For those who have the firmware's source, that is. In fact firmware is increasingly doing more nasty or undesirable stuff, like remote controlled PCs and the like, so this very trend is a reason to watch out for propietary firmware, not to accept it. And I believe the reason for the trend is simply that OSes (specially propietary OSes) are incresingly unreliable, so vendors tend to shift stuff to firmware (which does not help, it just delays the problem, propietary firmware will evolve like propietary software, opacity scales
[coreboot] To bin or not to bin. was: Allow components to add files to CBFS
On Wed, Dec 15, 2010 at 10:07:50PM +0100, Patrick Georgi wrote: Am Mittwoch, 15. Dezember 2010, um 20:17:18 schrieb Xavi Drudis Ferran: If the later I don't like the idea and at least I would like a huge warning BLOBS IN HERE !!! at the end of the make output. I avoid the term blob for two reasons: I don't quite dislike blob, but any meaningful alternative would do for the warning. I'm not sure the name of the file alone would do, some sort of taint flag, or license info would be ideal. In fact the best I can dream of is the name of each file, the license and the availability of source (linux has parts nominally under GPL without source code). But of course source code would need a definition. I seem to intuitionally feel I know it (the GPL definition), but then I find cases of people disagreeing, and they may not all be in bad faith. I prefer the OpenBSD definition of blob: binary components that run on the CPU. That a clear line drawn in the sand, and a useful distinction, too. Unfortunately GNU/blob spoiled that. I don't care where it runs. For me it's more whether it's been derived from some other form and what's more useful to touch if you want to change it. There's also the question of whether it can be replaced, but if it couldn't it wouldn't be included, of course. rant Applying the current FSF use of the word, a graphic rendered to png or jpeg without the source material (vector graphic, gimp image with multiple layers, ...) shipped with it is a blob. We're lucky that we never added a default bootsplash image to the tree! I don't get your rant. Whether there is source or not does not depend always on the format. If your bootsplash was made with gimp it would be better to include the source (it would be easier to combine with the logo of the hardware owner company, for instance, or adapt to other resolutions...), if it was made with a camera, maybe it's not so necessary to include the raw image and settings. I had to debate with GNU developers if the S-Boxes in AES are blobs, and if there's a preferred format for them (ie. if they could be calculated). They can't be calculated (there are a couple of formulas to verify if an S-Box is valid, but many are), but if you pick the wrong valid one, you get a different (and probably less safe) algorithm. The FSF meaning of the term only scares the same people who use it that way. /rant I think the discussion may have been less interesting to you than to them because you knew the algorithm better, but I think it was a relevant question. For me it would give insight on where the security comes from if I had time to learn AES. Must be similar to DES. I've never understood what makes those permutations secure or others less secure. That there aren't any binary components in the tree is simply for the fact that they're not redistributable: We usually scrap them from vendor BIOSes, and they're not separately available. That won't change. I hope it does not change even if one day vendors start giving permission to distribute sourceless binaries, as happens in linux or elsewhere. In fact there's already CPU microcode, but I'm not sure what would be source for that, so it may be ok. (It would spark quite a debate when storing binaries in the tree would actually be proposed, but we never even got that far for the stated reason) Ok. I'm happy to avoid that debate until the choice comes. For me it's enough now to know there won't be binaries in the tree so users will have to opt in. I tried to change the subject header because it's no longer about the patch. The other fact: Hardware relies more and more on update-able components in flash, without any knowledge of what this is. And that drove me to coreboot. This is why the project would lose all interest for me if this market trend would be accepted as an excuse for including sourceless stuff. But I guess that the project wouldn't lose much from my loss of interest in it. Maybe it's 8051 code, maybe it's VHDL stuff of some sorts, maybe a table like the S-Boxes, or a JPEG image. There is no preferred format, there's usually no disassembler for the data, or documentation that can be read outside the high security area at the vendor (and very likely only in 5pt print, orange glyphs on red paper in the area, to prevent anyone from making copies), but there's a single invariant for most of them: Without the data around, your system won't boot - it's useless as a brick, with the only feature that it sucks power. I'm not arguing the usefulness of hardware without binary stuff in those cases, I'm just arguing the usefulness of free firmware lacking source for components that do have source but it is not public. If you prefer to live without the file, simply don't put it in there. Your board might be less useful than a brick, but that's your choice. That brick would at least be useful to develop free replacements for the missing
Re: [coreboot] [PATCH]Move SET_FIDVID* to Kconfig
On Sun, Nov 07, 2010 at 08:37:00AM +0100, Patrick Georgi wrote: Am 07.11.2010 02:28, schrieb xdrudis: It is an option right now (just in romstage.c) - maybe we should drop some of these options on Fam10 completely (and their uses as well), but for now all I want to do is move them to Kconfig. Sure. I didn't mean if had to be the same patch. Thank you for looking into it, it's highly appreciated! Thank you for your work (and to the others too). -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot on dell mini 9
On Sun, Nov 07, 2010 at 06:16:28PM +0100, HacKurx wrote: Please can someone help me know if I can install coreboot on my Laptop? I haven't looked at the components, but I hear that in general laptops are very difficult. I guess it has improved with usb console but still, assuming that the chips in your laptop were supported, will it be possible for you to replace or reflash the flash chip with the firmware in case the first attempt fails and it doesn't boot ? It's easier in a desktop PC than a laptop. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Questions about more AMD related flags
On Fri, Nov 05, 2010 at 08:11:28PM +0100, Patrick Georgi wrote: SET_FIDVID*: These have _very_ weird behaviour, being set to some defaults in the two init_cpus.c (and fidvid.c seems to expect to be included after that one?), and some other settings somewhere else. I tried to untangle that while moving to Kconfig, but didn't quite succeed, so is here anyone who knows which defaults (or dependencies) are correct for each of the following? So far I have: I've been playing with fidvid.c a little for my single FAM10 cpu (4 cores) slowly at my scarce free time. I'm quite ignorant and the only result I got has been a consistent hang in prep_fid_vid after warm reset with my changes, and without them it sometimes hanged around there and often later. So don't quite believe me but For Fam10h: +config SET_FIDVID + bool + default y + This enables or disables all cpu and northbridge frecuency and voltage settings required by BKDG . In order to comply with BKDG it should be on for all FAM10. I believe it is set to 1 in all FAM10 boards ? +config SET_FIDVID_CORE0_ONLY + bool + default n + depends on SET_FIDVID + I remember I didn't realise for a while that SET_FIDVID_CORE0_ONLY was off but it was, so I agree it was weird to me, but I thought it was just me. There are things in the BKDG that need to be done for each core, not just core0, so I decided it was rightly off. I'd say FAM10 needs SET_FIDVID_CORE0_ONLY to off irrespective of board. For example, fixPsNbVidBeforeWR() in src/cpu/amd/model_10xxx/fidvid.c implements steps 1-6 of BKDG 2.4.2.9.1 in case of needing nb vid update. The BKDG #31116 rev 3.48 April 2010 says the pstate MSRs need writes for all cores. The BSP core 0 will always do it, because mainboard/.../romstage.c calls init_fidvid_bsp(). But the other cores wouldn't do it if SET_FIDVID_CORE0_ONLY was on (init_cpus() would call init_fidvid_ap for core0 of nodes other than BSP but not for cores 1,2,3,... of any node) Is this what you were asking ? +config SET_FIDVID_CORE_RANGE + bool + default n + depends on SET_FIDVID + bool ? I Only saw it used in init_fidvid_bsp as the second parameter to for_each_ap, and it does: if 1 iterates over core0 in nodes 0 if 2 iterates over cores 1 .. max (skips core0 of each node) else iterates over all cores in all nodes (except bsp core 0) this iterations wait for the cores to give their results and then calculates the common fid (frequency Id for the northbridge, wich must be the minimum i.e. slowest required for all processors). I guess one can check for each core or for one core in each processor (node). BKDG says F3xD4[NbFid] must be matched between all processors in the coherent fabric of a multi-socket sys- tem. The lowest setting from all processors in a multi-socket system (determined by using the following equa- tions on each processor and selecting the lowest value) is used as the common NbFid. So I would suppose you don't really need to check all cores in a processor. If they share the northbridge how could they require different frequencies for it ?. But this is only with respect to the frecuency. Maybe you want to wait for all simply to make sure you already set the NBVid before you set the NbFid? I believe for tilapia_fam10 you already have waited at wait_all_other_cores_started before calling init_fidvid_bsp, so you could have SET_FIDVID_CORE_RANGE to 1 and save a little. I think it's always 0, though. +config SET_FIDVID_DEBUG + bool + default y + depends on SET_FIDVID + For me it's ok at 1 . For FAM10 at least it is only use to enable traces for fidvid code (frequency and voltage setting). +config SET_FIDVID_STORE_AP_APICID_AT_FIRST + bool + default y + depends on SET_FIDVID model_10xx/fidvid.c // if we are tight of CAR stack, disable it #define SET_FIDVID_STORE_AP_APICID_AT_FIRST 1 I don't fully understand the advantage of enabling it. Apparently it only enables a table of core apicids that is first built and then read to wait for each core to tell you its nbfid. Why can't you directly iterate once and wait and calculate the nbfid (which is what would happen if this was 0) ?. The other difference is that setting it to 0 would make it not use SET_FIDVID_CORE_RANGE, and iterate always for all cores that have calculated fid, (in fact iterate for all cores if SET_FIDVID_CORE0_ONLY is 0 as it should, or only cores 0 if SET_FIDVID_CORE0_ONLY is 1 against BKDG). I don't know about fam f, it uses a different fidvid.c . -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Buying a new mainboard. Which vendors support coreboot?
On Sat, Nov 06, 2010 at 11:52:27PM +0200, Niklas Cholmkvist wrote: Hi, I would like a mainboard from a vendor that supports coreboot, but also has an Intel GMA(3D acceleration) on the same mainboard.(Intel GMA because of my percieved 'good 3D FLOSS drivers'...though irrelevant to coreboot) I've read that AMD is very supportive of coreboot. Do you think it's possible that there is an AMD mainboard with an Intel GMA(3D acceleration) on it? I don't think so. I think the bus between the CPU and northbridge is different, and it can't be easily done. And if it could be done I don't see Intel willing. It's the same reason there aren't intel addon graphic cards. But if you find one please tell me. I ended up with and AMD cpu + nvidia vga in order to at least have nouveau, but I hate buying from nvidia. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Questions about more AMD related flags
On Sat, Nov 06, 2010 at 03:32:30PM +0100, xdrudis wrote: So I would suppose you don't really need to check all cores in a processor. If they share the northbridge how could they require different frequencies for it ?. But this is only with respect to the frecuency. Maybe you want to wait for all simply to make sure you already set the NBVid before you set the NbFid? I believe for tilapia_fam10 you already have waited at wait_all_other_cores_started before calling init_fidvid_bsp, so you could have SET_FIDVID_CORE_RANGE to 1 and save a little. Sorry, I was mistaken. wait_all_other_cores_started does not mean wait for all cores that have started (until they're done) but wait for all cores to start. I mean that wait_all_other_cores_started waits until cores have written F10_APSTATE_STARTED to the lapic and init_fidvid_bsp waits until they have written F10_APSTATE_RESET, just after seting nbvid an changing to pstate 1 and then core0 to pstate 0 I'm not 100% that BKDG 2.4.2.9.1 requires synchronization after each step, which we don't do, but if it is required between steps 6 and 8 then SET_FIDVID_CORE_RANGE can't be set to 1 because we wouldn't be waiting for all cores to change to p1. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Move SET_FIDVID* to Kconfig
On Sat, Nov 06, 2010 at 01:56:45PM +0100, Patrick Georgi wrote: Hi, I moved the SET_FIDVID family of configuration options to Kconfig, adapting its use (CONFIG_ prefix), and tried to minimize the board specific settings. They get some defaults in src/cpu/amd/model_*xx/Kconfig, which are derived from the various #ifndef ... #define ... #endif blocks I removed in the cpu specific code. All #define SET_FIDVID 0 in romstage.c files weren't necessary due to these defaults, as well as all #define SET_FIDVID 1 in Fam10 boards, so these were stripped. Some select SET_FIDVID could probably still be removed. So far so good. I'm not sure FIDVID can be an option for fam10 . BKDG require it but I don't know if any fam10 cpu can boot without it. SET_FIDVID_CORE0_ONLY was always 1, so again, I moved this to the CPU. It isn't always 1. It's 0 for FAM10. But the patch is right as far as I can see asleep as I am. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [commit] r5976 - trunk/src/cpu/amd/car
On Wed, Oct 20, 2010 at 02:20:12PM -0500, Scott Duplichan wrote: But gas has no base 2 log function and could not figure out how to write a macro that returns a constant. Sorry, ignore my previous post . I misread and answered without thinking. It was about gas, not about log2. I'm surprised that a macro can't return a constant. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] DUAL_VDD_BIT in cpu/amd/model_10xxx/fidvid.c
Hello. I'm looking at the fidvid code while trying to make it work for more revisions and so on, and I don't understand its logic. at src/cpu/amd/model_10xxx/fidvid.c line 260 (in prep_fid_change()) it tests F3xA0[31] to tell whether it's in a dual power plane configuration. But according to BKDG : CofVidProg: COF and VID of P-states programmed. Read-only. 1=Out of cold reset, the VID and FID values of the P-state register specified by MSRC001_0071[StartupPstate] have been applied to the processor.0=Out of cold reset, the boot VID is applied to all processor power planes, the NB clock plane is set to 800 MHz (with a FID of 00h=800 MHz and a DID of 0b) and core CPU clock planes are set to 800 MHz (with a FID of 00h=1.6 GHz and a DID of 1h). This affects F3xD4[NbFidEn]. Registers containing P-state information such as FID, DID, and VID values are valid out of cold reset independent of the state of F3xA0[CofVidProg]. BIOS must transition the processor to a valid P-state out of cold reset when F3xA0[CofVidProg]=0. See 2.4.2.6 [BIOS Requirements for P-State Initializa- tion and Transitions]. Does the fact that the CPU has booted into a P-state VID or a boot VID warrant that the system is dual plane or single plane ? The name of the constant does not match any field I've found in the docs, and just 15 lines before it's setting all writeable bits in F3xA0 to 1s in a strange way (for PVI) which make me suspect this part of the code. There's a somewhat related bit in F3x1FC[31]. DualPlaneOnly. Revision B: Reserved. Revision C: Read-only. Reset: value varies by product. Spec- ifies the infrastructure that supports the processor. 0=The processor is supported by both the single- and dual-plane infrastructures. 1=The processor is only supported by the dual-plane infrastructure. See 2.4.2.7 [BIOS Configuration for Dual-plane Only Support]. Which I would understand as saying that if I find an 1 there I know I'm in double plane, and if I find an 0 I don't know anything. So, the question is: a) should I use F3xA0[31] to tell I'm in single or double plane or b) should I have a mainboard defined constant, and maybe check its value against F3x1FC[31] and give a warning if constant says single plane and F3x1FC[31]=1 , or c) is there some input to the processor I can read to tell if I'm in single or double plane without putting the info in the code ? I'm assuming b, but what do you think ? Thank you -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] hardcoded bdf numbers in sb700_early_init.c get serial output on ASUS M4A77TD-PRO
Hello. I rewrote my earlier patch to romcc_io.h (where I banned some
device ranges from pci_locate_device) because it was too
aggressive. With this patch to sb700_early_setup.c I achieve the same
on my board (serial output, and it hangs in the same place), but
hopefully with less breakage for other boards. I first tried to hardcode
PCI bus, device and function in sb700_lpc_init() only but it did hang
elsewhere, so I finally thought it more coherent to hardcode all
devices in the file than just some functions, and it works for me. I
still have the doubt of why was there a pci_locate_device in the first
place, since from my more than limited knowledge it does not look like
the devices in sb700 may appear in other bus,device,function
addresses. But the original even had an error message at one place for
when the device was not found.
Please review and/or test and commit if you think appropiate (I guess
it's not urgent, since my board still does not boot).
This patch applies to svn 5739
Signed-off-by: Xavi Drudis Ferran xdru...@tinet.cat
---
Thank you for commiting my previous patches.
Now I plan to have a look at fidvid.c and AMD's Bios and Kernel
Developer Guide. I'm not sure I'll be able to fix much, and it may
take me a while. I guess it's better not to send patches or anything
until I get something that works for me.Index: src/southbridge/amd/sb700/sb700_early_setup.c
===
--- src/southbridge/amd/sb700/sb700_early_setup.c (revision 5721)
+++ src/southbridge/amd/sb700/sb700_early_setup.c (working copy)
@@ -49,9 +49,9 @@
/* if (rev != 0) return rev; */
- dev = pci_locate_device(PCI_ID(0x1002, 0x4385), 0);
+ dev = PCI_DEV(0,0x14,0);
- if (dev == PCI_DEV_INVALID) {
+ if ( pci_read_config32(dev, 0) != PCI_ID(0x1002, 0x4385)) {
die(SMBUS controller not found\n);
/* NOT REACHED */
}
@@ -103,7 +103,8 @@
u32 reg32;
device_t dev;
- dev = pci_locate_device(PCI_ID(0x1002, 0x4385), 0); /* SMBUS
controller */
+ /* PCI_ID(0x1002, 0x4385) SMBUS controller */
+ dev = PCI_DEV(0,20,0);
/* NOTE: Set BootTimerDisable, otherwise it would keep rebooting!!
* This bit has no meaning if debug strap is not enabled. So if the
* board keeps rebooting and the code fails to reach here, we could
@@ -117,7 +118,8 @@
reg32 |= 1 20;
pci_write_config32(dev, 0x64, reg32);
- dev = pci_locate_device(PCI_ID(0x1002, 0x439d), 0); /* LPC
Controller */
+ /* PCI_ID(0x1002, 0x439d) LPC Controller */
+ dev = PCI_DEV(0,20,3);
/* Decode port 0x3f8-0x3ff (Serial 0) */
// XXX Serial port decode on LPC is hardcoded to 0x3f8
reg8 = pci_read_config8(dev, 0x44);
@@ -155,11 +157,7 @@
/* what is its usage? */
static u32 get_sbdn(u32 bus)
{
- device_t dev;
-
- /* Find the device. */
- dev = pci_locate_device_on_bus(PCI_ID(0x1002, 0x4385), bus);
- return (dev 15) 0x1f;
+ return 20; //sb700 SMBUS/ACPI PCI device number
}
static u8 dual_core(void)
@@ -236,8 +234,8 @@
u8 byte;
device_t dev;
- /* P2P Bridge */
- dev = pci_locate_device(PCI_ID(0x1002, 0x4384), 0);
+ /* P2P Bridge PCI_ID(0x1002, 0x4384) */
+ dev = PCI_DEV(0,20,4);
/* Chip Control: Enable subtractive decoding */
byte = pci_read_config8(dev, 0x40);
@@ -268,8 +266,8 @@
byte |= 1 0;
pci_write_config8(dev, 0x04, byte);
- /* LPC controller */
- dev = pci_locate_device(PCI_ID(0x1002, 0x439D), 0);
+ /* LPC controller PCI_ID(0x1002, 0x439D) */
+ dev = PCI_DEV(0,20,3);
byte = pci_read_config8(dev, 0x4A);
byte = ~(1 5); /* disable lpc port 80 */
@@ -282,14 +280,15 @@
device_t dev;
u32 reg32;
- /* Enable LPC controller */
- dev = pci_locate_device(PCI_ID(0x1002, 0x4385), 0);
+ /* Enable LPC controller PCI_ID(0x1002, 0x4385) */
+ dev = PCI_DEV(0,20,0);
reg32 = pci_read_config32(dev, 0x64);
reg32 |= 0x0010;/* lpcEnable */
pci_write_config32(dev, 0x64, reg32);
/* Enable port 80 LPC decode in pci function 3 configuration space. */
- dev = pci_locate_device(PCI_ID(0x1002, 0x439d), 0);
+ // PCI_ID(0x1002, 0x439d)
+ dev = PCI_DEV(0,20,3);
byte = pci_read_config8(dev, 0x4a);
byte |= 1 5; /* enable port 80 */
pci_write_config8(dev, 0x4a, byte);
@@ -304,7 +303,8 @@
printk(BIOS_INFO, sb700_devices_por_init()\n);
/* SMBus Device, BDF:0-20-0 */
printk(BIOS_INFO, sb700_devices_por_init(): SMBus Device,
BDF:0-20-0\n);
- dev = pci_locate_device(PCI_ID(0x1002, 0x4385), 0);
+ //PCI_ID(0x1002, 0x4385)
+ dev = PCI_DEV(0,20,0);
if (dev == PCI_DEV_INVALID) {
die(SMBUS controller not
Re: [coreboot] [PATCH] ht init and some errata for AMD fam 10 RB_C3
On Tue, Aug 17, 2010 at 08:44:10AM +0200, xdrudis wrote:
I know I should split it to smaller pieces, I just haven't had
the time yet, and there's some overlap, so I must take care...
Signed off by: Xavi Drudis Ferran xdru...@tinet.cat
I splitted the original patch in 8 patches, and I'm now sending them
one in each message.
They all apply to the 5722 svn revisionwith the patch.serial1
patch attached (at least I tested thus, the patches should apply
regardless).
There're some dependences between them.
The order I have tried them is the one I'll send them to the list:
patch.rbc3infam10all
patch.err351clearForceFullT0
patch.rbc3inErr346
patch.completeErr343
patch.erratum372
patch.erratum414
patch.rbc3inErr344
patch.rbc3inErr354
Signed off by: Xavi Drudis Ferran xdru...@tinet.cat
Add RB_C3 to AMD_FAM10_ALL so that it gets its MSR right for mtrs, ht, etc.
While reviewing impact of this change it seems code for erratum 531 was not in
sync with current docs. I have checked uses of AMD_FAM10_ALL, but I
haven't looked up the docs for all of them, at first sight it seems ok
to include all FAM10 revisions in this mask.
Apply errata 531 only to revisions listed in Revision Guide for AMD Family10h
processors (#41322) rev 3.74 June 2010. Before it was applied also to
DR-B0, DA-C3 or HY-D0 which are not affected according to current docs.
Index: src/cpu/amd/model_10xxx/defaults.h
===
--- src/cpu/amd/model_10xxx/defaults.h (revision 5721)
+++ src/cpu/amd/model_10xxx/defaults.h (working copy)
@@ -136,27 +136,27 @@
* program Link Global Extended Control Register[ForceFullT0]
* (F0x16C[15:13]) to 000b */
- { 0, 0x170, AMD_FAM10_ALL, AMD_PTYPE_ALL, /* Fix FAM10_ALL when fixed
in rev guide */
+ { 0, 0x170, AMD_DRBA23_RBC2, AMD_PTYPE_ALL, /* FIXME Should include
BL_C2 but there is no constant */
0x, 0x0100 },
- { 0, 0x174, AMD_FAM10_ALL, AMD_PTYPE_ALL,
+ { 0, 0x174, AMD_DRBA23_RBC2, AMD_PTYPE_ALL,
0x, 0x0100 },
- { 0, 0x178, AMD_FAM10_ALL, AMD_PTYPE_ALL,
+ { 0, 0x178, AMD_DRBA23_RBC2, AMD_PTYPE_ALL,
0x, 0x0100 },
- { 0, 0x17C, AMD_FAM10_ALL, AMD_PTYPE_ALL,
+ { 0, 0x17C, AMD_DRBA23_RBC2, AMD_PTYPE_ALL,
0x, 0x0100 },
- { 0, 0x180, AMD_FAM10_ALL, AMD_PTYPE_ALL,
+ { 0, 0x180, AMD_DRBA23_RBC2, AMD_PTYPE_ALL,
0x, 0x0100 },
- { 0, 0x184, AMD_FAM10_ALL, AMD_PTYPE_ALL,
+ { 0, 0x184, AMD_DRBA23_RBC2, AMD_PTYPE_ALL,
0x, 0x0100 },
- { 0, 0x188, AMD_FAM10_ALL, AMD_PTYPE_ALL,
+ { 0, 0x188, AMD_DRBA23_RBC2, AMD_PTYPE_ALL,
0x, 0x0100 },
- { 0, 0x18C, AMD_FAM10_ALL, AMD_PTYPE_ALL,
+ { 0, 0x18C, AMD_DRBA23_RBC2, AMD_PTYPE_ALL,
0x, 0x0100 },
- { 0, 0x170, AMD_FAM10_ALL, AMD_PTYPE_ALL,
+ { 0, 0x170, AMD_DRBA23_RBC2, AMD_PTYPE_ALL,
0x, 0x0100 },
/* Link Global Extended Control Register */
- { 0, 0x16C, AMD_FAM10_ALL, AMD_PTYPE_ALL,
+ { 0, 0x16C, AMD_DRBA23_RBC2, AMD_PTYPE_ALL,
0x0014, 0x003F }, /* [15:13] ForceFullT0 = 0b,
* Set T0Time
14h per BKDG */
Index: src/northbridge/amd/amdmct/amddefs.h
===
--- src/northbridge/amd/amdmct/amddefs.h(revision 5721)
+++ src/northbridge/amd/amdmct/amddefs.h(working copy)
@@ -62,10 +62,11 @@
#defineAMD_DR_LT_B3(AMD_DR_B0 | AMD_DR_B1 | AMD_DR_B2 | AMD_DR_BA)
#defineAMD_DR_GT_B0(AMD_DR_ALL ~(AMD_DR_B0))
#defineAMD_DR_ALL (AMD_DR_Bx)
-#defineAMD_FAM10_ALL (AMD_DR_ALL | AMD_RB_C2 | AMD_HY_D0 | AMD_DA_C3
| AMD_DA_C2)
+#defineAMD_FAM10_ALL (AMD_DR_ALL | AMD_RB_C2 | AMD_HY_D0 | AMD_DA_C3
| AMD_DA_C2 | AMD_RB_C3 )
#defineAMD_FAM10_GT_B0 (AMD_FAM10_ALL ~(AMD_DR_B0))
#defineAMD_DR_Cx (AMD_RB_C2 | AMD_DA_C2 | AMD_RB_C3 | AMD_DA_C3)
#defineAMD_DR_Dx (AMD_HY_D0)
+#define AMD_DRBA23_RBC2 (AMD_DR_BA | AMD_DR_B2 | AMD_DR_B3 | AMD_RB_C2 )
/*
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] ht init and some errata for AMD fam 10 RB_C3
My smallest patch ever
I've checked Revision Guide for AMD Family10h processors (#41322) rev
3.74 June 2010 for errata 351 and it agrees with the comment on
setting ForceFullT0= 000b but I believe the code didn't honor the
comment.
apply this after patch.rbc3infam10all
Index: src/cpu/amd/model_10xxx/defaults.h
===
--- src/cpu/amd/model_10xxx/defaults.h (revision 5719)
+++ src/cpu/amd/model_10xxx/defaults.h (working copy)
@@ -157,7 +157,7 @@
/* Link Global Extended Control Register */
{ 0, 0x16C, AMD_DRBA23_RBC2, AMD_PTYPE_ALL,
- 0x0014, 0x003F }, /* [15:13] ForceFullT0 = 0b,
+ 0x0014, 0xE03F }, /* [15:13] ForceFullT0 = 0b,
* Set T0Time
14h per BKDG */
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] include RB_C3 in erratum 346
Signed off by: Xavi Drudis Ferran xdru...@tinet.cat
diff -r -u src/cpu/amd/model_10xxx/defaults.h
../coreboot-p/src/cpu/amd/model_10xxx/defaults.h
--- src/cpu/amd/model_10xxx/defaults.h 2010-08-19 08:06:11.0 +0200
+++ ../coreboot-p/src/cpu/amd/model_10xxx/defaults.h2010-08-19
08:09:06.0 +0200
@@ -290,9 +290,9 @@
[5] DisPciCfgCpuMstAbtRsp = 1,
[1] SyncFloodOnUsPwDataErr = 1 */
- /* errata 346 - Fam10 C2
+ /* errata 346 - Fam10 C2 -- FIXME at 25.6.2010 should apply to BL-C[23]
too but I can't find their constants
* System software should set F3x188[22] to 1b. */
- { 3, 0x188, AMD_RB_C2 | AMD_DA_C2 | AMD_DA_C3, AMD_PTYPE_ALL,
+ { 3, 0x188, AMD_DR_Cx, AMD_PTYPE_ALL,
0x0040, 0x0040 },
/* L3 Control Register */
diff -r -u src/northbridge/amd/amdmct/amddefs.h
../coreboot-p/src/northbridge/amd/amdmct/amddefs.h
--- src/northbridge/amd/amdmct/amddefs.h2010-08-19 08:06:11.0
+0200
+++ ../coreboot-p/src/northbridge/amd/amdmct/amddefs.h 2010-08-19
08:09:06.0 +0200
@@ -66,6 +66,7 @@
#defineAMD_FAM10_GT_B0 (AMD_FAM10_ALL ~(AMD_DR_B0))
#defineAMD_DR_Cx (AMD_RB_C2 | AMD_DA_C2 | AMD_RB_C3 | AMD_DA_C3)
#defineAMD_DR_Dx (AMD_HY_D0)
+#defineAMD_DRBH_Cx (AMD_DR_Cx | AMD_HY_D0 )
#define AMD_DRBA23_RBC2 (AMD_DR_BA | AMD_DR_B2 | AMD_DR_B3 | AMD_RB_C2 )
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] Complete AMD erratum 343 workaround
Up to this patch, tests did the same as without the patches,
hang after setAMDMSR , but still I think they are useful,
since they get closer to documentation and don't make things worse.
Signed off by: Xavi Drudis Ferran xdru...@tinet.cat
Complete code for errata 343. Revision Guide for AMD Family10h
processors (#41322) rev 3.74 June 2010 says to set the register
to 1 before CAR and to 0 after. We were setting it to 0 after CAR,
but not to 1 before.
apply after patch.rbc3inErr346
Index: src/cpu/amd/model_10xxx/defaults.h
===
--- src/cpu/amd/model_10xxx/defaults.h (revision 5692)
+++ src/cpu/amd/model_10xxx/defaults.h (working copy)
@@ -88,6 +88,10 @@
{ CPUIDFEATURES, AMD_FAM10_ALL, AMD_PTYPE_DC,
0x, 1 (33-32),
0x, 1 (33-32) }, /* [ExtendedFeatEn]=1 */
+
+{ BU_CFG2, AMD_DRBH_Cx , AMD_PTYPE_ALL,
+ 0x, 1 (35-32),
+ 0x, 1 (35-32) }, /* Erratum 343 (set to 0 after CAR, in
post_cache_as_ram() ) */
};
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] include workaround for AMD erratum 372
with this one it stops here or earlier (as soon as before the patch,
sometimes):
*** Yes, the copy/decompress is taking a while, FIXME!
v_esp=000cbf48
testx = 5a5a5a5a
Copying data from cache to RAM -- switching to use RAM as stack... Done
testx = 5a5a5a5a
Disabling cache as ram now
Clearing initial memory region:
Signed off by: Xavi Drudis Ferran xdru...@tinet.cat
documented workaround erratum 372, see
Revision Guide for AMD Family10h processors (#41322) rev 3.74 June 2010
apply after patch.rbc3inErr346
Index: src/northbridge/amd/amdmct/mct_ddr3/mct_d.h
===
--- src/northbridge/amd/amdmct/mct_ddr3/mct_d.h (revision 5692)
+++ src/northbridge/amd/amdmct/mct_ddr3/mct_d.h (working copy)
@@ -175,6 +177,7 @@
#define Ddr3FourSocketCh 2 /* func 2, offset A8h, bit 2 */
#define SendControlWord30 /* func 2, offset 7Ch, bit 30 */
+#define NB_GfxNbPstateDis 62 /* MSRC001_001F Northbridge
Configuration Register (NB_CFG) bit 62 GfxNbPstateDis disable northbridge
p-state transitions */
/*=
SW Initialization
*/
Index: src/northbridge/amd/amdmct/wrappers/mcti_d.c
===
--- src/northbridge/amd/amdmct/wrappers/mcti_d.c(revision 5692)
+++ src/northbridge/amd/amdmct/wrappers/mcti_d.c(working copy)
@@ -400,14 +400,31 @@
coreDelay();
}
+
+static void vErratum372(struct DCTStatStruc *pDCTstat)
+{
+msr_t msr = rdmsr(NB_CFG_MSR);
+
+int nbPstate1supported = ! (msr.hi (1 (NB_GfxNbPstateDis -32)))
;
+
+// is this the right way to check for NB pstate 1 or DDR3-1333 ?
+if (((pDCTstat-PresetmaxFreq==1333)||(nbPstate1supported))
+(!pDCTstat-GangedMode)) {
+ /* DisableCf8ExtCfg */
+ msr.hi = ~(3 (51 - 32));
+ wrmsr(NB_CFG_MSR, msr);
+}
+}
#endif
static void mctHookBeforeAnyTraining(struct MCTStatStruc *pMCTstat, struct
DCTStatStruc *pDCTstatA)
{
#if (CONFIG_DIMM_SUPPORT 0x000F)==0x0005 /* AMD_FAM10_DDR3 */
- if (pDCTstatA-LogicalCPUID (AMD_RB_C2 | AMD_DA_C2 | AMD_DA_C3)) {
+ /* FIXME : as of 25.6.2010 errata 350 and 372 should apply to
((RB|BL|DA)-C[23])|(HY-D[01])|(PH-E0) but I don't find constants for all of
them */
+ if (pDCTstatA-LogicalCPUID AMD_DRBH_Cx) {
vErrata350(pMCTstat, pDCTstatA);
+ vErratum372(pDCTstatA);
}
#endif
}
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] include workaround for AMD erratum 414
with patch.erratum414 it stops here (next patches don'tmake it get further,
but they're needed according to documentation, don't break anything for me and
I still don't have
a solution for booting, so I'm keeping them there in case they fix something.
testx = 5a5a5a5a
Copying data from cache to RAM -- switching to use RAM as stack... Done
testx = 5a5a5a5a
Disabling cache as ram now
Clearing initial memory region: Done
Loading stage image.
Check CBFS header at fd2e
magic is 4f524243
Found CBFS header at fd2e
Check fallback/romstage
CBFS: follow chain: fff0 + 38 + 15b41 + align - fff15b80
Check fallback/coreboot_ram
Stage: loading fallback/coreboot_ram @ 0x20 (1114112 bytes), entry @ 0x2
Signed off by: Xavi Drudis Ferran xdru...@tinet.cat
documented workaround erratum 414, see
Revision Guide for AMD Family10h processors (#41322) rev 3.74 June 2010
apply after patch.erratum372
diff -ru ../coreboot-p2/src/northbridge/amd/amdmct/mct_ddr3/mct_d.h
./src/northbridge/amd/amdmct/mct_ddr3/mct_d.h
--- ../coreboot-p2/src/northbridge/amd/amdmct/mct_ddr3/mct_d.h 2010-08-19
09:11:18.0 +0200
+++ ./src/northbridge/amd/amdmct/mct_ddr3/mct_d.h 2010-08-19
19:11:05.0 +0200
@@ -118,6 +118,7 @@
#define TestFail 2 /* func 2, offset 40h-5C, bit 2*/
#define DqsRcvEnTrain 18 /* func 2, offset 78h, bit 18*/
#define EnDramInit 31 /* func 2, offset 7Ch, bit 31*/
+#define PchgPDModeSel 23 /* func 2, offset 84h, bit 23 */
#define DisAutoRefresh 18 /* func 2, offset 8Ch, bit 18*/
#define InitDram 0 /* func 2, offset 90h, bit 0*/
#define BurstLength32 10 /* func 2, offset 90h, bit 10*/
@@ -128,6 +129,7 @@
#define MemClkFreqVal 3 /* func 2, offset 94h, bit 3*/
#define RDqsEn 12 /* func 2, offset 94h, bit 12*/
#define DisDramInterface 14 /* func 2, offset 94h, bit 14*/
+#define PowerDownEn15 /* func 2, offset 94h, bit 15*/
#define DctAccessWrite 30 /* func 2, offset 98h, bit 30*/
#define DctAccessDone 31 /* func 2, offset 98h, bit 31*/
#define MemClrStatus 0 /* func 2, offset A0h, bit 0*/
diff -ru ../coreboot-p2/src/northbridge/amd/amdmct/wrappers/mcti_d.c
./src/northbridge/amd/amdmct/wrappers/mcti_d.c
--- ../coreboot-p2/src/northbridge/amd/amdmct/wrappers/mcti_d.c 2010-08-19
09:11:18.0 +0200
+++ ./src/northbridge/amd/amdmct/wrappers/mcti_d.c 2010-08-19
19:11:49.0 +0200
@@ -415,6 +415,23 @@
wrmsr(NB_CFG_MSR, msr);
}
}
+
+static void vErratum414(struct DCTStatStruc *pDCTstat)
+{
+ int dct=0;
+for(; dct 2 ; dct++)
+{
+int dRAMConfigHi = Get_NB32(pDCTstat-dev_dct,0x94 + (0x100 * dct));
+int powerDown = dRAMConfigHi (1 PowerDownEn ) ;
+int ddr3 = dRAMConfigHi (1 Ddr3Mode ) ;
+int dRAMMRS = Get_NB32(pDCTstat-dev_dct,0x84 + (0x100 * dct));
+int pchgPDModeSel = dRAMMRS (1 PchgPDModeSel ) ;
+ if (powerDown ddr3 pchgPDModeSel )
+ {
+ Set_NB32(pDCTstat-dev_dct,0x84 + (0x100 * dct), dRAMMRS ~(1
PchgPDModeSel) );
+ }
+}
+}
#endif
@@ -425,6 +442,7 @@
if (pDCTstatA-LogicalCPUID AMD_DRBH_Cx) {
vErrata350(pMCTstat, pDCTstatA);
vErratum372(pDCTstatA);
+ vErratum414(pDCTstatA);
}
#endif
}
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] Include RB_C3 in workaround for errata 344
My processor wasn't getting the workaround
Signed off by: Xavi Drudis Ferran xdru...@tinet.catRB_C3 and HY-D0 should also apply the workaround for errata 344, according to
Revision Guide for AMD Family10h processors (#41322) rev 3.74 June 2010
apply after patch.rbc3inErr346
Index: src/cpu/amd/model_10xxx/defaults.h
===
--- src/cpu/amd/model_10xxx/defaults.h (revision 5692)
+++ src/cpu/amd/model_10xxx/defaults.h (working copy)
@@ -321,9 +321,9 @@
u32 mask;
} fam10_htphy_default[] = {
- /* Errata 344 - Fam10 C2/D0
+ /* Errata 344 - Fam10 C2/D0 -- FIXME at 25.6.2010 should be for
((RB|BL|DA)-C[23])|(HY-D[01])|(PH-E0) but I don't find constants for all of them
* System software should set bit 6 of F4x1[9C, 94, 8C, 84]_x[78:70,
68:60]. */
- { 0x60, AMD_RB_C2 | AMD_DA_C2 | AMD_DA_C3 | AMD_HY_D0, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
+ { 0x60, AMD_DRBH_Cx , AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
0x0040, 0x0040 },
{ 0x61, AMD_RB_C2 | AMD_DA_C2 | AMD_DA_C3 | AMD_HY_D0, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
0x0040, 0x0040 },
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] include RB-C3 in workaround for erratum 354
Last one,
Signed off by: Xavi Drudis Ferran xdru...@tinet.cat
RB_C3 should also apply the workaround for errata 354, according to
Revision Guide for AMD Family10h processors (#41322) rev 3.74 June 2010
Index: src/cpu/amd/model_10xxx/defaults.h
===
--- src/cpu/amd/model_10xxx/defaults.h (revision 5692)
+++ src/cpu/amd/model_10xxx/defaults.h (working copy)
@@ -361,44 +361,44 @@
{ 0x78, AMD_RB_C2 | AMD_DA_C2 | AMD_DA_C3 | AMD_HY_D0, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
0x0040, 0x0040 },
- /* Errata 354 - Fam10 C2
+ /* Errata 354 - Fam10 C2 - FIXME at 25.6.2010 affects RB-C2,
BL-C2,DA-C2,RB-C3,BL-C3,DA-C3, but BL-C[23] have no constants
* System software should set bit 6 of F4x1[9C,94,8C,84]_x[58:50,
48:40] for all links. */
- { 0x40, AMD_RB_C2 | AMD_DA_C2 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
+ { 0x40, AMD_RB_C2 | AMD_DA_C2 | AMD_RB_C3 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
0x0040, 0x0040 },
- { 0x41, AMD_RB_C2 | AMD_DA_C2 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
+ { 0x41, AMD_RB_C2 | AMD_DA_C2 | AMD_RB_C3 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
0x0040, 0x0040 },
- { 0x42, AMD_RB_C2 | AMD_DA_C2 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
+ { 0x42, AMD_RB_C2 | AMD_DA_C2 | AMD_RB_C3 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
0x0040, 0x0040 },
- { 0x43, AMD_RB_C2 | AMD_DA_C2 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
+ { 0x43, AMD_RB_C2 | AMD_DA_C2 | AMD_RB_C3 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
0x0040, 0x0040 },
- { 0x44, AMD_RB_C2 | AMD_DA_C2 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
+ { 0x44, AMD_RB_C2 | AMD_DA_C2 | AMD_RB_C3 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
0x0040, 0x0040 },
- { 0x45, AMD_RB_C2 | AMD_DA_C2 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
+ { 0x45, AMD_RB_C2 | AMD_DA_C2 | AMD_RB_C3 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
0x0040, 0x0040 },
- { 0x46, AMD_RB_C2 | AMD_DA_C2 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
+ { 0x46, AMD_RB_C2 | AMD_DA_C2 | AMD_RB_C3 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
0x0040, 0x0040 },
- { 0x47, AMD_RB_C2 | AMD_DA_C2 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
+ { 0x47, AMD_RB_C2 | AMD_DA_C2 | AMD_RB_C3 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
0x0040, 0x0040 },
- { 0x48, AMD_RB_C2 | AMD_DA_C2 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
+ { 0x48, AMD_RB_C2 | AMD_DA_C2 | AMD_RB_C3 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
0x0040, 0x0040 },
- { 0x50, AMD_RB_C2 | AMD_DA_C2 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
+ { 0x50, AMD_RB_C2 | AMD_DA_C2 | AMD_RB_C3 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
0x0040, 0x0040 },
- { 0x51, AMD_RB_C2 | AMD_DA_C2 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
+ { 0x51, AMD_RB_C2 | AMD_DA_C2 | AMD_RB_C3 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
0x0040, 0x0040 },
- { 0x52, AMD_RB_C2 | AMD_DA_C2 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
+ { 0x52, AMD_RB_C2 | AMD_DA_C2 | AMD_RB_C3 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
0x0040, 0x0040 },
- { 0x53, AMD_RB_C2 | AMD_DA_C2 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
+ { 0x53, AMD_RB_C2 | AMD_DA_C2 | AMD_RB_C3 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
0x0040, 0x0040 },
- { 0x54, AMD_RB_C2 | AMD_DA_C2 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
+ { 0x54, AMD_RB_C2 | AMD_DA_C2 | AMD_RB_C3 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
0x0040, 0x0040 },
- { 0x55, AMD_RB_C2 | AMD_DA_C2 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
+ { 0x55, AMD_RB_C2 | AMD_DA_C2 | AMD_RB_C3 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
0x0040, 0x0040 },
- { 0x56, AMD_RB_C2 | AMD_DA_C2 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
+ { 0x56, AMD_RB_C2 | AMD_DA_C2 | AMD_RB_C3 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
0x0040, 0x0040 },
- { 0x57, AMD_RB_C2 | AMD_DA_C2 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
+ { 0x57, AMD_RB_C2 | AMD_DA_C2 | AMD_RB_C3 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
0x0040, 0x0040 },
- { 0x58, AMD_RB_C2 | AMD_DA_C2 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
+ { 0x58, AMD_RB_C2 | AMD_DA_C2 | AMD_RB_C3 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
0x0040, 0x0040 },
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] ht init and some errata for AMD fam 10 RB_C3
Signed off by: Xavi Drudis Ferran xdru...@tinet.cat
On Thu, Aug 19, 2010 at 11:52:22PM +0200, xdrudis wrote:
My smallest patch ever
I've checked Revision Guide for AMD Family10h processors (#41322) rev
3.74 June 2010 for errata 351 and it agrees with the comment on
setting ForceFullT0= 000b but I believe the code didn't honor the
comment.
apply this after patch.rbc3infam10all
Index: src/cpu/amd/model_10xxx/defaults.h
===
--- src/cpu/amd/model_10xxx/defaults.h(revision 5719)
+++ src/cpu/amd/model_10xxx/defaults.h(working copy)
@@ -157,7 +157,7 @@
/* Link Global Extended Control Register */
{ 0, 0x16C, AMD_DRBA23_RBC2, AMD_PTYPE_ALL,
- 0x0014, 0x003F }, /* [15:13] ForceFullT0 = 0b,
+ 0x0014, 0xE03F }, /* [15:13] ForceFullT0 = 0b,
* Set T0Time
14h per BKDG */
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [commit] r5717 - in trunk/src/superio/fintek: . f71863fg
On Wed, Aug 18, 2010 at 03:07:04PM -0400, Corey Osgood wrote: Most of the code in these files is trivial and identical to every other super IO, with the exception of changing the model name/number. If we kept the copyright notices from every previous author of those files, it would probably be a dozen names, none of whom actually wrote the code in the first place. -Corey IANAL, but as far as I know triviality, obviousness or inventivity has nothing to do with copyright. The only requirement is originality (and maybe it depends on jurisdiction). I'm not sure what's the threshold for originality. In any case I believe if it isn't original it isn't copyrightable, so it makes no sense to add the last author name. In order to be legally able to remove a previous author name you should be sure that his or her part in the code is not copyrightable, and that is hard to argue. So I think it is much easier, safe and sound to keep a dozen (or a dozen dozens) list of authors than to remove a copyright notice, unless legal advice says otherwise, or some of the previous authors removes herself or asks to be removed. That being said, it wouldn't be the first time that I fail in doing this, but never on purpose (typically when copying parts of a file to another, not when copying the whole file and then changing it). Xavi. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [commit] r5717 - in trunk/src/superio/fintek: . f71863fg
On Wed, Aug 18, 2010 at 05:53:19PM -0400, Corey Osgood wrote: Here's the problem: some time ago, someone wrote a superio chip.h that contained this: [...] Sorry, I didn't understand the problem. I thought it was triviality and it was removal of the whole contribution of a previous author. removing everything that I did to that file. So why should they leave me as a copyright holder on the file? Because it is easier than finding out who is the real author of the part of the file that survives. It makes nothing worse than it was and it does not bring more risks than removing your name. If they remove your copyright statement they have to make sure that you really didn't change more than what they have replaced. They may not be able to verify that unless svn kept track of which was the original file (I think it depends on whether you did svn cp or cp ?). If they leave your name and there's nothing you wrote on the file what's the worst than can happen ? That you sue them for attributing to you something you didn't write ? I don't think you could, specially if they add their own name, they are not saying which author wrote what. They took a collective work, made a derivative work and added their name to the previous authors. If you don't want that then simply add a comment speciying which part are yours and which aren't (but I hope you don't). If they remove your name and somehow you had changed something in the file that's still there they could have more problems, I think. If somebody knew what the first file was, at least pepole could always use that as a template and keep the copyright notices shorter (they and the original author). But if it's too late for that I don't think that following the routine of keeping the original copyrights has so severe a consequence that it is worth making exceptions. But I think I'm arguing too much for something that it is not so important to me and that I'm no expert in. I feel like I'm splitting hair. I should be splitting patches... -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] update processor names for AMD
Hello.
This is a patch for setting the processor names updated to the
same doc as the original but revision June 2010.
It applies to svn 5703 and I tested it with my previous patch.warnerrors
and patch.serial1 and it makes no difference. I can't tell whether
it works yet, but maybe someone else can try it if their boards boot.
Signed off by: Xavi Drudis Ferran xdru...@tinet.cat
Index: src/cpu/amd/model_10xxx/processor_name.c
===
--- src/cpu/amd/model_10xxx/processor_name.c(revision 5692)
+++ src/cpu/amd/model_10xxx/processor_name.c(working copy)
@@ -23,6 +23,8 @@
*
* Revision Guide for AMD Family 10h Processors
* Publication # 41322 Revision: 3.17 Issue Date: February 2008
+ * modified by Xavi Drudis Ferran (xdru...@tinet.cat) 2010-08-01
+ * from #41322 Revision: 3.74 Issue Date: June 2010
*/
#include console/console.h
@@ -45,17 +47,21 @@
char const *value;
};
+ // nodocs == were in the old sources, but are not in current docs
static const struct str_s String1_socket_F[] = {
- {0x00, 0x01, 0x00, Dual-Core AMD Opteron(tm) Processor 83},
- {0x00, 0x01, 0x01, Dual-Core AMD Opteron(tm) Processor 23},
+ {0x00, 0x01, 0x00, Dual-Core AMD Opteron(tm) Processor 83}, /*nodocs*/
+ {0x00, 0x01, 0x01, Dual-Core AMD Opteron(tm) Processor 23}, /*nodocs*/
{0x00, 0x03, 0x00, Quad-Core AMD Opteron(tm) Processor 83},
{0x00, 0x03, 0x01, Quad-Core AMD Opteron(tm) Processor 23},
- {0x00, 0x03, 0x02, Embedded AMD Opteron(tm) Processor 83},
- {0x00, 0x03, 0x03, Embedded AMD Opteron(tm) Processor 23},
- {0x00, 0x03, 0x04, Embedded AMD Opteron(tm) Processor 13},
- {0x00, 0x03, 0x05, AMD Phenom(tm) FX-},
- {0x01, 0x01, 0x01, Embedded AMD Opteron(tm) Processor},
+ {0x00, 0x03, 0x02, Embedded AMD Opteron(tm) Processor 83}, /*nodocs*/
+ {0x00, 0x03, 0x03, Embedded AMD Opteron(tm) Processor 23}, /*nodocs*/
+ {0x00, 0x03, 0x04, Embedded AMD Opteron(tm) Processor 13}, /*nodocs*/
+ {0x00, 0x03, 0x05, AMD Phenom(tm) FX-}, /*nodocs*/
+ {0x00, 0x05, 0x00, Six-Core AMD Opteron(tm) Processor 84},
+ {0x00, 0x05, 0x01, Six-Core AMD Opteron(tm) Processor 24},
+ {0x01, 0x01, 0x01, Embedded AMD Opteron(tm) Processor}, /*nodocs*/
+ {0x01, 0x03, 0x01, Embedded AMD Opteron(tm) Processor },
{0, 0, 0, NULL}
};
@@ -63,22 +69,64 @@
{0x00, 0xFF, 0x0A, SE},
{0x00, 0xFF, 0x0B, HE},
{0x00, 0xFF, 0x0C, EE},
- {0x00, 0xFF, 0x0D, Quad-Core Processor},
+ {0x00, 0xFF, 0x0D, Quad-Core Processor}, /*nodocs*/
{0x00, 0xFF, 0x0F, },
- {0x01, 0x01, 0x01, GF HE},
+ {0x00, 0x05, 0x00, SE},
+ {0x00, 0x05, 0x01, HE},
+ {0x00, 0x05, 0x02, EE},
+
+ {0x01, 0x03, 0x01, GF HE},
+ {0x01, 0x03, 0x02, HF HE},
+ {0x01, 0x03, 0x03, VS},
+ {0x01, 0x03, 0x04, QS HE},
+ {0x01, 0x03, 0x05, NP HE},
+ {0x01, 0x03, 0x06, KH HE},
+ {0x01, 0x03, 0x07, KS EE},
+
{0, 0, 0, NULL}
};
static const struct str_s String1_socket_AM2[] = {
- {0x00, 0x00, 0x00, AMD Athlon(tm) Processor LE-},
- {0x00, 0x00, 0x01, AMD Sempron(tm) Processor LE-},
- {0x00, 0x01, 0x00, Dual-Core AMD Opteron(tm) Processor 13},
- {0x00, 0x01, 0x01, AMD Athlon(tm)},
+{0x00, 0x00, 0x02, AMD Sempron(tm) 1},
+{0x00, 0x00, 0x03, AMD Athlon(tm) II 1},
+{0x00, 0x00, 0x01, AMD Athlon(tm) },
+
+// duplicated in documentation
+{0x00, 0x00, 0x03, AMD Athlon(tm) II X2 2},
+
+{0x00, 0x00, 0x04, AMD Athlon(tm) II X2 B},
+{0x00, 0x00, 0x05, AMD Athlon(tm) II X2 },
+{0x00, 0x00, 0x07, AMD Phenom(tm) II X2 5},
+{0x00, 0x00, 0x0A, AMD Phenom(tm) II X2 },
+{0x00, 0x00, 0x0B, AMD Phenom(tm) II X2 B},
+{0x00, 0x00, 0x0C, AMD Sempron(tm) X2 1},
{0x00, 0x02, 0x00, AMD Phenom(tm)},
+{0x00, 0x02, 0x03, AMD Phenom(tm) II X3 B},
+{0x00, 0x02, 0x04, AMD Phenom(tm) II X3 },
+{0x00, 0x02, 0x07, AMD Athlon(tm) II X3 4},
+{0x00, 0x02, 0x08, AMD Phenom(tm) II X3 7},
+{0x00, 0x02, 0x0A, AMD Athlon(tm) II X3 },
{0x00, 0x03, 0x00, Quad-Core AMD Opteron(tm) Processor 13},
+{0x00, 0x03, 0x02, AMD Phenom(tm) },
+{0x00, 0x03, 0x03, AMD Phenom(tm) II X4 9},
+{0x00, 0x03, 0x04, AMD Phenom(tm) II X4 8},
+{0x00, 0x03, 0x07, AMD Phenom(tm) II X4 B},
+{0x00, 0x03, 0x08, AMD Phenom(tm) II X4 },
+{0x00, 0x03, 0x0A, AMD Athlon(tm) II X4 6},
+{0x00, 0x03, 0x0F, AMD Athlon(tm) II X4 },
+{0x00, 0x05, 0x00, AMD Phenom(tm) II X6 1},
+{0x01, 0x03, 0x02, AMD Phenom(tm) II X4 9},
+{0x01, 0x03, 0x03, AMD Phenom(tm) II X4 8},
+
+ {0x00, 0x00, 0x00, AMD Athlon(tm) Processor LE-}, /*nodocs*/
+ {0x00, 0x01, 0x00, Dual-Core AMD Opteron(tm) Processor
[coreboot] [PATCH] ht init and some errata for AMD fam 10 RB_C3
Hi.
This is the rest of patches to get until fidvid or staring
ram stage, apparently at random. In fact once I've cleaned
up the other patches a little I can't seem to make it stop at fidvid
as it used to, but I guess with a dozen more tries it will...
It's including RB-C3 in AMD_FAM10_ALL
and adding some patches. It misses constants for new models
that should also get some errata treatment.
It applies to 5703 with patch.warnerror, patch.serial1, and
patch procnames, together with the new m4a77td-pro dir I haven't
sent.
I know I should split it to smaller pieces, I just haven't had
the time yet, and there's some overlap, so I must take care...
Signed off by: Xavi Drudis Ferran xdru...@tinet.cat
Index: src/cpu/amd/model_10xxx/defaults.h
===
--- src/cpu/amd/model_10xxx/defaults.h (revision 5692)
+++ src/cpu/amd/model_10xxx/defaults.h (working copy)
@@ -88,6 +88,10 @@
{ CPUIDFEATURES, AMD_FAM10_ALL, AMD_PTYPE_DC,
0x, 1 (33-32),
0x, 1 (33-32) }, /* [ExtendedFeatEn]=1 */
+
+{ BU_CFG2, AMD_DRBH_Cx , AMD_PTYPE_ALL,
+ 0x, 1 (35-32),
+ 0x, 1 (35-32) }, /* Erratum 343 (set to 0 after CAR, in
post_cache_as_ram() ) */
};
@@ -136,28 +140,28 @@
* program Link Global Extended Control Register[ForceFullT0]
* (F0x16C[15:13]) to 000b */
- { 0, 0x170, AMD_FAM10_ALL, AMD_PTYPE_ALL, /* Fix FAM10_ALL when fixed
in rev guide */
+ { 0, 0x170, AMD_DRBA23_RBC2, AMD_PTYPE_ALL, /* FIXME Should include
BL_C2 but there is no constant */
0x, 0x0100 },
- { 0, 0x174, AMD_FAM10_ALL, AMD_PTYPE_ALL,
+ { 0, 0x174, AMD_DRBA23_RBC2, AMD_PTYPE_ALL,
0x, 0x0100 },
- { 0, 0x178, AMD_FAM10_ALL, AMD_PTYPE_ALL,
+ { 0, 0x178, AMD_DRBA23_RBC2, AMD_PTYPE_ALL,
0x, 0x0100 },
- { 0, 0x17C, AMD_FAM10_ALL, AMD_PTYPE_ALL,
+ { 0, 0x17C, AMD_DRBA23_RBC2, AMD_PTYPE_ALL,
0x, 0x0100 },
- { 0, 0x180, AMD_FAM10_ALL, AMD_PTYPE_ALL,
+ { 0, 0x180, AMD_DRBA23_RBC2, AMD_PTYPE_ALL,
0x, 0x0100 },
- { 0, 0x184, AMD_FAM10_ALL, AMD_PTYPE_ALL,
+ { 0, 0x184, AMD_DRBA23_RBC2, AMD_PTYPE_ALL,
0x, 0x0100 },
- { 0, 0x188, AMD_FAM10_ALL, AMD_PTYPE_ALL,
+ { 0, 0x188, AMD_DRBA23_RBC2, AMD_PTYPE_ALL,
0x, 0x0100 },
- { 0, 0x18C, AMD_FAM10_ALL, AMD_PTYPE_ALL,
+ { 0, 0x18C, AMD_DRBA23_RBC2, AMD_PTYPE_ALL,
0x, 0x0100 },
- { 0, 0x170, AMD_FAM10_ALL, AMD_PTYPE_ALL,
+ { 0, 0x170, AMD_DRBA23_RBC2, AMD_PTYPE_ALL,
0x, 0x0100 },
/* Link Global Extended Control Register */
- { 0, 0x16C, AMD_FAM10_ALL, AMD_PTYPE_ALL,
- 0x0014, 0x003F }, /* [15:13] ForceFullT0 = 0b,
+ { 0, 0x16C, AMD_DRBA23_RBC2, AMD_PTYPE_ALL,
+ 0x0014, 0xE03F }, /* [15:13] ForceFullT0 = 0b,
* Set T0Time
14h per BKDG */
@@ -290,9 +294,9 @@
[5] DisPciCfgCpuMstAbtRsp = 1,
[1] SyncFloodOnUsPwDataErr = 1 */
- /* errata 346 - Fam10 C2
+ /* errata 346 - Fam10 C2 -- FIXME at 25.6.2010 should apply to BL-C[23]
too but I can't find their constants
* System software should set F3x188[22] to 1b. */
- { 3, 0x188, AMD_RB_C2 | AMD_DA_C2 | AMD_DA_C3, AMD_PTYPE_ALL,
+ { 3, 0x188, AMD_DR_Cx, AMD_PTYPE_ALL,
0x0040, 0x0040 },
/* L3 Control Register */
@@ -317,9 +321,9 @@
u32 mask;
} fam10_htphy_default[] = {
- /* Errata 344 - Fam10 C2/D0
+ /* Errata 344 - Fam10 C2/D0 -- FIXME at 25.6.2010 should be for
((RB|BL|DA)-C[23])|(HY-D[01])|(PH-E0) but I don't find constants for all of them
* System software should set bit 6 of F4x1[9C, 94, 8C, 84]_x[78:70,
68:60]. */
- { 0x60, AMD_RB_C2 | AMD_DA_C2 | AMD_DA_C3 | AMD_HY_D0, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
+ { 0x60, AMD_DRBH_Cx , AMD_PTYPE_ALL, HTPHY_LINKTYPE_ALL,
0x0040, 0x0040 },
{ 0x61, AMD_RB_C2 | AMD_DA_C2 | AMD_DA_C3 | AMD_HY_D0, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
0x0040, 0x0040 },
@@ -357,44 +361,44 @@
{ 0x78, AMD_RB_C2 | AMD_DA_C2 | AMD_DA_C3 | AMD_HY_D0, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
0x0040, 0x0040 },
- /* Errata 354 - Fam10 C2
+ /* Errata 354 - Fam10 C2 - FIXME at 25.6.2010 affects RB-C2,
BL-C2,DA-C2,RB-C3,BL-C3,DA-C3, but BL-C[23] have no constants
* System software should set bit 6 of F4x1[9C,94,8C,84]_x[58:50,
48:40] for all links. */
- { 0x40, AMD_RB_C2 | AMD_DA_C2 | AMD_DA_C3, AMD_PTYPE_ALL,
HTPHY_LINKTYPE_ALL,
+ { 0x40, AMD_RB_C2 | AMD_DA_C2 |
[coreboot] [PATCH] Eliminate some warnings treated as errors
After I copied mainboard/amd/tilapia-fam10 dir for mainboard/asus/m4a77td-pro,
adapted it a litlle
and changed mainboard/asus/Kconfig and makemenuconfig, I had
to change a few small things because I got warnings treated as
erroes for unused symbols.
patch.warnerror
With only this patch applied to svn rev 5701
I can compile but I can't see anything in the serial port.
(I can send the current diff between m4a77td-pro and tilapia-fam10, but maybe
I wait until it boots?)
Signed off by: Xavi Drudis Ferran xdru...@tinet.cat
Index: src/northbridge/amd/amdht/h3finit.c
===
--- src/northbridge/amd/amdht/h3finit.c (revision 5692)
+++ src/northbridge/amd/amdht/h3finit.c (working copy)
@@ -845,8 +845,8 @@
*/
static void coherentInit(sMainData *pDat)
{
- u8 i, j;
+
#ifdef HT_BUILD_NC_ONLY
/* Replace discovery process with:
* No other nodes, no coherent links
@@ -856,6 +856,8 @@
pDat-TotalLinks = 0;
pDat-nb-enableRoutingTables(0, pDat-nb);
#else
+ u8 i, j;
+
pDat-NodesDiscovered = 0;
pDat-TotalLinks = 0;
for (i = 0; i MAX_NODES; i++)
Index: src/northbridge/amd/amdht/h3ncmn.c
===
--- src/northbridge/amd/amdht/h3ncmn.c (revision 5692)
+++ src/northbridge/amd/amdht/h3ncmn.c (working copy)
@@ -1553,6 +1553,8 @@
*
*
---
*/
+#ifndef HT_BUILD_NC_ONLY
+
static void fam0fWriteHTLinkCmdBufferAlloc(u8 node, u8 link, u8 req, u8 preq,
u8 rsp, u8 prb)
{
u32 temp;
@@ -1574,6 +1576,7 @@
temp = prb;
AmdPCIWriteBits(currentPtr, 15, 12, temp);
}
+#endif /* HT_BUILD_NC_ONLY */
/**
*
@@ -1594,6 +1597,8 @@
*
*
---
*/
+#ifndef HT_BUILD_NC_ONLY
+
static void fam0fWriteHTLinkDatBufferAlloc(u8 node, u8 link, u8 reqD, u8
preqD, u8 rspD)
{
u32 temp;
@@ -1612,6 +1617,7 @@
temp = rspD;
AmdPCIWriteBits(currentPtr, 26, 24, temp);
}
+#endif /* HT_BUILD_NC_ONLY */
/**
*
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Ban device scan to get serialport on ASUS M4A77TD-PRO
On Mon, Aug 16, 2010 at 06:21:31PM +0200, Xavi Drudis Ferran wrote:
Xavi Drudis Ferran wrote:
1.- In order to get sb700_lpc_init in sb700_early_setup.c to work
I've got to modifiy pci_locate_device in order to refrain from
scanning some functions in pci bus 0.
Hm. Which fn?
Sorry, I should have said devices. I think it scans every function of every
device, reg. 00
and I told it not to do so for any function of some devices (those with
nothing attached
in my board). I'll send the patch later.
Here's the patch. I'll attach lspci output with the propietary BIOS
in order to compare with the excluded devices. I'm testing without
the Nvidia VGA, though.
With svn 5701 + the earlier patch patch.warnerror + patch.serial1
that I'll attach here, my mainboard outputs to serial and stops
at setAMDMSR (after start other cores, so I might misread the log)
I don't know if it makes sense. That's not neccessarily the case. It
depends on if the SB700 can have a different BDF on different boards.
I'd say no, but what do I know?
but then I wonder whether my change is acceptable for other
mainboards,
No, I don't think it is.
Please don't commit this patch. It's just an illustration on
what I did to have serial output, but it may break other boards,
or (I don't think so) the same mainboard with other hardware attached.
It seems I have to sign off even if I'm asking not to be commited so:
Signed off by: Xavi Drudis Ferran xdru...@tinet.cat
In general nothing should be hard coded that is not hard coded in
documentation. Ie. if BDF *can* change, then it can not be hard
coded. However, the BDF should already be available from
devicetree.cb, and hopefully that can be used also for early setup.
Ah, I'll see how to access de devicetree.cb, then. But I think it was
hardcoded in docs. They said dev 0 func 0x14 IIRC. I'll check again.
I'm rereading docs for SB700 linked from
http://www.coreboot.org/Datasheets#AMD_SB700.2FSB710.2FSB750
And I only see hardcoded BDF in the docs (in diagrams, chapter titles,
text and assembler examples).
So I thik I'll change
sb700_early_init to use hardcoded BDF unless someone thinks otherwise.
Ok. I have to clean up the code a little and incorporate las weekend svn
changes,
and then I'll break the changes in patches and start sending them. Beware
that they are not completely tested (my board does not boot yet).
It's getting late. I'll continue tomorrow.
-[:00]-+-00.0 ATI Technologies Inc RX780/RX790 Chipset Host Bridge
[1002:5957]
+-02.0-[:01]00.0 nVidia Corporation GeForce 8400 GS
[10de:06e4]
+-0a.0-[:02]00.0 Realtek Semiconductor Co., Ltd.
RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168]
+-11.0 ATI Technologies Inc SB700/SB800 SATA Controller [AHCI mode]
[1002:4391]
+-12.0 ATI Technologies Inc SB700/SB800 USB OHCI0 Controller
[1002:4397]
+-12.1 ATI Technologies Inc SB700 USB OHCI1 Controller [1002:4398]
+-12.2 ATI Technologies Inc SB700/SB800 USB EHCI Controller
[1002:4396]
+-13.0 ATI Technologies Inc SB700/SB800 USB OHCI0 Controller
[1002:4397]
+-13.1 ATI Technologies Inc SB700 USB OHCI1 Controller [1002:4398]
+-13.2 ATI Technologies Inc SB700/SB800 USB EHCI Controller
[1002:4396]
+-14.0 ATI Technologies Inc SBx00 SMBus Controller [1002:4385]
+-14.1 ATI Technologies Inc SB700/SB800 IDE Controller [1002:439c]
+-14.2 ATI Technologies Inc SBx00 Azalia (Intel HDA) [1002:4383]
+-14.3 ATI Technologies Inc SB700/SB800 LPC host controller
[1002:439d]
+-14.4-[:03]--
+-14.5 ATI Technologies Inc SB700/SB800 USB OHCI2 Controller
[1002:4399]
+-18.0 Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64,
Sempron] HyperTransport Configuration [1022:1200]
+-18.1 Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64,
Sempron] Address Map [1022:1201]
+-18.2 Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64,
Sempron] DRAM Controller [1022:1202]
+-18.3 Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64,
Sempron] Miscellaneous Control [1022:1203]
\-18.4 Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64,
Sempron] Link Control [1022:1204]
Index: src/arch/i386/include/arch/romcc_io.h
===
--- src/arch/i386/include/arch/romcc_io.h (revision 5682)
+++ src/arch/i386/include/arch/romcc_io.h (working copy)
@@ -243,17 +243,26 @@
pci_io_write_config32(dev, where, value);
#endif
}
+static inline __attribute__((always_inline)) int
forbidden_dev_for_locate(device_t dev)
+{ // empty pci slots hang pci_locate_device
+device_t dev_only = (dev PCI_DEV(0,0x1F,0));
+return ( ((dev_only = PCI_DEV(0,2,0)) (dev_only
Re: [coreboot] ASUS M4A77TD-PRO. No boot, nothing on the serial port. I'm quite lost.
On Tue, Aug 03, 2010 at 12:31:01AM +0200, Rudolf Marek wrote: Well please investigate because I put there already - it is the write to reg 0x72. There might be watchdog in SB700 datasheet says disabled by default but dunno if there is some possibility that it is enabled by default by some strap resistor. No, there isn't... Oh,wait. It's there. I spent most of yesterday's afternoon looking at the original code for asrock, not the file you sent me (I compiled the one you sent me but then compared the original one to the coreboot code, because I compile on the M4A77TD-PRO board on the serial port but look at the code in a laptop with VGA ). No wonder there were so many differences I didn't know which ones to pick... Some things didn't make sense... I'll look again today. Make sure you call sb700_lpc_init _before_ any access to superIO. Also I would suggest to use the tilapia_fam10 instead of a copy - you might forgotten to do something. Simply do changes to the tilapia_fam10 and rename/move to another dir late OK. The code in the SerialICE does same thing as sb700_lpc_init and it8712f_enable_serial. Thanks. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Light at the other side of the null modem cable
Ok. Now I've got two lines of output in the serial port from coreboot. Thank you very much. The way I got it is a dodge but at least maybe I can now add debug messages to find the proper way. I just replaced sb700_lpc_init by the corresponding code by Rudolf Marek in the serialICE mainboard . I can see two differences at first sight: seriaICE uses absolute pci address while sb700_lpc_init looks for PCI Ids, and serialICE writes all the bits of the registers while sb700_lpc_init changes just one bit. Besides, sb700_lpc_init initializes smbus also and does more stuff. On Tue, Aug 03, 2010 at 12:31:01AM +0200, Rudolf Marek wrote: Well please investigate because I put there already - it is the write to reg 0x72. There might be watchdog in SB700 datasheet says disabled by default but dunno if there is some possibility that it is enabled by default by some strap resistor. Aparently it's active. Make sure you call sb700_lpc_init _before_ any access to superIO. Looking at coreboot there were (at least) two places where watchdogs get killed (or something like it). One is the one you put in serialICE and the other is inside sb700_lpc_init : dev = pci_locate_device(PCI_ID(0x1002, 0x4385), 0); /* SMBUS contro\ ller */ /* NOTE: Set BootTimerDisable, otherwise it would keep rebooting!! * This bit has no meaning if debug strap is not enabled. So if the * board keeps rebooting and the code fails to reach here, we could * disable the debug strap first. */ reg32 = pci_read_config32(dev, 0x4C); reg32 |= 1 31; pci_write_config32(dev, 0x4C, reg32); But the odd thing is that when coreboot has output to the serial port (once, no reboot) this code was not running. So I don't see why it doesn't reboot like serialICE. Maybe it simply has hanged before the timeout (but aren't the watchdogs meant to prevent just this?). A hang is not surprising since I removed quite a lot of initialisation from sb700_lpc_init . I could try to add code similar to that above to serialICE and see what happens. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Light at the other side of the null modem cable
On Tue, Aug 03, 2010 at 11:22:29AM +0200, xdrudis wrote:
I could try to add code similar to that above to serialICE and see
what happens.
Done. It now boots serialICE once and starts the shell. I haven't downloaded
qemu, patched it and tested with a coreboot image (or the propietary bios),
but the commands I entered at the shell were answered ok as far as I
can tell.
Here's the patch against the file Rudolf Marek sent,
but I'll attach the modified file too.
--- asrock_939a785gmh.c 2010-08-03 12:08:04.0 +0200
+++ SerialICE/mainboard/asrock_939a785gmh.c2010-08-03
12:02:34.0 +0200
@@ -42,6 +42,10 @@
static void chipset_init(void)
{
+u32 reg32 = pci_read_config32(PCI_ADDR(0, 0x14, 0, 0x4C));
+reg32 |= 1 31;
+pci_write_config32(PCI_ADDR(0, 0x14, 0, 0x4C), reg32);
+
/* Enable LPC decoding */
pci_write_config8(PCI_ADDR(0, 0x14, 3, 0x44), (16));
/*
* SerialICE
*
* Copyright (C) 2006 Uwe Hermann u...@hermann-uwe.de
* Copyright (C) 2010 Rudolf Marek r.ma...@assembler.cz
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; version 2 of the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
const char boardname[33]=ALL YOUR BASE ARE BELONG TO US! ;
#define SUPERIO_CONFIG_PORT 0x2e
static void superio_init(void)
{
pnp_enter_ext_func_mode_ite(SUPERIO_CONFIG_PORT);
/* Disable the watchdog. */
pnp_set_logical_device(SUPERIO_CONFIG_PORT, 7);
pnp_write_register(SUPERIO_CONFIG_PORT, 0x72, 0x00);
/* Enable the serial port. */
pnp_set_logical_device(SUPERIO_CONFIG_PORT, 1); /* COM1 */
pnp_set_enable(SUPERIO_CONFIG_PORT, 0);
pnp_set_iobase0(SUPERIO_CONFIG_PORT, 0x3f8);
pnp_set_irq0(SUPERIO_CONFIG_PORT, 4);
pnp_set_enable(SUPERIO_CONFIG_PORT, 1);
pnp_exit_ext_func_mode_ite(SUPERIO_CONFIG_PORT);
}
static void chipset_init(void)
{
u32 reg32 = pci_read_config32(PCI_ADDR(0, 0x14, 0, 0x4C));
reg32 |= 1 31;
pci_write_config32(PCI_ADDR(0, 0x14, 0, 0x4C), reg32);
/* Enable LPC decoding */
pci_write_config8(PCI_ADDR(0, 0x14, 3, 0x44), (16));
pci_write_config8(PCI_ADDR(0, 0x14, 3, 0x48), (1 1) | (1 0));
superio_init();
}
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ASUS M4A77TD-PRO. No boot, nothing on the serial port. I'm quite lost.
On Mon, Aug 02, 2010 at 11:54:15AM +0200, Rudolf Marek wrote: When I boot with the propietary BIOS I can get GRUB2 and linux console on the serial port, but only at 38400 bps. 118000 does not work. So I've put 38400 in kconfig too. Hm this is strange. Maybe you can try with 9600 ? I'll try. Since docs say 118000 I thought the furthest from that the worst, so I didn't try. I checked your superiotool dump and it seems that you dont need to call it8712f_24mhz_in check if you do not call it by accident. I tried once with it8712f_24mhz_in but then I removed the call and I think most tests have been without it. I'll recheck. I would suggest to try to make it work with serialICE first, then fix the coreboot console as second step. Go to www.serialice.com and download it. Ok. I thought there was no hope for SerialICE if I can't make serial work in coreboot, but I'll give it a look. It is some kind of simple monitor which can execute various IO operations through serial port. I'm attaching a file which could do the trick for you. Set the baudspeed to 38400 and select that asrock board in kconfig. Replace the existing file with attached, and compile. Not sure if padding is there so if you get 64KB image then you need just to place the image in last 64KB of the flash. Then use minicom or whatever and see if you get the serialice prompt. If so, you just need to fix the coreboot to do same thing. Fine, thank you for giving options to try. I'll get back after these tests. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ASUS M4A77TD-PRO. No boot, nothing on the serial port. I'm quite lost.
On Mon, Aug 02, 2010 at 01:20:54PM +0200, Stefan Reinauer wrote: On 02.08.2010, at 12:43, xdrudis xdru...@tinet.cat wrote: On Mon, Aug 02, 2010 at 11:54:15AM +0200, Rudolf Marek wrote: When I boot with the propietary BIOS I can get GRUB2 and linux console on the serial port, but only at 38400 bps. 118000 does not work. So I've put 38400 in kconfig too. Hm this is strange. Maybe you can try with 9600 ? I'll try. Since docs say 118000 I thought the furthest from that the worst, so I didn't try. Sure it's not 115200? 118000 sounds very unusual. Yes, 115200, you're right, sorry . I wrote it in the mail from memory. But I did it right when trying, because at least minicom has the speed in the menu, and I know I checked it was the same everywhere. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ASUS M4A77TD-PRO. No boot, nothing on the serial port. I'm quite lost.
On Mon, Aug 02, 2010 at 01:20:54PM +0200, Stefan Reinauer wrote: On 02.08.2010, at 12:43, xdrudis xdru...@tinet.cat wrote: On Mon, Aug 02, 2010 at 11:54:15AM +0200, Rudolf Marek wrote: When I boot with the propietary BIOS I can get GRUB2 and linux console on the serial port, but only at 38400 bps. 118000 does not work. So I've put 38400 in kconfig too. Hm this is strange. Maybe you can try with 9600 ? I'll try. Since docs say 118000 I thought the furthest from that the worst, so I didn't try. Sure it's not 115200? 118000 sounds very unusual. Stefan Mph. :-( I feel more stupid than usual. Sorry for the noise. I just tried again with 115200 and grub 2 and linux console work with the propietary BIOS. I don't know what I did wrong the first time... The only thing I find different is that now I'm using ssh to access the other side of the null modem cable (an EPIA-M computer) and the other time I was using the keyboard at the EPIA-M console. I must have done some silly mistake the other time. But coreboot won't work yet at 9600, 38400 nor 115200 (I've rechecked I din't had the it8712f_24mhz_in call ). I'm going to try serialICE next. Thanks. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ASUS M4A77TD-PRO. No boot, nothing on the serial port. I'm quite lost.
On Mon, Aug 02, 2010 at 11:54:15AM +0200, Rudolf Marek wrote: I would suggest to try to make it work with serialICE first, then fix the coreboot console as second step. Go to www.serialice.com and download it. It is some kind of simple monitor which can execute various IO operations through serial port. I'm attaching a file which could do the trick for you. Set the baudspeed to 38400 and select that asrock board in kconfig. Replace the existing file with attached, and compile. Not sure if padding is there so if you get 64KB image then you need just to place the image in last 64KB of the flash. Then use minicom or whatever and see if you get the serialice prompt. If so, you just need to fix the coreboot to do same thing. Ok. I did it and I got the serialICE prompt (@38400). In fact it appears again and again every second or so. That suggests some watchdog might be rebooting the board. I already set the it8712f kill watchdog call in coreboot, not sure if it was needed, but it seems it is. I could put it in serialICE but unless I need to use SerialICE for something else I think I won't. In fact if I had done the qemu part coreboot itself might have reset the wachdog over the serial line, I guess. Thank you very much. Now I'm going to compare what serialICE does with what coreboot does and see where I get. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ASUS M4A77TD-PRO. First step: buy spare flash chips...
I forgot to add that the mainboard did not boot when I built the PC. It would only boot once when I cleared CMOS, and then never more until I cleared it again. I could fix it by downloading a BIOS image of a newer version from asus and flashing it (with a tool called EZ flash, I think, which was in the factory BIOS). Now it boots fine. I tried flashrom -r file.rom and it produced a file of the same size as the downloaded BIOS image ( 1 megabyte) but diff says the binary files differ. I'm not sure whether this means flashrom is not reading the BIOS 100% right or it's just normal because some parts of the file don't get copied to EEPROM or something... Where do you get your spare EEPROMs ? I've tried a couple of local electronics parts shops in Barcelona, and they hardly knew Macronix. They couldn't find any MX25L parts listed. I'll try again, I guess...But maybe I should go somewhere else ? -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] ASUS M4A77TD-PRO. First step: buy spare flash chips...
Hello. I finally bought the hardware I told you and installed gnewsense 3 with a custom linux-libre 2.6.34 : mainboard Asus M4A77TD-PRO http://www.asus.com/product.aspx?P_ID=0AvsBb7WBZe2i9zK CPU AMD Phenom X4 910e stepping c3 AMD 770 AMD SB710 RAM 2 x 4Gb dual channel non-ECC G.Skill DDR3-1333 PC3 10666 F3-10666CL9D-8GBRL superio ITE IT8712F (clearly marked on the chip and detected) lan: RTL8112L audio VIA VT1708S I've put a graphics card by MSI, Nvidia GeForce 8400GS passively cooled (no fan) on the PCIExpress 2.0 slot. I'll attachs the lspci and superiotool r3125 outputs (versions from gNewSense) and flashrom 0.9.2 downloaded and compiled from release tarball. Btw. The readme in flashrom 0.9.2 says to use make DESTDIR=/usr install if you don't want it in /usr/local, but this will install it in /usr/usr/local/sbin. To have it in /usr/sbin you need to run makePREFIX=/usr install. It's slightly confusing for me, I've had to look at the Makefile. Now, the first thing I want to do is to buy spare flash chips. But I'm not sure what chips or where to buy them. It's a socket with an eight pin chip (DIP-8?) (4 pins per side), roughly 5mm x 9mm I'd say it's by Macronix (and flashrom agrees). But I doubt about the specific model. The motherboard manual says 8Mb Flash ROM. The letters on the chip are very small and there's some marking over them that keeps me from reading them all . I'll copy here what I can read (i mark the most dubious letters with ?). (top left is a logo MX) - - - - -- -- - - = v = = =b09?714 = = = = 25L5???5PC-15G 3C153600 TAIWAN Looking at catalogues from macronix I think 25L is the family (SPI serial flash) 5?? should be the size (I'm not sure how many digits are there, not even 100% sure it's a 5) ?5 would be normal, write protected, duplex,etc. PC might be the process ( xx micrometers), -15 would be frequency of 66 Mhz and G something about lead free or environmental regulations. but flashrom says its a Macronix MX25L8005 . http://www.macronix.com/QuickPlace/hq/PageLibrary4825740B00298A3B.nsf/h_Index/6F878CF760C559BD482576E00022E6CC/?OpenDocumentEPN=MX25L8005 Now, the question is should I buy some MX25L8005 ? (apparently its end of life is 2010-11-30, so it should be available, but where in small quantities ? ) According to http://www.macronix.com/QuickPlace/hq/PageLibrary4825740B00298A3B.nsf/h_Index/430AA5580EA1C72E482576BE0004AF37/$File/PCN-10-035-B.pdf maybe I could try Mx25L8006EPI-12G Where do you get your spare EEPROMs ? Thank you. flashrom v0.9.2-r1001 on Linux 2.6.34-libre (x86_64), built with libpci 3.0.0, GCC 4.3.2 flashrom is free software, get the source code at http://www.flashrom.org Initializing internal programmer No coreboot table found. DMI string system-manufacturer: System manufacturer DMI string system-product-name: System Product Name DMI string system-version: System Version DMI string baseboard-manufacturer: ASUSTeK Computer INC. DMI string baseboard-product-name: M4A77TD PRO DMI string baseboard-version: Rev X.0x DMI string chassis-type: Desktop Found ITE Super I/O, id 8712 Found chipset AMD SB700/SB710/SB750, enabling flash write... SPI base address is at 0xfec1 AltSpiCSEnable=0, SpiRomEnable=1, AbortEnable=0 PrefetchEnSPIFromIMC=0, PrefetchEnSPIFromHost=1, SpiOpEnInLpcMode=1 SpiArbEnable=0, SpiAccessMacRomEn=1, SpiHostAccessRomEn=1, ArbWaitCount=0, SpiBridgeDisable=0, DropOneClkOnRd=0 GPIO11 used for SPI_DO GPIO12 used for SPI_DI GPIO31 used for SPI_HOLD GPIO32 used for SPI_CS GPIO47 used for SPI_CLK ROM strap override is not active OK. This chipset supports the following protocols: LPC,FWH,SPI. SuperI/O ID 8712 is not on the controller list. Calibrating delay loop... 871M loops per second, 10 myus = 10 us, 100 myus = 100 us, 1000 myus = 1001 us, 1 myus = 10010 us, OK. Probing for AMD Am29F010A/B, 128 KB: skipped. Probing for AMD Am29F002(N)BB, 256 KB: skipped. Probing for AMD Am29F002(N)BT, 256 KB: skipped. Probing for AMD Am29F016D, 2048 KB: skipped. Probing for AMD Am29F040B, 512 KB: skipped. Probing for AMD Am29F080B, 1024 KB: skipped. Probing for AMD Am29LV040B, 512 KB: skipped. Probing for AMD Am29LV081B, 1024 KB: skipped. Probing for ASD AE49F2008, 256 KB: skipped. Probing for Atmel AT25DF021, 256 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014 Probing for Atmel AT25DF041A, 512 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014 Probing for Atmel AT25DF081, 1024 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014 Probing for Atmel AT25DF161, 2048 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014 Probing for Atmel AT25DF321, 4096 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014 Probing for Atmel AT25DF321A, 4096 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014 Probing for Atmel AT25DF641, 8192 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014 Probing for Atmel AT25F512B, 64 KB: probe_spi_rdid_generic: id1 0xc2, id2 0x2014 Probing for Atmel AT25FS010, 128 KB: probe_spi_rdid_generic:
Re: [coreboot] Dualbios on GA-MA770-UD3
On Sun, Apr 25, 2010 at 01:45:19PM +0200, Peter Stuge wrote: xdrudis wrote: They might just use a watchdog: Ok. I'm rereading the link Gigabyte gave me, Please read the US Patent. I wasn't aware. I hadn't read your mail when I wrote mine. I started to read it, but your summary was more useful. As usual claims are so broad (they claim a computer, not merely a BIOS, a whatchdog, some circuit or a motherboard), so broad you can't even buy a CPU, DIMMS and their motherboard and build a PC unless you comply with some license by them, and who would buy a motherboard and not build a PC with it ?. I guess they give you a license for the patent when you buy their motherboard, but then under what terms ? Don't take it as legal advice, IANAL, I guess any judge would narrow the claims to the inventive step or something, just laughing at the tipically silly language. But of course you meant the description, not the claims. Thank you. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Dualbios on GA-MA770-UD3
On Sat, Apr 24, 2010 at 08:26:45PM +0200, Patrick Georgi wrote: Am 24.04.2010 19:43, schrieb xdrudis: They might just use a watchdog: - BIOS 1 sets a flag - BIOS 1 configures the watchdog to trigger when it's not touched within 2 seconds (or whatever). watchdog would reboot the system then - BIOS 1 jumps in BIOS 2 - BIOS 2 does whatever it needs to do to consider itself safe - Meanwhile, BIOS 2 touches the watchdog every so often - BIOS 2 deactivates the watchdog In this scenario, coreboot would have to know how to tell the watchdog to reset its countdown, and how to disable the watchdog, to safely use the Dual BIOS feature. Ok. I'm rereading the link Gigabyte gave me, which does not explain enough or I don't understand it enough, but it might be this scenario you explain http://www.gigabyte.com.tw/FileList/NewTech/2006_motherboard_newtech/article_04_bios_explained.htm (the URL says 2006 but it was given to me in a mail in early March 2010) I've noticed they say it reboots before running the other BIOS, it's not just a jump. How would that work ? would it be some flag in CMOS ? This is better, I guess in that it gives both BIOSes the same initial state. It also says the original BIOS checks both BIOS copies, but I guess it doesn't matter since it will only run if coreboot fails, and then you have to reflash it anyway. The feature supposedly shouldn't just guard against non-Gigabyte images, but against issues with their own images, too - and those would have the right signature, and thus would pass any such test. I'd be really amazed if they'd add another chip (that actually costs money) and then only implement an incomplete protection scheme with it. Ok. It makes sense. Thank you for explaining. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Dualbios on GA-MA770-UD3
Thank you for your work on Dual BIOS. What I don't understand is how is this supposed to work. From what you say and what I asked sales cotact staff at gigabyte (no very useful insights) , there are two bios roms. One has the ability to check the other and run it only if it detects it's ok. If it doesn't it flashes itself to it. So if you use one of the BIOS for coreboot it will either be rewriten by the original BIOS or it will boot, depending on which ROM boots first and which ROM you put coreboot in. If you flash the ROM that boots first you can try coreboot, but in case it doesn't work how are you going to jump to the original BIOS ? If you flash the other ROM then apparently the original BIOS will boot and do what it pleases, possibly overwrite coreboot, or assuming you can trick it to believe coreboot is a correct BIOS then maybe jump to it after some initialisation, but will coreboot then have a chance to work from the same state it would in case it had booted first ? Tricking the original BIOS to believe coreboot is a correct image may be hard. In the worst case you may have to break a digital signature without the private key. This is not directly related, but gives an idea of how hard it could be http://invisiblethingslab.com/resources/bh09usa/Attacking Intel BIOS.pdf But assuming you can, will using coreboot after other firmware has set up things far enough to be able to test the ROM where coreboot is in, will that be a sufficient test ? I'm not saying it won't, I have no clue. Anyway, being able to flash both chips is good at the very least in order to have more space for payloads or so. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] DDR3 support of AMD Family 10
On Fri, Apr 23, 2010 at 09:24:43AM +0800, Bao, Zheng wrote: DDR3 supporting is added. Thank you very much. I would thank you more but I'm too busy looking at what to buy from AMD... -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Doubts about necessity of propietary parts in the firmware
On Wed, Apr 14, 2010 at 10:18:50AM +0800, Qing Pei Wang wrote: the 780 mainboard which coreboot support now is mahogany. I am trying to porting a few more mainboard as GSOC project. the mainboard i choose at this moment is 1)Shine,2)Tilapia,3)Gigabyte GA-MA78GM-S2H,4)ASUS M4A78-VM 5)Colorful C.A780G X5. i am aslo checking if i can order an Jetway PA78VM5-H which Scott have much interests. You can choose one of them or the other 780 mainboard. Thank you very much. I found the Gigabyte GA-MA78GM-S2H at http://www.gigabyte.com.tw/Products/Motherboard/Products_Spec.aspx?ClassValue=MotherboardProductID=2758ProductName=GA-MA78GM-S2H (max 16 Gb RAM) ASUS M4A78-VM at http://www.asus.com/product.aspx?P_ID=daNjn5iQIh14MVvN (max 8Gb RAM) Jetway PA78VM5-H at http://www.jetwaycomputer.com/spec/PA78VM5-H.pdf But its maximum RAM seems to be 4Gb, and I'd like something more and Colorful C.A780G X5 http://en.colorful.cn/Product/Specific.aspx?GUID=445638f9-8ec4-423b-8c00-4f0b812b991e I can't find how much RAM can it hold (the picture shows 4 slots) It has 2x8 Mb Rom chips, maybe socketed (by the picture, I didn't find any manual) But I didn't find any mainboard by the name Shine or Tilapia, do you have any reference? most of the bios with public mainbard are soldered, but you can also use flashrom or external programmer which has test clip. take this as an example http://www.dediprog.com/SPI-flash-in-circuit-programming/ISP-Testclip-SO8 Ok, thank you very much. I'll try to use flashrom and buy the programmer + clip when I brick it. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Doubts about necessity of propietary parts in the firmware
On Tue, Apr 13, 2010 at 09:44:02AM -0600, Marc Jones wrote: Hi Xavi, Thanks for your interest in coreboot. This is a long email! :) I'm bad at summarizing. Sorry. VGA BIOS is not required. You could have a headless system. Or a system with a framebuffer driver like Geode. Headless would be last resort. If possible I would like to have a monitor connected to the system (either mainboard or graphics card) and have a desktop there. I don't need video while booting (but I would appreciate it, of course). I understand this is possible depending on the GPU. When you say a system with a framebuffer you mean any system with linux User Mode Setting should work without propietary VGA BIOS ? Double graphics is a problem ? As far as I know the only modern desktop class chipsets supported by the manufacturer, are AMD RS780/SB700 , am I wrong ? (thanks, AMD!). I think all come with an ATI IGP , which requires blobs in the linux/X driver (AtomBIOS). I may be misinformed on AtomBIOS, but I think I don't want to use it. I've heard nouveau has just deblobed its driver, so I might add an Nvidia graphics card to it (at least while Open Graphics Project isn't ready for consumers). I'll try to buy one second hand, as lesser evil, since I dislike buying directly from vendors not supporting free software. Does having both the ATI IGP and the Nvidia card give any additional complication ? (besides it's going to be less tested than more usual setups). I wish Intel supported coreboot or radeonhd didn't use AtomBIOS (like it once was). This is a continued area of development, but yes, many drivers use the vbios too hold proprietary information. Again, not an issue if you are running a headless machine. Do you mean deblobing linux/X graphics drivers is a continued area of development or supporting IGP + graphics card in coreboot (if it needs some speacial support by corebbot) is a continued area of development ? There is no specific roadmap. This is usually driven by board availability. I think some boards will be ported during GSoC. If you have a preferred board, send an email to the list. Someone might be working on it. I don't have a prefered board (yet). I was thinking of picking one of the few that people has shown some interest in here in the list. That might be best for me as a newbie as I wouldn't be alone even if it is not currently supported yet. I'm not sure if it would be best for the project (having more that one test instance for the same board ) or it would be best to have as many different boards to test as possible. I think that DDR3 support will be critical for coreboot this year. I am optimistic that we will get some help from AMD this summer. Ok, I can wait, I guess. I can start by the OS, test flashrom with the propietary bios, etc. and handle coreboot proper later. How to choose socketed boards ? How can one know whether a card has socketed or soldered BIOS ROMs besides looking at it or some photos ? Should it be in the specs or manual ? (I don't trust myself with a soldering iron). This will usually be in the manual. Many boards are SPI flash now and you need an external programmer with a test clip to program them. This is an area we need to improve on the wiki. I had read something (either in coreboot wiki or from some link there) but I no longer find it. I thought SPI could be socketed or soldered. These are great goals. It sounds like you have a lot in common with the folks at the FSF. :) In goals, we have a lot in common, I'm just less active pursuing them. There are a couple AMD and Intel platforms that might meet your needs. Are there ? I've been looking at the supported mainboards and found few that I could buy currently in a shop and are relatively powerful. I'll look again. I expect more boards (like the 780/710) to be supported this summer if you are willing to wait. I am also hopeful that we see coreboot on systems available from vendors in the future. I've already wited quite a lot, and my current laptop is falling apart. So I may buy soon, but I may install coreboot later (I understand buying before getting support may be risky). I'd like to buy something with coreboot preinstalled, but that may be the next system I buy after whatever I get now. In your products page I've seen a couple of servers with coreboot I might get, but they're a bit expensive for what I was thinking. Thanks for your help. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Doubts about necessity of propietary parts in the firmware
Hello. First things first: thank you all for working in coreboot, yet another free software project I wouldn't think possible if you hadn't made it real. I've been reading the archives and browsing coreboot.org, but I have little clue about firmware so I still have doubts I would like to clear beforing buying/building my next computer VGA BIOS . Is it necessary ?. I've seen some reports of using coreboot with a propietary VGA BIOS, either run from the graphics card ROM or reaped from the motherboard propietary BIOS. Is this an intermediate state in development and it is eventually replaced with free code ? or we're not there (yet?). Can one live without any VGA BIOS ? Leaving it out means coreboot boots blindly but then (a deblobed) linux/X initializes the graphics hardware all right and you have display just like with VGA BIOS, only later in the boot process ? Or the GPU can't be used without the propietary VGA BIOS ? Can GRUB display a menu without VGA BIOS ? (SGA BIOS doesn't seem useful here, since I don't want to use a serial link forever) Btw, can GRUB show background images without VGA BIOS ? Do these answers depend on the GPU or northbridge ? Double graphics is a problem ? As far as I know the only modern desktop class chipsets supported by the manufacturer, are AMD RS780/SB700 , am I wrong ? (thanks, AMD!). I think all come with an ATI IGP , which requires blobs in the linux/X driver (AtomBIOS). I may be misinformed on AtomBIOS, but I think I don't want to use it. I've heard nouveau has just deblobed its driver, so I might add an Nvidia graphics card to it (at least while Open Graphics Project isn't ready for consumers). I'll try to buy one second hand, as lesser evil, since I dislike buying directly from vendors not supporting free software. Does having both the ATI IGP and the Nvidia card give any additional complication ? (besides it's going to be less tested than more usual setups). I wish Intel supported coreboot or radeonhd didn't use AtomBIOS (like it once was). Any AMD RS780/SB700 boards roadmap ? Any hints which AMD RS780/SB700 boards are going to be supported first ? (I'm using the suggestions I see on the mailing list, but I've heard of GSoC potential effort and I don't know if there're priorities already set for it) DDR3 coming soon ? I've heard optimism on DDR3 but I believe it's not yet supported by coreboot. Do you have any estimation on how long can it take or how much would it cost if someone was to pay for it ? (I don't think I can pay, it's just to quantify the effort). For now I'm planning to avoid DDR3 just in case. I'm not sure it's a huge performance benefit. How to choose socketed boards ? How can one know whether a card has socketed or soldered BIOS ROMs besides looking at it or some photos ? Should it be in the specs or manual ? (I don't trust myself with a soldering iron). TPM I don't like Treacherous Computing and the like so I would prefer to buy a motherboard without TPM. If I can get coreboot to run then the TPM may become harmless, but I still don't want to encourage vendors to put TPM in. The question is, are there security benefits if you control the firmware, like you would eventually increase security by using your own keys, or are the keys hardwired and unreplaceable so that the best you can hope for is to disable them? I don't really know how many boards without TPM are in the market, anyway. Thanks for reading so far and sorry for abusing this list thus. I'm going to include a little background now, but your answers can help me even without you reading further. I'm a professional programmer, and I studied Enginyeria Tècnica de Sistemes Informàtics before completing it to Enginyeria Informàtica (that's a 3 years degree in computer systems engineering, followed with the courses to turn it into a 5 years degree in computing). But I wasn't really interested in electronics and we didn't see anything about firmware. I did some exercises in 8086 and M68000 assembler, some C for operating systems and so on, but I don't have professional experience on it. Never wrote drivers or so on. I've worked more on web apps, web services and business applications. So I hope I can learn enough to test things without bricking my board, but not really to help develop anything. I used to buy laptops with intel IGP, because they had free drivers but now that my current laptop is getting older I looked for current hardware and found out about Intel Active Management Technology and DASH by AMD et al, and from that I discovered SMM. I used to think the BIOS was a small piece of code that was only used for booting and I could then forget it, but now I'm a bit more afraid of remote control with propietary BIOSes. I would like a computer with as little propietary software as possible, but yet powerful enough to compile quick enough, and ideally able to run a couple of distributions virtualized to test stuff. Something like 4-8 Gb of RAM (8 -16
