coreboot April 2014

coreboot@coreboot.org

42 participants
85 discussions

Re: [coreboot] Life hack #37: how to make a great touchpad
by mrnuke 21 Apr '14

21 Apr '14

On Monday, April 21, 2014 10:05:40 AM ron minnich wrote: > coreboot on chromebooks are very on topic. Track pad drivers for > Linux, or the trackpad firmware, or the trackpad vendor, or the > algorithms used, or the fact that you made this comment in such a way > that nobody from the trackpad group will see it, or that it's pretty > rude on top of that, not so much. > Rude? How so? I was just pointing out that having a good touchpad on a low- cost device is possible. It would have been rude to withhold this information ;) Alex

1 0

Re: [coreboot] Life hack #37: how to make a great touchpad
by mrnuke 21 Apr '14

21 Apr '14

On Monday, April 21, 2014 09:24:57 AM ron minnich wrote: > Oh, wait, what mailing list is this again? I thought it was the ~coreboot > list. > I thought Chromebooks were very on-topic, or did we drop them from our tree? Alex

2 1

Re: [coreboot] Life hack #37: how to make a great touchpad
by ron minnich 21 Apr '14

21 Apr '14

well, as long as we're off topic, the El Patron restaurant in Albuquerque was quite good. And it looks like the new Fit is a great car, although I still think the 2007 model year had more of a road feel. Oh, wait, what mailing list is this again? I thought it was the ~coreboot list. ron

1 0

can't find seabios
by jstkf2012＠126.com 21 Apr '14

21 Apr '14

Hi all,I can't find payload（seabios）.Below is some information about my code.Can?you?help me to see the problem?mainboard: google/rambilayout:Name?? ??? ??? ??? ??? ??? ??? ??? Offset?? ??? ??? ???Type?? ??? ??? ???? ??Size?cmos_layout.bin?? ??? ??? ?0x300000?? ???cmos_layout?? ??? ???1164?pci8086,0f31.rom ? ? ? 0x3004c0 ? ? optionrom ? ? ? ?65536 fallback/romstage ? ? ?0x310500 ? ? stage ? ? ? ? ? ?22813 fallback/coreboot_ram ?0x315e80 ? ? stage ? ? ? ? ? ?62692 fallback/payload ? ? ? 0x3253c0 ? ? payload ? ? ? ? ?52933 config?? ??? ??? ??? ??? ??? ??? ?0x3322c0 ? ? raw ? ? ? ? ? ? ?3998?(empty)?? ??? ??? ??? ??? ??? ? ?0x3332c0 ? ? null ? ? ? ? ? ? 117976?cpu_microcode_blob.bin 0x34ffc0 ? ?microcode ? ? ? ? 104512 (empty)?? ??? ??? ??? ??? ??? ???0x369840 ? ? null?? ??? ??? ??? ??? ???354136?fsp.bin?? ??? ??? ??? ??? ??? ???0x3bffc0 ? ?(unknown) ? ? ? ? 229376?(empty) ?? ??? ??? ??? ??? ??? ??0x3f8000 ? ?null?? ??? ??? ??? ??? ???31832?log：Loading segment from rom address 0xfff253f8 code (compression=1) New segment dstaddr 0xe6898 memsize 0x19768 srcaddr 0xfff25430 filesize 0xce8d (cleaned up) New segment addr 0xe6898 size 0x19768 offset 0xfff25430 filesize 0xce8d Loading segment from rom address 0xfff25414 Entry Point 0x000fc79f Could not find a bounce buffer... Could not load payload .

1 0

[RFC] New patch to review for coreboot: a61a8fe util/board_status: Use capture and not commit time
by Paul Menzel 20 Apr '14

20 Apr '14

