flashrom July 2013

flashrom@flashrom.org

31 participants
142 discussions

Re: [flashrom] [PATCH 02/10] Add support for AMD Geode's MSR on OpenBSD.
by Carl-Daniel Hailfinger 13 Jul '13

13 Jul '13

Am 10.07.2013 21:17 schrieb Stefan Tauner: > Previously the default implementation was used, which always failed. > On other systems than the Geode the code is not equal to that anymore, > but should not explode because setup_cpu_msr() returns an error and > therefore no other MSR functions should be called. > > Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> > Tested-by Leonardo Guardati <leonardo(a)guardati.it> > Acked-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> > > Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> Please kill one of your signoffs. I like the simplification of the previous #ifdef mess. Cosmetic suggestions (commit is OK without them as well): Move the libpayload setup_cpu_msr/cleanup_cpu_msr from the top of the file down to the block right after libpayload_wrmsr. This has the advantage of making the msr setup code for libpayload dependent on x86 instead of having it enabled for all architectures. Add a comment to the OSX MSR functions which mentions that rdmsr/wrmsr are provided by DirectHW. Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Regards, Carl-Daniel -- http://www.hailfinger.org/

2 1

[commit] r1696 - trunk
by repository service 13 Jul '13

13 Jul '13

Author: stefanct Date: Sat Jul 13 23:18:32 2013 New Revision: 1696 URL: http://flashrom.org/trac/flashrom/changeset/1696 Log: Add support for AMD Geode's MSR on OpenBSD. Previously the default implementation was used, which always failed. On other systems than the Geode the code is not equal to that anymore, but should not explode because setup_cpu_msr() returns an error and therefore no other MSR functions should be called. Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> Tested-by Leonardo Guardati <leonardo(a)guardati.it> Acked-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Modified: trunk/physmap.c Modified: trunk/physmap.c ============================================================================== --- trunk/physmap.c Sat Jul 13 22:55:33 2013 (r1695) +++ trunk/physmap.c Sat Jul 13 23:18:32 2013 (r1696) @@ -282,6 +282,8 @@ PHYSMAP_RO); } +/* MSR abstraction implementations for Linux, OpenBSD, FreeBSD/Dragonfly, OSX, libpayload + * and a non-working default implemenation on the bottom. See also hwaccess.h for some (re)declarations. */ #if defined(__i386__) || defined(__x86_64__) #ifdef __linux__ @@ -381,8 +383,83 @@ /* Clear MSR file descriptor. */ fd_msr = -1; } -#else -#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) || defined(__DragonFly__) +#elif defined(__OpenBSD__) /* This does only work for certain AMD Geode LX systems see amdmsr(4). */ +#include <sys/ioctl.h> +#include <machine/amdmsr.h> + +static int fd_msr = -1; + +msr_t rdmsr(int addr) +{ + struct amdmsr_req args; + + msr_t msr = { 0xffffffff, 0xffffffff }; + + args.addr = (uint32_t)addr; + + if (ioctl(fd_msr, RDMSR, &args) < 0) { + msg_perr("Error while executing RDMSR ioctl: %s\n", strerror(errno)); + close(fd_msr); + exit(1); + } + + msr.lo = args.val & 0xffffffff; + msr.hi = args.val >> 32; + + return msr; +} + +int wrmsr(int addr, msr_t msr) +{ + struct amdmsr_req args; + + args.addr = addr; + args.val = (((uint64_t)msr.hi) << 32) | msr.lo; + + if (ioctl(fd_msr, WRMSR, &args) < 0) { + msg_perr("Error while executing WRMSR ioctl: %s\n", strerror(errno)); + close(fd_msr); + exit(1); + } + + return 0; +} + +int setup_cpu_msr(int cpu) +{ + char msrfilename[64]; + memset(msrfilename, 0, sizeof(msrfilename)); + snprintf(msrfilename, sizeof(msrfilename), "/dev/amdmsr"); + + if (fd_msr != -1) { + msg_pinfo("MSR was already initialized\n"); + return -1; + } + + fd_msr = open(msrfilename, O_RDWR); + + if (fd_msr < 0) { + msg_perr("Error while opening %s: %s\n", msrfilename, strerror(errno)); + return -1; + } + + return 0; +} + +void cleanup_cpu_msr(void) +{ + if (fd_msr == -1) { + msg_pinfo("No MSR initialized.\n"); + return; + } + + close(fd_msr); + + /* Clear MSR file descriptor. */ + fd_msr = -1; +} + +#elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__) || defined(__DragonFly__) #include <sys/ioctl.h> typedef struct { @@ -465,9 +542,8 @@ fd_msr = -1; } -#else - -#if defined(__MACH__) && defined(__APPLE__) +#elif defined(__MACH__) && defined(__APPLE__) +/* rdmsr() and wrmsr() are provided by DirectHW which needs neither setup nor cleanup. */ int setup_cpu_msr(int cpu) { // Always succeed for now @@ -494,6 +570,7 @@ return 0; } #else +/* default MSR implementation */ msr_t rdmsr(int addr) { msr_t ret = { 0xffffffff, 0xffffffff }; @@ -516,9 +593,7 @@ { // Nothing, yet. } -#endif -#endif -#endif -#else +#endif // OS switches for MSR code +#else // x86 /* Does MSR exist on non-x86 architectures? */ -#endif +#endif // arch switches for MSR code

