> > It doesn't seem good that the Multiboot table gets written before the
> > UMA and high table areas are added. I would think that's why they
> > don't show up.
> >
>
> Yes, that was it, thanks for the advice.
I'm glad it helped.
> I checked with coreinfo, and multiboot table did not have a cl
On Thu, 2010-08-26 at 09:40 -0600, Myles Watson wrote:
> It doesn't seem good that the Multiboot table gets written before the
> UMA and high table areas are added. I would think that's why they
> don't show up.
>
Yes, that was it, thanks for the advice.
I checked with coreinfo, and multiboot
One reason for keeping other settings out of the mainboard is that
they may get overwritten later.
It looks like the register at gpio_address + 0x18
(GPIOL_PULLUP_ENABLE) is getting written in cs5536.c and
spacerunner-lx/mainboard.c.
Thanks,
Myles
--
coreboot mailing list: coreboot@coreboot.org
Author: myles
Date: Thu Aug 26 20:24:04 2010
New Revision: 5744
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5744
Log:
Remove unused mainboard_config definitions. Trivial.
Signed-off-by: Myles Watson
Acked-by: Myles Watson
Modified:
trunk/src/mainboard/amd/db800/chip.h
trun
On Thu, Aug 26, 2010 at 10:42 AM, Myles Watson wrote:
>> Am 25.08.2010 18:10, schrieb Jens Rottmann:
>> > i.e. make the mainboard the root device of the device tree - seemed
>> plausible to
>> > me, somehow. This compiles and boots fine, but the 'register' statement
>> still
>> > doesn't have any
> Am 25.08.2010 18:10, schrieb Jens Rottmann:
> > i.e. make the mainboard the root device of the device tree - seemed
> plausible to
> > me, somehow. This compiles and boots fine, but the 'register' statement
> still
> > doesn't have any effect, sio_gp1x_config in the mainboard's chip.h still
sio_
Am 25.08.2010 18:10, schrieb Jens Rottmann:
> i.e. make the mainboard the root device of the device tree - seemed plausible
> to
> me, somehow. This compiles and boots fine, but the 'register' statement still
> doesn't have any effect, sio_gp1x_config in the mainboard's chip.h still isn't
> set -
> Multiboot Information structure has been written.
> POST: 0x9d
> Adding CBMEM entry as no. 5
> Writing high table forward entry at 0x0500
> Wrote coreboot table at: 0500 - 0518 checksum 9fde
> New low_table_end: 0x0518
> Now going to write high coreboot table at 0x7fffe000
> rom
On Thu, Aug 26, 2010 at 9:31 AM, Juhana Helovuo wrote:
> On Thu, 2010-08-19 at 14:39 -0600, Myles Watson wrote:
>> > It is still somewhat unclear where and how all of these memory maps are
>> > transmitted from Coreboot to Linux. I could not find the callback for
>> > BIOS e820 calls in Coreboot s
On Thu, 2010-08-19 at 14:39 -0600, Myles Watson wrote:
> > It is still somewhat unclear where and how all of these memory maps are
> > transmitted from Coreboot to Linux. I could not find the callback for
> > BIOS e820 calls in Coreboot sources.
>
> Coreboot doesn't do callbacks. If you're using
Am 26.08.2010 16:13, schrieb Jens Rottmann:
> These 3 boards say 'default n', but because all 3 have northbridges which do
> 'select HAVE_HIGH_TABLES', it's _still_ always 'y'.
>
> I really didn't understand what the whole point of this stuff is, so I didn't
> dare touch it ...
The point was tha
Hi Stefan,
during doing this I happened to trip over HAVE_HIGH_TABLES, which struck me as
really weired:
src/Kconfig:
config HAVE_HIGH_TABLES
bool
default y
And various northbridges 'select' this - but what is the point, it defaults to
'y' and has no prompt for the user to unse
On 8/26/10 2:26 PM, Jens Rottmann wrote:
> CONFIG_DEBUG_RAM_SETUP and CONFIG_DEBUG_SMBUS are only available if the board
> /
> chipset support it. But this involves a long list of 'depends', which you
> have
> to remember updating manually. Converted this into HAVE_... properties, which
> will
Author: stepan
Date: Thu Aug 26 14:46:02 2010
New Revision: 5743
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5743
Log:
CONFIG_DEBUG_RAM_SETUP and CONFIG_DEBUG_SMBUS are only available if the board /
chipset support it. But this involves a long list of 'depends', which you have
to re
Author: stepan
Date: Thu Aug 26 14:43:58 2010
New Revision: 5742
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5742
Log:
One of my boards needs this mini delay in order to survive ram initialization.
Odd. The others don't.
Signed-off-by: Stefan Reinauer
Acked-by: Stefan Reinauer
Mo
Author: stepan
Date: Thu Aug 26 14:42:43 2010
New Revision: 5741
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5741
Log:
kontron 986lcd-m: Fix compilation if there is no oprom execution at all...
Signed-off-by: Stefan Reinauer
Acked-by: Stefan Reinauer
Modified:
trunk/src/mainbo
CONFIG_DEBUG_RAM_SETUP and CONFIG_DEBUG_SMBUS are only available if the board /
chipset support it. But this involves a long list of 'depends', which you have
to remember updating manually. Converted this into HAVE_... properties, which
will be inherited automatically if someone copies a chipset
On 8/25/10 7:34 PM, Антон Кочков wrote:
> inteltool: added initial support of cpu_info extended information
> inteltool: added initial support for other cpu's
> inteltool: dumping MSR registers for Intel Celeron M 743
> Signed-off-by: Anton Kochkov
Hi Anton,
just some thoughts...
I don't think
Theis is very nice and probably needed in the long run.
Mvh Anders
- Reply message -
Fra: "Patrick Georgi"
Dato: tor., aug. 26, 2010 08:17
Emne: [coreboot] Building coreboot BIOS on a Windows computer
Til:
Am 26.08.2010 06:44, schrieb Scott:
> Hello coreboot folks,
>
> I know the dev
19 matches
Mail list logo