Dear coreboot folks, just a heads-up that I sent the following patch set touch board status’ directory structure for review. Am Samstag, den 19.04.2014, 22:27 +0200 schrieb Paul Menzel: > Paul Menzel (paulepanter(a)users.sourceforge.net) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/5553 > > -gerrit > > commit a61a8fedadf418fc380743844572c0d9ea0f6eed > Author: Paul Menzel <paulepanter(a)users.sourceforge.net> > Date: Sat Apr 19 21:31:27 2014 +0200 > > util/board_status: Use capture and not commit time > > Currently the directory structure is > > <vendor>/<board>/<revision>/<timestamp> > > where the time stamp is the commit date. This does not allow to upload > results for the same commit and same board with different configuration. > The hardware could differ, for example the used processor, or the > configuration of coreboot or the used payload or its configuration. > > Also it is theoretically possible, though not very easy to achieve with > the current Gerrit workflow, that two commits have the same commit date. > > So instead of using the date of the commit simply use the date of > running the script `board_status.sh`. > > <vendor>/<board>/<revision>/<time_now> > > In theory that could still give collisions, but the chances of two > people having the same board running coreboot build from the same commit > and running `board_status.sh` at the same time are very low. > > Getting the current time is not easy, as the interface of `date` is not > standardized, though `date -u` probably should work the same. As > `getrevision.sh` already takes care of the formatting, pass the > non-tracked file `/bin/true` to `getrevision.sh`, which causes it to > return the current time properly formatted. Get rid of the resulting > warning > > Warning: Path "/bin/true" is not under version control. > > by removing the line from `getrevision.sh`. > > Change-Id: Id92a4b660e910b524f15297472ff570ef797039e > Signed-off-by: Paul Menzel <paulepanter(a)users.sourceforge.net> > --- > util/board_status/board_status.sh | 7 ++++--- > util/board_status/getrevision.sh | 3 --- > 2 files changed, 4 insertions(+), 6 deletions(-) > > diff --git a/util/board_status/board_status.sh b/util/board_status/board_status.sh > index 3cff231..19c69d1 100644 > --- a/util/board_status/board_status.sh > +++ b/util/board_status/board_status.sh > @@ -141,7 +141,7 @@ fi > tmpdir=$(mktemp -d) > > # Obtain board and revision info to form the directory structure: > -# <vendor>/<board>/<revision>/<timestamp> > +# <vendor>/<board>/<revision>/<time_now> > cbfstool_cmd="util/cbfstool/cbfstool" > test_cmd $LOCAL "$cbfstool_cmd" > $cbfstool_cmd build/coreboot.rom extract -n config -f ${tmpdir}/config.txt > @@ -153,8 +153,9 @@ getrevision="util/board_status/getrevision.sh" > test_cmd $LOCAL $getrevision > tagged_version=$($getrevision -T) > timestamp=$($getrevision -t) > +time_now=$($getrevision -t /bin/true) That is an ugly hack, which lead me to remove the warning in `getrevision.sh`. Should I just use `date -u` and format that somehow? Any ideas? Should the time stamp of the commit date of the commit still be put into `revision.txt`? > -results="${vendor}/${mainboard}/${tagged_version}/${timestamp}" > +results="${vendor}/${mainboard}/${tagged_version}/${time_now}" > > echo "Temporarily placing output in ${tmpdir}/${results}" > mkdir -p "${tmpdir}/${results}" > @@ -202,7 +203,7 @@ if [ $UPLOAD_RESULTS -eq 1 ]; then > > echo "Uploading results" > git add "${vendor}" > - git commit -a -m "${mainboard_dir}/${tagged_version}/${timestamp}" > + git commit -a -m "${mainboard_dir}/${tagged_version}/${time_now}" > git push origin > > # Results have been uploaded so it's pointless to keep the > diff --git a/util/board_status/getrevision.sh b/util/board_status/getrevision.sh > index 0a6b6c6..bdd4748 100755 > --- a/util/board_status/getrevision.sh > +++ b/util/board_status/getrevision.sh > @@ -233,9 +233,6 @@ main() { > if [ -z "$query_path" ] ; then > query_path=. > fi > - if ! is_file_tracked "$query_path" ; then > - echo "Warning: Path \"${query_path}\" is not under version control.">&2 > - fi > if [ -z "$action" ] ; then > show_help > echo "Error: No actions specified" Thanks, Paul

1 0

pcengines/apu status
by Anthony Martin 19 Apr '14

19 Apr '14

Does anyone on this list know if there are plans to upstream the work that SAGE did for the new APU mainboard from PCEngines? http://www.pcengines.ch/apu.htm Thanks, Anthony

2 1

Re: [coreboot] Bug in your code
by ron minnich 18 Apr '14

18 Apr '14

