Looking at cbmem -c output this seems to be where the 5 seconds is
being lost, but it's truncating the output. How can I stop cbmem from
truncating the output so I can see what's going on?
CBFS: CBFS_HEADER_ROM_ADDRESS: 0xf9d0/0x80
CBFS: CBFS location: 0x70~0x7ff9f0, align: 64
On Wed, Jul 31, 2013 at 10:00 AM, John Lewis jle...@johnlewis.ie wrote:
On 31/07/2013 15:33, Aaron Durbin wrote:
On Wed, Jul 31, 2013 at 9:24 AM, John Lewis jle...@johnlewis.ie wrote:
Hi all, Just want to confirm where we are in terms of things working or
not. The new system-agent binary
On Wed, Jul 31, 2013 at 10:18 AM, Aaron Durbin adur...@chromium.org wrote:
On Wed, Jul 31, 2013 at 10:00 AM, John Lewis jle...@johnlewis.ie wrote:
On 31/07/2013 15:33, Aaron Durbin wrote:
On Wed, Jul 31, 2013 at 9:24 AM, John Lewis jle...@johnlewis.ie wrote:
Hi all, Just want to confirm
On 31/07/2013 16:20, Aaron Durbin wrote:
On Wed, Jul 31, 2013 at 10:18 AM, Aaron Durbin adur...@chromium.org
wrote:
On Wed, Jul 31, 2013 at 10:00 AM, John Lewis jle...@johnlewis.ie
[4]
wrote:
On 31/07/2013 15:33, Aaron Durbin wrote:
On Wed, Jul 31, 2013 at 9:24 AM, John Lewis
On Wed, Jul 31, 2013 at 10:34 AM, John Lewis jle...@johnlewis.ie wrote:
On 31/07/2013 16:20, Aaron Durbin wrote:
On Wed, Jul 31, 2013 at 10:18 AM, Aaron Durbin adur...@chromium.org
wrote:
On Wed, Jul 31, 2013 at 10:00 AM, John Lewis jle...@johnlewis.ie [4]
wrote:
On 31/07/2013 15:33,
On 31/07/2013 16:43, Aaron Durbin wrote:
On Wed, Jul 31, 2013 at 10:34 AM, John Lewis jle...@johnlewis.ie
wrote:
On 31/07/2013 16:20, Aaron Durbin wrote:
On Wed, Jul 31, 2013 at 10:18 AM, Aaron Durbin
adur...@chromium.org
[5] wrote:
On Wed, Jul 31, 2013 at 10:00 AM, John Lewis
On Wed, Jul 31, 2013 at 10:50 AM, John Lewis jle...@johnlewis.ie wrote:
On 31/07/2013 16:43, Aaron Durbin wrote:
On Wed, Jul 31, 2013 at 10:34 AM, John Lewis jle...@johnlewis.ie wrote:
On 31/07/2013 16:20, Aaron Durbin wrote:
On Wed, Jul 31, 2013 at 10:18 AM, Aaron Durbin
On Wed, Jul 31, 2013 at 11:42 AM, John Lewis jle...@johnlewis.ie wrote:
On 31/07/2013 17:11, Aaron Durbin wrote:
On Wed, Jul 31, 2013 at 11:03 AM, John Lewis jle...@johnlewis.ie wrote:
On 31/07/2013 16:56, Aaron Durbin wrote:
On Wed, Jul 31, 2013 at 10:50 AM, John Lewis
On Wed, Jul 31, 2013 at 1:27 PM, John Lewis jle...@johnlewis.ie wrote:
On 31/07/2013 17:51, Aaron Durbin wrote:
On Wed, Jul 31, 2013 at 11:42 AM, John Lewis jle...@johnlewis.ie wrote:
On 31/07/2013 17:11, Aaron Durbin wrote:
On Wed, Jul 31, 2013 at 11:03 AM, John Lewis jle...@johnlewis.ie
On Wed, Jul 31, 2013 at 1:48 PM, John Lewis jle...@johnlewis.ie wrote:
On 31/07/2013 19:36, Aaron Durbin wrote:
On Wed, Jul 31, 2013 at 1:27 PM, John Lewis jle...@johnlewis.ie wrote:
On 31/07/2013 17:51, Aaron Durbin wrote:
On Wed, Jul 31, 2013 at 11:42 AM, John Lewis jle...@johnlewis.ie
Well, I could not make the combination of 3830 + 3831 work with lumpy,
see attached log.
Kyösti
On Mon, 2013-07-29 at 15:22 -0700, Duncan Laurie wrote:
Just checking to make sure it was still populated... Now we know it is the
internal memory that is the issue.
I suspect you may now be
Can you provide the full firmware log and dmesg? 'cbmem -l' should
give you the firmware log.
On Sun, Jul 28, 2013 at 7:47 AM, John Lewis jle...@johnlewis.ie wrote:
Guys, I have noticed that not all the 4 GB or RAM is showing, and I get this
message in the kernel:
[0.00] Memory:
Scratch that, found and compiled it in coreboot/util/cbmem. Doesn't
output very much though, assume I need to compile debugging and console
in.
On 29/07/2013 15:19, John Lewis wrote:
Where do I find/build cbmem binary?
Please find attached dmesg.
On 29/07/2013 14:43, Aaron Durbin wrote:
It's under the 'util' directory in the coreboot repository:
http://review.coreboot.org/gitweb?p=coreboot.git;a=tree;f=util/cbmem;h=14fbe6c462edf294e247e95616700cee7a6f46db;hb=refs/heads/master
From this:
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem
Also, later on in dbmem console output Available memory below 4GB:
1992M
On 29/07/2013 15:39, John Lewis wrote:
Right, here is cbmem console output, which was -c not -l. As you
can see, it says fairly early on it recognises 2GB not 4. It's not
exactly verbose about why. I also noticed later
On Mon, Jul 29, 2013 at 9:39 AM, John Lewis jle...@johnlewis.ie wrote:
Right, here is cbmem console output, which was -c not -l. As you can
Sorry about that. I was just going off of my memory which is clearly
not correct!
see, it says fairly early on it recognises 2GB not 4. It's not exactly
On Mon, 2013-07-29 at 15:19 +0100, John Lewis wrote:
Where do I find/build cbmem binary?
Please find attached dmesg.
Hi
I have same issue. Only about 2Gib of 4GiB installed shows. I had not
noticed this until You pointed this out. Looks like a problem with the
last entry coreboot creates in
Hi
Here is my cbmem -c output. And I can actually only see one DIMM with 2
GiB detected here, so you can probably forget about what I wrote about
e820..
Kyösti
cbmem -c
coreboot-4.0-4564-ga50e65a Sat Jul 13 00:27:46 EEST 2013 starting...
Setting up static southbridge registers... done.
Kyösti,
I'm not certain it's just the last entry of the e820. mrc is just
seeing 2GiB of ram and setting it up that way.
TOUUD 0x10060 TOLUD 0x7f20 TOM 0x8000
MEBASE 0x7f80
IGD decoded, subtracting 32M UMA and 2M GTT
TSEG base 0x7c80 size 8M
Available memory below 4GB: 1992M
On Wed, Jul 24, 2013 at 10:34 AM, Kyösti Mälkki kyosti.mal...@gmail.com wrote:
Ron _should_ have been aware of this. Actually, if you want my opinion,
he should have been nagging to Stefan to fix this for a month now, or
when the issue was first reported.
I should have been aware of all kinds
Did someone change the SPD eeprom address notation in pei_data from
7-bit to 8-bit addresses?
samsung/lumpy/romstage.c :
.spd_addresses = { 0x50, 0x00,0xf0,0x00 },
google/stout/romstage.c :
spd_addresses: { 0xA0, 0x00,0xA4,0x00 },
Kyösti
--
coreboot mailing list:
If one pulls the dimm out of the slot does the machine boot? I'm
curious if reading the dimm spd is working or using the on-board spd
memory is working. Based on what I am seeing I would expect the board
not to boot.
Let me know what you guys find.
-Aaron
On Mon, Jul 29, 2013 at 10:13 AM,
On Mon, Jul 29, 2013 at 10:22 AM, Kyösti Mälkki kyosti.mal...@gmail.com wrote:
Did someone change the SPD eeprom address notation in pei_data from
7-bit to 8-bit addresses?
samsung/lumpy/romstage.c :
.spd_addresses = { 0x50, 0x00,0xf0,0x00 },
google/stout/romstage.c :
On Mon, Jul 29, 2013 at 10:38 AM, John Lewis jle...@johnlewis.ie wrote:
My 550 won't boot without the DIMM in, so it sounds like it's not
recognising the embedded memory.
OK. That is a good data point. However, I don't know from what code
base that original wrapper was built from in order to
On 29/07/2013 16:47, Aaron Durbin wrote:
On Mon, Jul 29, 2013 at 10:38 AM, John Lewis jle...@johnlewis.ie
wrote:
My 550 won't boot without the DIMM in, so it sounds like it's not
recognising the embedded memory.
OK. That is a good data point. However, I don't know from what code
base that
* Aaron Durbin adur...@chromium.org [130724 17:16]:
A couple things to change:
CONFIG_CPU_ADDR_BITS=36
CONFIG_SPI_FLASH_NO_FAST_READ=y
I *don't* think this is causing you grief, but these are different
from the chromium repo.
Also, you .config shows a 4MiB cbfs, but that doesn't jive
On 29/07/2013 16:47, Aaron Durbin wrote:
On Mon, Jul 29, 2013 at 10:38 AM, John Lewis jle...@johnlewis.ie
wrote:
My 550 won't boot without the DIMM in, so it sounds like it's not
recognising the embedded memory.
OK. That is a good data point. However, I don't know from what code
base that
* Kyösti Mälkki kyosti.mal...@gmail.com [130729 17:22]:
Did someone change the SPD eeprom address notation in pei_data from
7-bit to 8-bit addresses?
samsung/lumpy/romstage.c :
.spd_addresses = { 0x50, 0x00,0xf0,0x00 },
google/stout/romstage.c :
spd_addresses: { 0xA0,
I'm just going to summarize our current situation:
1. HEAD does not work at all using the
3rdparty/northbridge/intel/sandybridge/systemagent-r6.bin
2. Reverting 1cc3416f5fb58883fdad7192856c258c01909fd7 and using
systemagent-sandybridge.bin boots, but it does not handle the
soldered-on memory.
On 29/07/2013 19:17, Aaron Durbin wrote:
I'm just going to summarize our current situation:
1. HEAD does not work at all using the
3rdparty/northbridge/intel/sandybridge/systemagent-r6.bin
2. Reverting 1cc3416f5fb58883fdad7192856c258c01909fd7 and using
systemagent-sandybridge.bin boots, but it
Lumpy should have 2GB of on-board memory and a DIMM slot that comes with a
2GB DIMM.
Coreboot seems to detect the on-board memory and finds the SPD binary for
it, any chance the DIMM slot is empty?
Memory Straps:
- memory capacity 2GB
- die revision 1
- vendor Samsung
CBFS: Looking for
So the DIMM slot happens to be empty/seated badly on both our Lumpy's? Don't
think so.
Mine acted like a brick with the SODIMM removed.
John.
Duncan Laurie dlau...@chromium.org wrote:
Lumpy should have 2GB of on-board memory and a DIMM slot that comes with a 2GB
DIMM.
Coreboot seems to
Unfortunately the input can depend on the systemagent binary. In this case
the sandybridge-only binary has a different SMBUS layer and the 7-bit
notation is correct. Now the systemagent code comes with its own driver
that uses 8-bit notation.
-duncan
On Mon, Jul 29, 2013 at 8:22 AM, Kyösti
Just checking to make sure it was still populated... Now we know it is the
internal memory that is the issue.
I suspect you may now be hitting the original issue that Stefan was trying
to fix with the systemagent binary changes (
http://review.coreboot.org/#/c/3568/) that were reverted to get
Have just tried both patches with a spanking new tree and resulted in a brick.
I will have a go with just 3831 tomorrow morning unless I'm told otherwise.
John.
Duncan Laurie dlau...@chromium.org wrote:
Just checking to make sure it was still populated... Now we know it is the
internal
Guys, I have noticed that not all the 4 GB or RAM is showing, and I get
this message in the kernel:
[0.00] Memory: 1914260k/4200448k available (6486k kernel code,
2160136k absent, 126052k reserved, 6780k data, 1412k init)
Any idea what the problem is (mrc.bin), and what I might do to
Am 24.07.2013 00:45, schrieb John Lewis:
Name Offset Type Size
[...]
0x77f580 null 2584 mrc.cache 0x77ffc0
(unknown)0
Quick note: This is wrong (size 0). Most likely we need to change the
build system magic some more that
On Tue, Jul 23, 2013 at 9:44 PM, Peter Stuge pe...@stuge.se wrote:
I guess eliminating that deployment/release process completely is the
reason to just always work directly upstream.
well, that deploy/release process is not going to be eliminated. I'm
just working on some ideas to make things
I have 3 boys aged 3 to 8. ;)
From the outside there are differences between internal and public
trees of both ChromiumOS and Coreboot which put roadblocks in the way of
a successful build, at times. I'm not here to tell you how to do things,
but if there were a work-around for my current
I realise that this may well not work for reasons I don't understand,
but I have manually added the me.bin file to coreboot.rom using
cbfstool. Worth a try, I thought.
On 24/07/2013 07:38, ron minnich wrote:
On Tue, Jul 23, 2013 at 9:44 PM, Peter Stuge pe...@stuge.se wrote:
I guess
Well, that didn't work, although the fan briefly span up, which I
didn't notice before.
I also tried building your beloved Parrot, and that is missing me.bin
too.
On 24/07/2013 11:26, John Lewis wrote:
I realise that this may well not work for reasons I don't understand,
but I have
John,
Are you checking out the blobs repo into 3rdparty? In that repo there
are the following blobs for lumpy:
http://review.coreboot.org/gitweb?p=blobs.git;a=tree;f=mainboard/samsung/lumpy;h=b4c159f20789c0eacdf5a25135a3275d277cf256;hb=refs/heads/master
The descriptor and me blobs don't live in
Aaron,
On 24/07/2013 14:36, Aaron Durbin wrote:
John,
Are you checking out the blobs repo into 3rdparty? In that repo there
are the following blobs for lumpy:
Yes.
The config looks sane. I take it there i no serial port to see what is
going on. Kyosti has worked with this using usb debug. He has also
built upstream for lumpy. Kyosti, can you provide any guidance for
John? I don't have a lumpy to play with at my disposal. This might be
a mismatch withe
A couple things to change:
CONFIG_CPU_ADDR_BITS=36
CONFIG_SPI_FLASH_NO_FAST_READ=y
I *don't* think this is causing you grief, but these are different
from the chromium repo.
Also, you .config shows a 4MiB cbfs, but that doesn't jive with the
cbfstool output from a previous email where it looked
On 24/07/2013 16:16, Aaron Durbin wrote:
A couple things to change:
CONFIG_CPU_ADDR_BITS=36
CONFIG_SPI_FLASH_NO_FAST_READ=y
Okay will change and try again, just in case. I did notice there are 3
different binaries in the 3rdparty/northbridge/intel/sandybridge
directory. Perhaps I should
On Wed, Jul 24, 2013 at 10:32 AM, John Lewis jle...@johnlewis.ie wrote:
On 24/07/2013 16:16, Aaron Durbin wrote:
A couple things to change:
CONFIG_CPU_ADDR_BITS=36
CONFIG_SPI_FLASH_NO_FAST_READ=y
Okay will change and try again, just in case. I did notice there are 3
different binaries in
Just so the mailing list sees that this worked.
On Wed, Jul 24, 2013 at 10:54 AM, John Lewis jle...@johnlewis.ie wrote:
Aaron, you're a star. I now have a SeaBIOS prompt and it's trying to boot
off the HD. :))
On 24/07/2013 16:39, Aaron Durbin wrote:
On Wed, Jul 24, 2013 at
Hi
Just briefly jumping in the middle of conversation. The romstage.c in
samsung/lumpy does not work with systemagent-r6.bin. More precisely,
pei_data is missing initialisation of some fields. Same thing for
stumpy.
Ron _should_ have been aware of this. Actually, if you want my opinion,
he
So, I have been trying to do as Ron suggested. First obstacle is VGA
BIOS isn't pulled in automatically. I managed to extract that from
existing BIOS using fmap_decode and cbfstool, as per the VMX Hacking
instructions on the Chromium website, and Coreboot builds, but I'm left
with a brick. Can
Well, it doesn't. As for the VGA BIOS I get make: *** No rule to
make target `systemagent-r6.bin', needed by `build/coreboot.pre1'.
Stop. It only seems to pull in the descriptor and ME binaries, at least
those are the only ones in 3rdparty directory.
John.
On 23/07/2013
22:33, ron minnich
Actually file is in 3rdparty/northbridge/intel/sandybridge/ but build
isn't picking file up.
On 23/07/2013 22:33, ron minnich wrote:
If you set that, and you enable 3rd party binaries, it should get it
just
fine.
ron
On Tue, Jul 23, 2013 at 2:31 PM, John Lewis jle...@johnlewis.ie
wrote:
scream and scream again ... ok I'll look. Just worked for parrot.
This whole experience is convincing me we've screwed up how we deploy
chromebook coreboot to upstream ...
speaking for myself, nobody else, and not google :-)
ron
--
coreboot mailing list: coreboot@coreboot.org
On Tue, Jul 23, 2013 at 4:45 PM, John Lewis jle...@johnlewis.ie wrote:
Actually file is in 3rdparty/northbridge/intel/sandybridge/ but build isn't
picking file up.
In your .config can you set
CONFIG_MRC_FILE=3rdparty/northbridge/intel/sandybridge/systemagent-r6.bin
? I think that will pick it
uh, yeah there needs to be an me.bin. mrc.bin is the code that runs on
x86 to turn on memory.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
mrc != me. mrc is memory reference code and me is management engine, and
they are not interchangeable.
Gabe
On Tue, Jul 23, 2013 at 2:53 PM, John Lewis jle...@johnlewis.ie wrote:
Okay. :)
Well, I copied the file into the coreboot root and it built (the full path
is not specified in
Well this is all I get if I have both ME and System agent enabled in
menuconfig. And, yes, I did it all again from scratch in case. Thoughts?
Name Offset Type Size
cmos_layout.bin0x70 cmos_layout 1120
pci8086,0106.rom
ron minnich wrote:
This whole experience is convincing me we've screwed up how we deploy
chromebook coreboot to upstream ...
Sure sounds like it.
I guess eliminating that deployment/release process completely is the
reason to just always work directly upstream.
//Peter
--
coreboot mailing
Hey Guys,
Thanks to some pointers that Ron Minnich gave me a few weeks back, I've
been able to debrick my Samsung 550 Chromebook. However, during the time
I waited for my Bus Pirate I started thinking it might be nice to build
my own Coreboot, with a SeaBIOS payload. Now I have a build, but
you need a vga bios for now. You must have the ME firmware.
Try this:
make menuconfig
go to general setup
enable the 'third party binaries' menu item (or whatever it's called)
they should now get downloaded automagically.
Do a cbfstool build/coreboot.rom print
before and after this step, and
60 matches
Mail list logo
