On Fri, Sep 5, 2014 at 2:37 PM, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> I think that his problem is either:
> 1) Badly seated modules
I like this because it gets us off the hook. But it's hard for me to
believe that every single reseat is a bad one.
Mono, now that it's all working, can y
On 09/05/2014 02:40 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 06.09.2014 00:31, H. Peter Anvin wrote:
>> On 09/05/2014 02:23 PM, Vladimir 'φ-coder/phcoder' Serbinenko
>> wrote:
>>> On 06.09.2014 00:18, ron minnich wrote:
Vladimir can you point me to that patch? This sounds
in
On 06.09.2014 00:31, H. Peter Anvin wrote:
> On 09/05/2014 02:23 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> On 06.09.2014 00:18, ron minnich wrote:
>>> Vladimir can you point me to that patch? This sounds
>>> interesting.
>>>
>> https://lkml.org/lkml/2010/8/25/190
>>
>
> I believe *most*
On 06.09.2014 00:19, ron minnich wrote:
> I don't think it's random at all. Vladimir can confirm, but if he is
> caching the RAM parameters, then this 'solution' will work for you
> until the next time you reflash coreboot, or change your dram type, at
> which point it will stop working.
>
Nehalem
On 09/05/2014 02:23 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 06.09.2014 00:18, ron minnich wrote:
>> Vladimir can you point me to that patch? This sounds
>> interesting.
>>
> https://lkml.org/lkml/2010/8/25/190
>
I believe *most* of this patch has already gotten merged as we now use
On 06.09.2014 00:18, ron minnich wrote:
> Vladimir can you point me to that patch? This sounds interesting.
>
https://lkml.org/lkml/2010/8/25/190
> ron
>
signature.asc
Description: OpenPGP digital signature
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/list
On 09/05/2014 02:09 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>
>> I'm not a fan of Coreboot having invented its own nonstandard
>> hacks, but I guess it is pretty much unavoidable.
> It's completely avoidable. The stub can copy this information to
> standard framebuffer info structure. Th
I don't think it's random at all. Vladimir can confirm, but if he is
caching the RAM parameters, then this 'solution' will work for you
until the next time you reflash coreboot, or change your dram type, at
which point it will stop working.
It's not a solid solution.
ron
--
coreboot mailing lis
Vladimir can you point me to that patch? This sounds interesting.
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
> I'm not a fan of Coreboot having invented its own nonstandard hacks, but
> I guess it is pretty much unavoidable.
It's completely avoidable. The stub can copy this information to
standard framebuffer info structure. The only missing thing is to apply
patch by cjwatson or mjg59 (I'm not sure now
I was not hot plugging them, but powering off and removing the battery as well
during each change with the DIMMs. I absolutely don't know why it did not work
before using the second slot separately. It might just have been random?
greets
Mono
On Fri, Sep 05, 2014 at 01:57:36PM -0700, ron minnic
Or are you booting with the second slot full, powering off, loading
both slots, and it works because of the MRC cache?
On Fri, Sep 5, 2014 at 1:57 PM, ron minnich wrote:
> On Fri, Sep 5, 2014 at 1:56 PM, Mono wrote:
>> um, I tested the second slot separately as suggested by phcoder and after
>>
On Fri, Sep 5, 2014 at 1:56 PM, Mono wrote:
> um, I tested the second slot separately as suggested by phcoder and after
> that they work together too.
> thanks!
I don't understand.
The second slot works separately, and now both slots work? What's the
"after" mean? Are you hot plugging the DIMM?
On Fri, Sep 5, 2014 at 1:05 PM, H. Peter Anvin wrote:
> I'm not a fan of Coreboot having invented its own nonstandard hacks, but
> I guess it is pretty much unavoidable.
I suspect this should not be architecture-dependent, since coreboot
tables work across 3 coreboot architectures at present wit
um, I tested the second slot separately as suggested by phcoder and after that
they work together too.
thanks!
On Fri, Sep 05, 2014 at 09:27:02PM +0200, Mono wrote:
> Hallo all,
>
> Is anyone successfuly running the x201 port with two RAM modules installed? I
> am using it (commit 8128a56c0ec7e
On 09/04/2014 03:25 AM, Gerd Hoffmann wrote:
> Signed-off-by: Gerd Hoffmann
> ---
> arch/x86/Kconfig | 12 +++
> arch/x86/kernel/Makefile | 1 +
> arch/x86/kernel/coreboot.c | 232
> +
> 3 files changed, 245 insertions(+)
> create mode
Hallo all,
Is anyone successfuly running the x201 port with two RAM modules installed? I
am using it (commit 8128a56c0ec7e147d4ad68e6ba55979e9ead25ae from Sep 18) for
booting a x201i computer with only one RAM module (2GB). As soon as I insert a
second RAM module (2GB) it does not boot anymore.
On 09/05/2014 11:14 AM, John Lewis wrote:
On 05/09/14 07:17, Denis 'GNUtoo' Carikli wrote:
4. Use your rasberry and try to make g_dbgp work there, to test use the
linux kernel with earlyprintk=dbgp. Note that earlyprintk=dbgp doesn't
work out of the box on all distro's kernels, you need the rig
On 05/09/14 07:17, Denis 'GNUtoo' Carikli wrote:
4. Use your rasberry and try to make g_dbgp work there, to test use the
linux kernel with earlyprintk=dbgp. Note that earlyprintk=dbgp doesn't
work out of the box on all distro's kernels, you need the right
compilation options to make it work.
De
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 03 Sep 2014 16:43:36 +0200
Marek Doležel wrote:
> Hello,
>
> I noticed you are in connection with buglabs community.
>
> I couldn't find any option to buy this device. I guess the device is
> developed only for "Big players" as mentioned o
On Do, 2014-09-04 at 22:09 +0200, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> This code assumes that payload didn't change video mode which is
> improper assumption if you're not a payload.
The code tries to detect that case. If either the vga is in text mode
or it finds vesafb / efifb informa
21 matches
Mail list logo