1 0

Re: [flashrom] [PATCH 01/10] Fix hwaccess (again).
by Carl-Daniel Hailfinger 13 Jul '13

13 Jul '13

Am 10.07.2013 21:17 schrieb Stefan Tauner: > Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> This changes the behaviour for FreeBSD (and derivatives). Is this what you wanted? If yes, please change the commit message to Fix hwaccess for FreeBSD Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Regards, Carl-Daniel -- http://www.hailfinger.org/

2 1

[commit] r1695 - trunk
by repository service 13 Jul '13

13 Jul '13

Author: stefanct Date: Sat Jul 13 22:55:33 2013 New Revision: 1695 URL: http://flashrom.org/trac/flashrom/changeset/1695 Log: Fix hwaccess (again). I completely forgot about NetBSD in r1638 which was broken since then. Also, on OpenBSD use iopl again and refine the warning in case we have insufficient privileges. Thanks to Jonathan A. Kollasch for his help in getting the details right. Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Modified: trunk/hwaccess.c Modified: trunk/hwaccess.c ============================================================================== --- trunk/hwaccess.c Thu Jul 11 15:48:52 2013 (r1694) +++ trunk/hwaccess.c Sat Jul 13 22:55:33 2013 (r1695) @@ -26,10 +26,9 @@ #error Unknown architecture #endif -#define IS_BSD (defined(__FreeBSD__) || defined(__FreeBSD_kernel__) || defined(__DragonFly__) || defined(__OpenBSD__)) #define IS_LINUX (defined(__gnu_linux__) || defined(__linux__)) #define IS_MACOSX (defined(__APPLE__) && defined(__MACH__)) -#if !(IS_BSD || IS_LINUX || IS_MACOSX || defined(__DJGPP__) || defined(__LIBPAYLOAD__) || defined(__sun)) +#if !(IS_LINUX || IS_MACOSX || defined(__NetBSD__) || defined(__OpenBSD__) || defined(__FreeBSD__) || defined(__FreeBSD_kernel__) || defined(__DragonFly__) || defined(__DJGPP__) || defined(__LIBPAYLOAD__) || defined(__sun)) #error "Unknown operating system" #endif @@ -47,7 +46,10 @@ #include "flash.h" #include "hwaccess.h" -#if IS_X86 && IS_BSD +#define USE_IOPL (IS_LINUX || IS_MACOSX || defined(__NetBSD__) || defined(__OpenBSD__)) +#define USE_DEV_IO (defined(__FreeBSD__) || defined(__FreeBSD_kernel__) || defined(__DragonFly__)) + +#if IS_X86 && USE_DEV_IO int io_fd; #endif @@ -71,9 +73,9 @@ { #if defined (__sun) sysi86(SI86V86, V86SC_IOPL, 0); -#elif IS_BSD +#elif USE_DEV_IO close(io_fd); -#elif IS_LINUX || IS_MACOSX +#elif USE_IOPL iopl(0); #endif return 0; @@ -86,16 +88,19 @@ #if IS_X86 && !(defined(__DJGPP__) || defined(__LIBPAYLOAD__)) #if defined (__sun) if (sysi86(SI86V86, V86SC_IOPL, PS_IOPL) != 0) { -#elif IS_BSD +#elif USE_DEV_IO if ((io_fd = open("/dev/io", O_RDWR)) < 0) { -#elif IS_LINUX || IS_MACOSX +#elif USE_IOPL if (iopl(3) != 0) { #endif - msg_perr("ERROR: Could not get I/O privileges (%s).\n" - "You need to be root.\n", strerror(errno)); + msg_perr("ERROR: Could not get I/O privileges (%s).\n", strerror(errno)); + msg_perr("You need to be root.\n"); #if defined (__OpenBSD__) - msg_perr("Please set securelevel=-1 in /etc/rc.securelevel and reboot, or reboot into \n"); - msg_perr("single user mode.\n"); + msg_perr("If you are root already please set securelevel=-1 in /etc/rc.securelevel and\n" + "reboot, or reboot into single user mode.\n"); +#elif defined(__NetBSD__) + msg_perr("If you are root already please reboot into single user mode or make sure\n" + "that your kernel configuration has the option INSECURE enabled.\n"); #endif return 1; } else {

1 0

