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 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 this
> booting in the first place.
>
> Stefan has uploaded a patch that applies on top of the earlier reverted
> patch. You could try to undo the revert, switch back to the systemagent-r6
> binary, and apply this new patch that was just uploaded:
> http://review.coreboot.org/#/c/3831 <http://review.coreboot.org/#/c/3831/1>/
> (and maybe http://review.coreboot.org/#/c/3830/ too? Stefan?)
>
> Binary blobs ruin all the fun.
>
> -duncan
>
>
>
> On Mon, Jul 29, 2013 at 2:50 PM, John Lewis <jlewis(a)johnlewis.ie> wrote:
>
> > 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 <dlaurie(a)chromium.org> wrote:
> >
> > 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 'spd.bin' starting from 0x700000.
> > CBFS: Found file (offset=0x7dc000, len=1536).
> >
> >
> > I think the console output should show a summary after the MRC binary
> > runs, but the verbose CBFS output is overflowing the buffer:
> >
> > http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/northbridge/i…
> >
> > -duncan
> >
> >
> >
> > On Mon, Jul 29, 2013 at 8:14 AM, Aaron Durbin <adurbin(a)chromium.org>wrote:
> >
> >> 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 0x100600000 TOLUD 0x7f200000 TOM 0x80000000
> >> MEBASE 0x7f800000
> >> IGD decoded, subtracting 32M UMA and 2M GTT
> >> TSEG base 0x7c800000 size 8M
> >> Available memory below 4GB: 1992M
> >> Available memory above 4GB: 6M
> >>
> >> -Aaron
> >>
> >> On Mon, Jul 29, 2013 at 10:04 AM, Kyösti Mälkki <kyosti.malkki(a)gmail.com>
> >> wrote:
> >> > 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 e820 memory map.
> >> >
> >> >
> >> > This is from your dmesg, I see same with (close to) current master.
> >> >
> >> > [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x00000001005fffff]
> >> usable
> >> >
> >> >
> >> > The coreboot image my Samsung 550 originally shipped with had this:
> >> >
> >> > [ 0.000000] BIOS-e820: 0000000100000000 - 000000014fe00000 (usable)
> >> >
> >> >
> >> >
> >> > Kyösti
> >> >
> >>
> >> --
> >> coreboot mailing list: coreboot(a)coreboot.org
> >> http://www.coreboot.org/mailman/listinfo/coreboot
> >>
> >
> >
On 07/29/2013 10:19 AM, ron minnich wrote:
> On Wed, Jul 24, 2013 at 10:34 AM, Kyösti Mälkki <kyosti.malkki(a)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 of things I bet.
>
> You perhaps underestimate the complexity of our daily environment.
>
> ron
>
Ron,
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 <dlaurie(a)chromium.org> 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 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 this booting in the first place.
>
>
>Stefan has uploaded a patch that applies on top of the earlier reverted patch. You could try to undo the revert, switch back to the systemagent-r6 binary, and apply this new patch that was just uploaded:
>
>http://review.coreboot.org/#/c/3831/
>
>(and maybe http://review.coreboot.org/#/c/3830/ too? Stefan?)
>
>
>Binary blobs ruin all the fun.
>
>
>-duncan
>
>
>
>
>On Mon, Jul 29, 2013 at 2:50 PM, John Lewis <jlewis(a)johnlewis.ie> wrote:
>
>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 <dlaurie(a)chromium.org> wrote:
>
>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 'spd.bin' starting from 0x700000. CBFS: Found file (offset=0x7dc000, len=1536).
>
>
>I think the console output should show a summary after the MRC binary runs, but the verbose CBFS output is overflowing the buffer:
>
>http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/northbridge/i…
>
>
>-duncan
>
>
>
>
>On Mon, Jul 29, 2013 at 8:14 AM, Aaron Durbin <adurbin(a)chromium.org> wrote:
>
>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 0x100600000 TOLUD 0x7f200000 TOM 0x80000000
>MEBASE 0x7f800000
>IGD decoded, subtracting 32M UMA and 2M GTT
>TSEG base 0x7c800000 size 8M
>
>Available memory below 4GB: 1992M
>
>Available memory above 4GB: 6M
>
>
>-Aaron
>
>
>On Mon, Jul 29, 2013 at 10:04 AM, Kyösti Mälkki <kyosti.malkki(a)gmail.com> wrote:
>> 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 e820 memory map.
>>
>>
>> This is from your dmesg, I see same with (close to) current master.
>>
>> [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x00000001005fffff] usable
>>
>>
>> The coreboot image my Samsung 550 originally shipped with had this:
>>
>> [ 0.000000] BIOS-e820: 0000000100000000 - 000000014fe00000 (usable)
>>
>>
>>
>
>> Kyösti
>>
>
>--
>coreboot mailing list: coreboot(a)coreboot.org
>http://www.coreboot.org/mailman/listinfo/coreboot
>
>
>
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 <dlaurie(a)chromium.org> wrote:
>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 'spd.bin' starting from 0x700000. CBFS: Found file (offset=0x7dc000, len=1536).
>
>
>I think the console output should show a summary after the MRC binary runs, but the verbose CBFS output is overflowing the buffer:
>
>http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/northbridge/i…
>
>
>-duncan
>
>
>
>
>On Mon, Jul 29, 2013 at 8:14 AM, Aaron Durbin <adurbin(a)chromium.org> wrote:
>
>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 0x100600000 TOLUD 0x7f200000 TOM 0x80000000
>MEBASE 0x7f800000
>IGD decoded, subtracting 32M UMA and 2M GTT
>TSEG base 0x7c800000 size 8M
>
>Available memory below 4GB: 1992M
>
>Available memory above 4GB: 6M
>
>-Aaron
>
>
>On Mon, Jul 29, 2013 at 10:04 AM, Kyösti Mälkki <kyosti.malkki(a)gmail.com> wrote:
>> 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 e820 memory map.
>>
>>
>> This is from your dmesg, I see same with (close to) current master.
>>
>> [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x00000001005fffff] usable
>>
>>
>> The coreboot image my Samsung 550 originally shipped with had this:
>>
>> [ 0.000000] BIOS-e820: 0000000100000000 - 000000014fe00000 (usable)
>>
>>
>>
>> Kyösti
>>
>
>--
>coreboot mailing list: coreboot(a)coreboot.org
>http://www.coreboot.org/mailman/listinfo/coreboot
>
>
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 'spd.bin' starting from 0x700000.
CBFS: Found file (offset=0x7dc000, len=1536).
I think the console output should show a summary after the MRC binary runs,
but the verbose CBFS output is overflowing the buffer:
http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/northbridge/i…
-duncan
On Mon, Jul 29, 2013 at 8:14 AM, Aaron Durbin <adurbin(a)chromium.org> wrote:
> 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 0x100600000 TOLUD 0x7f200000 TOM 0x80000000
> MEBASE 0x7f800000
> IGD decoded, subtracting 32M UMA and 2M GTT
> TSEG base 0x7c800000 size 8M
> Available memory below 4GB: 1992M
> Available memory above 4GB: 6M
>
> -Aaron
>
> On Mon, Jul 29, 2013 at 10:04 AM, Kyösti Mälkki <kyosti.malkki(a)gmail.com>
> wrote:
> > 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 e820 memory map.
> >
> >
> > This is from your dmesg, I see same with (close to) current master.
> >
> > [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x00000001005fffff]
> usable
> >
> >
> > The coreboot image my Samsung 550 originally shipped with had this:
> >
> > [ 0.000000] BIOS-e820: 0000000100000000 - 000000014fe00000 (usable)
> >
> >
> >
> > Kyösti
> >
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
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 does not handle the
> soldered-on memory.
>
> Does that sound about right?
Yep, that's it in a nutshell, Aaron. Also the SeaBIOS that gets pulled
in links the bootmenu to F12. Needs to be a saner ESC or F2 default for
Chromebooks as per ChromiumOS Coreboot.
>
> On Mon, Jul 29, 2013 at 1:12 PM, John Lewis <jlewis(a)johnlewis.ie>
> wrote:
>
>> On 29/07/2013 16:47, Aaron Durbin wrote:
>>
>>> On Mon, Jul 29, 2013 at 10:38 AM, John Lewis <jlewis(a)johnlewis.ie
>>> [1]> 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 debug
>>> further.
>>> Did you save the original rom image that your device was shipped
>>> with? I'd be curious to know if that matches the one found in the
>>> blobs repo.
>> You can find it at http://johnlewis.ie/bios.bin [3]and the mrc.bin's
>> are different by a few kilobytes. I can also tell you that if I try
>> to
>> use that mrc.bin with straight Coreboot I get a nice brick. ;)
>>
>>>> On 29/07/2013 16:25, Aaron Durbin wrote:
>>>>
>>>>> On Mon, Jul 29, 2013 at 10:22 AM, Kyösti Mälkki
>>>>> <kyosti.malkki(a)gmail.com [2][1]> 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 : spd_addresses: { 0xA0, 0x00,0xA4,0x00
>>>>>> },
>>>>> The 0xf0 handles the soldered down memory. I was looking at the
>>>>> 0x50 address as well, but I think that is correct (I'm looking at
>>>>> code that I think is the wrapper that you guys are using). I
>>>>> could be wrong though.
Links:
------
[1] mailto:jlewis@johnlewis.ie
[2] mailto:kyosti.malkki@gmail.com
[3] http://johnlewis.ie/bios.bin
On 29/07/2013 16:47, Aaron Durbin wrote:
> On Mon, Jul 29, 2013 at 10:38 AM, John Lewis <jlewis(a)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 debug further.
> Did you save the original rom image that your device was shipped
> with?
> I'd be curious to know if that matches the one found in the blobs
> repo.
You can find it at http://johnlewis.ie/bios.bin and the mrc.bin's are
different by a few kilobytes. I can also tell you that if I try to use
that mrc.bin with straight Coreboot I get a nice brick. ;)
>
>> On 29/07/2013 16:25, Aaron Durbin wrote:
>>
>>> On Mon, Jul 29, 2013 at 10:22 AM, Kyösti Mälkki
>>> <kyosti.malkki(a)gmail.com [1]> 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 :
>>>> spd_addresses: { 0xA0, 0x00,0xA4,0x00 },
>>> The 0xf0 handles the soldered down memory. I was looking at the
>>> 0x50
>>> address as well, but I think that is correct (I'm looking at code
>>> that I think is the wrapper that you guys are using). I could be
>>> wrong though.
* Aaron Durbin <adurbin(a)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 with the
> cbfstool output from a previous email where it looked to be set to
> 1MiB.
I think you want an 8MiB rom file with a 6MiB (space left for ME and
descriptor) CBFS.
On 29/07/2013 16:47, Aaron Durbin wrote:
> On Mon, Jul 29, 2013 at 10:38 AM, John Lewis <jlewis(a)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 debug further.
> Did you save the original rom image that your device was shipped
> with?
I do, but I'm not sure how complete it is since every time I've tried
to use it since first reading the ME doesn't seem to be very happy and
switches the laptop off after 30 mins. I'll forward it, presently.
> I'd be curious to know if that matches the one found in the blobs
> repo.
>
>> On 29/07/2013 16:25, Aaron Durbin wrote:
>>
>>> On Mon, Jul 29, 2013 at 10:22 AM, Kyösti Mälkki
>>> <kyosti.malkki(a)gmail.com [1]> 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 :
>>>> spd_addresses: { 0xA0, 0x00,0xA4,0x00 },
>>> The 0xf0 handles the soldered down memory. I was looking at the
>>> 0x50
>>> address as well, but I think that is correct (I'm looking at code
>>> that I think is the wrapper that you guys are using). I could be
>>> wrong though.
Links:
------
[1] mailto:kyosti.malkki@gmail.com