Please see http://review.coreboot.org/#/c/5544/ and I appreciate your patience. ron On Fri, Apr 18, 2014 at 9:08 AM, WANG FEI <wangfei.jimei(a)gmail.com> wrote: > The first option to change makemagic('B', 'S', 'S', ' ') of > PAYLOAD_SEGMENT_BSS in util/cbfstool/cbfs.h would be a better solution. > > > On Fri, Apr 18, 2014 at 4:52 PM, Aaron Durbin <adurbin(a)chromium.org> wrote: >> >> On Fri, Apr 18, 2014 at 9:49 AM, ron minnich <rminnich(a)gmail.com> wrote: >> > Can somebody give me a sanity check? I can't see the error with the >> > macro. >> > I won't say too much here -- just take a look. I'm not convinced the >> > code is wrong. >> >> >> http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/include/cbfs_… >> >> shows >> >> #define PAYLOAD_SEGMENT_CODE 0x45444F43 >> #define PAYLOAD_SEGMENT_DATA 0x41544144 >> #define PAYLOAD_SEGMENT_BSS 0x20535342 >> #define PAYLOAD_SEGMENT_PARAMS 0x41524150 >> #define PAYLOAD_SEGMENT_ENTRY 0x52544E45 >> >> and >> >> http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/lib/selfboot.… >> >> does no endianness correction. The segment->type is taken verbatim >> what is in cbfs. >> >> #define makemagic(b3, b2, b1, b0)\ >> (((b3)<<24) | ((b2) << 16) | ((b1) << 8) | (b0)) >> >> #define PAYLOAD_SEGMENT_CODE makemagic('C', 'O', 'D', 'E') >> #define PAYLOAD_SEGMENT_DATA makemagic('D', 'A', 'T', 'A') >> #define PAYLOAD_SEGMENT_BSS makemagic(' ', 'B', 'S', 'S') >> #define PAYLOAD_SEGMENT_PARAMS makemagic('P', 'A', 'R', 'A') >> #define PAYLOAD_SEGMENT_ENTRY makemagic('E', 'N', 'T', 'R') >> >> I would see the following result for all host cbfstool compilations: >> >> 0x434F4445 >> 0x44415441 >> 0x20425353 >> 0x50415241 >> 0x454E5452 >> >> But we xdr to big endian... so one needs to make the >> src/include/cbfs_core.h be architecture endian aware which it isn't. >> >> For the x86 case: >> >> makemagic('B', 'S', 'S', ' ') would make the xdr.be_put32 yield >> 0x20535342 when a little endian machine read the 32-bit word from a >> big endian serialization. >> >> The real question is what are the payload magic numbers and what >> should the encoding be? If they are serialized as big endian then the >> runtime needs an equivalent makemagic and be2host() to do the proper >> comparison. Having the runtime code be compiled as a straight up >> define is not correct for every machine because the underlying >> endinanness could be different. >> >> I think people are getting hung up on strings when the code is dealing >> w/ 32-bit values. >> >> 1. change makemagic('B', 'S', 'S', ' ') for PAYLOAD_SEGMENT_BSS that >> should fix little endian target machines >> 2. fix the runtime in coreboot to match cbfsutil where it sucks out >> the data as big endian and compares against the correct value. >> >> >> >> > >> > thanks >> > >> > ron >> > >> > On Fri, Apr 18, 2014 at 7:39 AM, WANG FEI <wangfei.jimei(a)gmail.com> >> > wrote: >> >> Ronald, >> >> >> >> I just noticed a bug in your code, I've added the comment to coreboot >> >> review >> >> syste, but I'm not farmilar with this system, not sure if it will send >> >> you a >> >> notice mail automatically, so I just send you a mail to inform you >> >> this. >> >> >> >> Here is the link of comment, >> >> http://review.coreboot.org/#/c/5098/ >> >> >> >> -Fei >> > >> > -- >> > coreboot mailing list: coreboot(a)coreboot.org >> > http://www.coreboot.org/mailman/listinfo/coreboot > >

1 0

Re: [coreboot] Bug in your code
by Aaron Durbin 18 Apr '14

18 Apr '14