Re: [flashrom] Want to donate 110 Euro to flashrom.org thru paypal if can get 45 minute help with flashing BIOS
by Stefan Tauner 12 Jul '13

12 Jul '13

On Fri, 12 Jul 2013 10:15:36 +0700 jakob neubert <jakobneubert(a)fastmail.fm> wrote: > Well, am a non-programmer so just trying to figure out what to write > correctly in the terminal window is very difficult. Spent 3 hours on > that yesterday. > > Can't make it save the BIOS - and - can't make it erase BIOS either. > When doing that then it says that write protected. > > When trying to flash BIOS then it says that the motehrbnoard is not > supported - but, its a common mother board with common parts on it from > Realtek, Broadcom and so on. You are describing the things you tried and their outcome very sketchy. You have not even mentioned if you have used flashrom or the vendor tools(!). We can not diagnose anything that way. We need to know exactly what commands you used and what the response was. If you have flashrom installed already send us the log file generated by "flashrom -p internal -o flashrom.log" please. That would be a good start. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

Re: [flashrom] [RFC] Layout *file* handling...
by Stefan Tauner 12 Jul '13

12 Jul '13

On Thu, 11 Jul 2013 12:31:55 -0700 David Hendricks <dhendrix(a)google.com> wrote: > On Thu, Jul 11, 2013 at 9:42 AM, Stefan Tauner < > stefan.tauner(a)student.tuwien.ac.at> wrote: > > > > - Default inclusion status. It would be nice to be able to mark some > > regions as to be included by default so that one does not even need > > to use -i. (no idea about syntax yet) > > > > This one could get complicated... Maybe for the layout 2.0 you can add a > column to specify include options like "always" or "never". That could be > made into a comma-separated list with other region attributes (TBD). Maybe we should think more broadly about what we want to achieve. The layout file as it is and the features I enumerated are very much focused on describing attributes of address ranges. That is fine if it is our main concern, but I am not sure it is. Eventually we want to make it easier to describe access patterns to a memory device, so maybe a more imperative approach would be better that describes what flashrom should do. We would end up with a configuration file that would be able to replace everything we can declare on the command line now + current layout files + your write protection commands + a schedule of what of the above should be used/done when. The more I think about it the more I think this is wrong and way more easily handled by real scipting languages together with a libflashrom binding. :) > > - Includes of other layout files (include .*) > > > > Interesting! I like that idea. Do you have use cases for that? We dont want to implement features just because they sound nice to have :) > - Some kind of priority if one selects overlapping regions. > > Interesting... Not sure I like it though. It seems too easy to botch this > IMO. Yes indeed. :) These ideas are a food for thought and nothing else. I would like to get more feedback from the potential users regarding (these) features and not invent stuff no one actually needs. As Stefan wrote already the normal work flow is to get a complete image out of the build system... -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

[RFC] Layout handling...
by Carl-Daniel Hailfinger 12 Jul '13

12 Jul '13

Hi, before we change flashrom to work with current layout requirements, we should summarize the features we need/want, and then decide how to handle the individual layout regions internally. Terms: "write strategy" describes a combination of erase+write commands with a given block size, touching some blocks. "read protected" describes a region which can not be read. "write protected" describes a region which can not be written. "write once" describes a region which can be written exactly once in the chip lifetime. If you add a feature to the list, please give it a nickname so we know which feature people are referring to. Some of the features below might not be desirable, but I want to list them anyway so we can explicitly declare them as unsupported if needed. fullwrite-unrestricted: Write a chip-sized image, no special read/write restrictions of the chip, no layout file needs to be specified. Default write case right now. fullwrite-noread: Write a chip-sized image, reading anything from the chip is not possible. Many DVD writers fall in that category. No verification, violates our reliability guarantees. fullwrite-postread: Write a chip-sized image, reading anything from the chip is only possible after write. Chips which are read-locked until a full erase/write fall in that category. Do those exist as standalone flash chips or only integrated into processors? fullwrite-partialread: Write a chip-sized image, reading is only possible in some chip regions. Only partial verification, violates our reliability guarantees. fullwrite-partialwrite: Write a chip-sized image, but writing is only possible in some regions. This is obviously a conflict unless the image has the same contents as the chip in the write-protected regions and there is a possible write strategy for the whole image which does not touch the write-protected regions. Should flashrom always refuse this scenario, or only refuse it in case of conflicts? partialwrite-unrestricted: Write only parts of an image, the rest of the chip contents is kept, no special read/write restrictions. partialwrite-partialread: Write only parts of an image, the rest of the chip contents is kept, reading is only possible in some chip regions. If no read-protected regions are written and a suitable write strategy exists, should flashrom warn? If a read-protected region is written, should flashrom warn/refuse due to reliability requirements? partialwrite-partialwrite: Write only parts of an image, the rest of the chip contents is kept, writing is only possible in some chip regions. If no write-protected regions are written and a suitable write strategy exists, should flashrom warn? flashrom will refuse to write a write-protected region. fullread-unrestricted: Read the full chip, no special read restrictions of the chip. partialread-unrestricted: Read only parts of a chip, no special read restrictions of the chip. partialread-partialread: Read only parts of a chip, some regions are read-protected. flashrom should refuse to read any read-protected regions. partialread-imagefiller: If only parts of a chip are read and the read image has full chip size, what should be used as filler for unread regions? 0x00 or 0xff? partialread-layout-imagesize: If only parts of a chip are read, should the read image still have full chip size with all read regions filled in at the respective locations? partialread-layout-split: If only parts of a chip are read, should it be possible to write each region (or a combination thereof) to a separate image file, and would that mapping be specified in the layout file? partialwrite-layout-split: If only parts of a chip are written, should it be possible to collect each part of the new image from a separate image file, and would that mapping be specified in the layout file? readwrite-protection-time: Which read protection and write protection times exist? Temporary lock until unlock, temporary lock until chip soft reset, temporary lock until chip/programmer hard reset (powerdown or reset line), permanent eternal lock. readwrite-protection-type: Which read protection and write protection types exist? Programmer lock (e.g. Intel SPI), hardware chip lock (WP pin), software chip lock (chip command). readwrite-protection-interaction: How should we express this situation: A region is write-locked with a software chip lock, but to remove that software chip lock, a hardware chip lock has to be disabled first, then the software chip lock can be disabled. partialaccess-crash: Some regions in the chip are really off-limits and will cause an unrecoverable error (system crash) when accessed (read or write). That seems to be the case for some EC/flash interactions. Comments? Any forks of flashrom (e.g. chromium) which need infrastructure features not mentioned above? Regards, Carl-Daniel -- http://www.hailfinger.org/