On Fri, Apr 18, 2014 at 11:08 AM, WANG FEI <wangfei.jimei(a)gmail.com> wrote: > The first option to change makemagic('B', 'S', 'S', ' ') of > PAYLOAD_SEGMENT_BSS in util/cbfstool/cbfs.h would be a better solution. > It wasn't an either or proposition. The #2 piece is to fix big endian machines that are inherently broken with the way the current code is written. #1 definitely fixes your problem, though. > > On Fri, Apr 18, 2014 at 4:52 PM, Aaron Durbin <adurbin(a)chromium.org> wrote: >> >> On Fri, Apr 18, 2014 at 9:49 AM, ron minnich <rminnich(a)gmail.com> wrote: >> > Can somebody give me a sanity check? I can't see the error with the >> > macro. >> > I won't say too much here -- just take a look. I'm not convinced the >> > code is wrong. >> >> >> http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/include/cbfs_… >> >> shows >> >> #define PAYLOAD_SEGMENT_CODE 0x45444F43 >> #define PAYLOAD_SEGMENT_DATA 0x41544144 >> #define PAYLOAD_SEGMENT_BSS 0x20535342 >> #define PAYLOAD_SEGMENT_PARAMS 0x41524150 >> #define PAYLOAD_SEGMENT_ENTRY 0x52544E45 >> >> and >> >> http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/lib/selfboot.… >> >> does no endianness correction. The segment->type is taken verbatim >> what is in cbfs. >> >> #define makemagic(b3, b2, b1, b0)\ >> (((b3)<<24) | ((b2) << 16) | ((b1) << 8) | (b0)) >> >> #define PAYLOAD_SEGMENT_CODE makemagic('C', 'O', 'D', 'E') >> #define PAYLOAD_SEGMENT_DATA makemagic('D', 'A', 'T', 'A') >> #define PAYLOAD_SEGMENT_BSS makemagic(' ', 'B', 'S', 'S') >> #define PAYLOAD_SEGMENT_PARAMS makemagic('P', 'A', 'R', 'A') >> #define PAYLOAD_SEGMENT_ENTRY makemagic('E', 'N', 'T', 'R') >> >> I would see the following result for all host cbfstool compilations: >> >> 0x434F4445 >> 0x44415441 >> 0x20425353 >> 0x50415241 >> 0x454E5452 >> >> But we xdr to big endian... so one needs to make the >> src/include/cbfs_core.h be architecture endian aware which it isn't. >> >> For the x86 case: >> >> makemagic('B', 'S', 'S', ' ') would make the xdr.be_put32 yield >> 0x20535342 when a little endian machine read the 32-bit word from a >> big endian serialization. >> >> The real question is what are the payload magic numbers and what >> should the encoding be? If they are serialized as big endian then the >> runtime needs an equivalent makemagic and be2host() to do the proper >> comparison. Having the runtime code be compiled as a straight up >> define is not correct for every machine because the underlying >> endinanness could be different. >> >> I think people are getting hung up on strings when the code is dealing >> w/ 32-bit values. >> >> 1. change makemagic('B', 'S', 'S', ' ') for PAYLOAD_SEGMENT_BSS that >> should fix little endian target machines >> 2. fix the runtime in coreboot to match cbfsutil where it sucks out >> the data as big endian and compares against the correct value. >> >> >> >> > >> > thanks >> > >> > ron >> > >> > On Fri, Apr 18, 2014 at 7:39 AM, WANG FEI <wangfei.jimei(a)gmail.com> >> > wrote: >> >> Ronald, >> >> >> >> I just noticed a bug in your code, I've added the comment to coreboot >> >> review >> >> syste, but I'm not farmilar with this system, not sure if it will send >> >> you a >> >> notice mail automatically, so I just send you a mail to inform you >> >> this. >> >> >> >> Here is the link of comment, >> >> http://review.coreboot.org/#/c/5098/ >> >> >> >> -Fei >> > >> > -- >> > coreboot mailing list: coreboot(a)coreboot.org >> > http://www.coreboot.org/mailman/listinfo/coreboot > >

1 0

Re: [coreboot] Bug in your code
by WANG FEI 18 Apr '14

18 Apr '14

The first option to change makemagic('B', 'S', 'S', ' ') of PAYLOAD_SEGMENT_BSS in util/cbfstool/cbfs.h would be a better solution. On Fri, Apr 18, 2014 at 4:52 PM, Aaron Durbin <adurbin(a)chromium.org> wrote: > On Fri, Apr 18, 2014 at 9:49 AM, ron minnich <rminnich(a)gmail.com> wrote: > > Can somebody give me a sanity check? I can't see the error with the > macro. > > I won't say too much here -- just take a look. I'm not convinced the > > code is wrong. > > > http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/include/cbfs_… > > shows > > #define PAYLOAD_SEGMENT_CODE 0x45444F43 > #define PAYLOAD_SEGMENT_DATA 0x41544144 > #define PAYLOAD_SEGMENT_BSS 0x20535342 > #define PAYLOAD_SEGMENT_PARAMS 0x41524150 > #define PAYLOAD_SEGMENT_ENTRY 0x52544E45 > > and > > http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/lib/selfboot.… > > does no endianness correction. The segment->type is taken verbatim > what is in cbfs. > > #define makemagic(b3, b2, b1, b0)\ > (((b3)<<24) | ((b2) << 16) | ((b1) << 8) | (b0)) > > #define PAYLOAD_SEGMENT_CODE makemagic('C', 'O', 'D', 'E') > #define PAYLOAD_SEGMENT_DATA makemagic('D', 'A', 'T', 'A') > #define PAYLOAD_SEGMENT_BSS makemagic(' ', 'B', 'S', 'S') > #define PAYLOAD_SEGMENT_PARAMS makemagic('P', 'A', 'R', 'A') > #define PAYLOAD_SEGMENT_ENTRY makemagic('E', 'N', 'T', 'R') > > I would see the following result for all host cbfstool compilations: > > 0x434F4445 > 0x44415441 > 0x20425353 > 0x50415241 > 0x454E5452 > > But we xdr to big endian... so one needs to make the > src/include/cbfs_core.h be architecture endian aware which it isn't. > > For the x86 case: > > makemagic('B', 'S', 'S', ' ') would make the xdr.be_put32 yield > 0x20535342 when a little endian machine read the 32-bit word from a > big endian serialization. > > The real question is what are the payload magic numbers and what > should the encoding be? If they are serialized as big endian then the > runtime needs an equivalent makemagic and be2host() to do the proper > comparison. Having the runtime code be compiled as a straight up > define is not correct for every machine because the underlying > endinanness could be different. > > I think people are getting hung up on strings when the code is dealing > w/ 32-bit values. > > 1. change makemagic('B', 'S', 'S', ' ') for PAYLOAD_SEGMENT_BSS that > should fix little endian target machines > 2. fix the runtime in coreboot to match cbfsutil where it sucks out > the data as big endian and compares against the correct value. > > > > > > > thanks > > > > ron > > > > On Fri, Apr 18, 2014 at 7:39 AM, WANG FEI <wangfei.jimei(a)gmail.com> > wrote: > >> Ronald, > >> > >> I just noticed a bug in your code, I've added the comment to coreboot > review > >> syste, but I'm not farmilar with this system, not sure if it will send > you a > >> notice mail automatically, so I just send you a mail to inform you this. > >> > >> Here is the link of comment, > >> http://review.coreboot.org/#/c/5098/ > >> > >> -Fei > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > http://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Bug in your code
by Aaron Durbin 18 Apr '14