5 12

Re: [flashrom] [RFC] Layout *file* handling...
by Stefan Reinauer 12 Jul '13

12 Jul '13

On 7/11/13 12:31 PM, David Hendricks wrote: > > in the cli) > > > +1. It's pretty silly to need to specify a ROM-sized file for "-w" > just to update a single region. > While this is true, ROM-sized files are typically what falls out of pretty much everyone's build system, so we should retain this option. Stefan

2 1

Re: [flashrom] Want to donate 110 Euro to flashrom.org thru paypal if can get 45 minute help with flashing BIOS
by Stefan Tauner 12 Jul '13

12 Jul '13

On Wed, 10 Jul 2013 17:22:24 +0700 jakob neubert <jakobneubert(a)fastmail.fm> wrote: > I am un-able to flash my computers with flashrom and have already been > using gparted, rescuecd, linuxmint, Ubuntu and so on. > > > > They are Acer aspire 4755G and Acer aspire v3-471g laptops (I7 CPU, 8 > GB ram). Please provide some verbose output and/or error messages, for example the complete output of flashrom -p internal -VV -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

Re: [flashrom] [RFC] Layout *file* handling...
by Stefan Tauner 11 Jul '13

11 Jul '13

On Thu, 11 Jul 2013 13:55:38 -0700 David Hendricks <dhendrix(a)google.com> wrote: > On Thu, Jul 11, 2013 at 1:12 PM, Stefan Tauner < > stefan.tauner(a)student.tuwien.ac.at> wrote: > > > On Thu, 11 Jul 2013 12:31:55 -0700 > > David Hendricks <dhendrix(a)google.com> wrote: > > > > > > - Default image names. For example one might want to always use me.bin > > > > for the ME region without the need to specify it all the time on the > > > > cli. (add the name after the region name, separated by : just like > > > > in the cli) > > > > > > > > > > +1. It's pretty silly to need to specify a ROM-sized file for "-w" just > > to > > > update a single region. > > > > That needs to be dealt otherwise. > > > Darn, I was hoping to rope you into doing work for me ;-) > > What i meant is that you specify in > > the layout file the image you would normally specify by -i > > regionname:filename. > > > > if there is no file name in the cli, look in the layout file. > > > So far so good. > > > > if there > > is none there either, use the one of the complete image (for the -w > > case, -r would be slightly different). > > > > So the behavior is the same as it is now? That is, the -w argument is the > complete ROM-sized file and flashrom will use the layout info to seek to > the correct offset in the file? It is the same regarding the rom-sized file... because that has absolutely nothing to do with the layout file per se. That solely depends on the CLI which is free to prepare the image otherwise (if that's not possible then it should be eventually). You talked about -w (etc.) no longer requiring an argument... that's where I would put the focus to solve the problem of requiring rom-sized images. If I'll beat you to implement that, you will notice it ;) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

← Newer
1
...
7
8
9
10
11
12
13
14
15
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom July 2013