18 Apr '14

On Fri, Apr 18, 2014 at 9:49 AM, ron minnich <rminnich(a)gmail.com> wrote: > Can somebody give me a sanity check? I can't see the error with the macro. > I won't say too much here -- just take a look. I'm not convinced the > code is wrong. http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/include/cbfs_… shows #define PAYLOAD_SEGMENT_CODE 0x45444F43 #define PAYLOAD_SEGMENT_DATA 0x41544144 #define PAYLOAD_SEGMENT_BSS 0x20535342 #define PAYLOAD_SEGMENT_PARAMS 0x41524150 #define PAYLOAD_SEGMENT_ENTRY 0x52544E45 and http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/lib/selfboot.… does no endianness correction. The segment->type is taken verbatim what is in cbfs. #define makemagic(b3, b2, b1, b0)\ (((b3)<<24) | ((b2) << 16) | ((b1) << 8) | (b0)) #define PAYLOAD_SEGMENT_CODE makemagic('C', 'O', 'D', 'E') #define PAYLOAD_SEGMENT_DATA makemagic('D', 'A', 'T', 'A') #define PAYLOAD_SEGMENT_BSS makemagic(' ', 'B', 'S', 'S') #define PAYLOAD_SEGMENT_PARAMS makemagic('P', 'A', 'R', 'A') #define PAYLOAD_SEGMENT_ENTRY makemagic('E', 'N', 'T', 'R') I would see the following result for all host cbfstool compilations: 0x434F4445 0x44415441 0x20425353 0x50415241 0x454E5452 But we xdr to big endian... so one needs to make the src/include/cbfs_core.h be architecture endian aware which it isn't. For the x86 case: makemagic('B', 'S', 'S', ' ') would make the xdr.be_put32 yield 0x20535342 when a little endian machine read the 32-bit word from a big endian serialization. The real question is what are the payload magic numbers and what should the encoding be? If they are serialized as big endian then the runtime needs an equivalent makemagic and be2host() to do the proper comparison. Having the runtime code be compiled as a straight up define is not correct for every machine because the underlying endinanness could be different. I think people are getting hung up on strings when the code is dealing w/ 32-bit values. 1. change makemagic('B', 'S', 'S', ' ') for PAYLOAD_SEGMENT_BSS that should fix little endian target machines 2. fix the runtime in coreboot to match cbfsutil where it sucks out the data as big endian and compares against the correct value. > > thanks > > ron > > On Fri, Apr 18, 2014 at 7:39 AM, WANG FEI <wangfei.jimei(a)gmail.com> wrote: >> Ronald, >> >> I just noticed a bug in your code, I've added the comment to coreboot review >> syste, but I'm not farmilar with this system, not sure if it will send you a >> notice mail automatically, so I just send you a mail to inform you this. >> >> Here is the link of comment, >> http://review.coreboot.org/#/c/5098/ >> >> -Fei > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot April 2014