Peter Stuge wrote:
> Stefan Reinauer wrote:
>
>>> Right, but what checks that the data is not colliding with something
>>> else.
>>>
>> Like?
>>
>
> Like another table? Or is this the first thing written - and
> everything afterwards is simply appended?
>
The coreboot table is wri
Peter,
If I want to port coreboot to Atheros chipset, can you please point me
to a general direction on getting started?
Thanks,
Shane
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Stefan Reinauer wrote:
> > Right, but what checks that the data is not colliding with something
> > else.
>
> Like?
Like another table? Or is this the first thing written - and
everything afterwards is simply appended?
//Peter
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboo
On Wed, Nov 11, 2009 at 10:32:40PM +0100, Patrick Georgi wrote:
> Ideally, it will become some automatic "as small as possible"
> configuration. Unfortunately ld doesn't allow to align everything to an
> upper boundary, so this requires the link-twice trick or so.
Just as a random note, the ab
On 12/11/2009, Stefan Reinauer wrote:
> Myles Watson wrote:
>> On Wed, Nov 11, 2009 at 4:57 PM, Maciej Pijanka
>> wrote:
>>
>>> On 12/11/2009, Myles Watson wrote:
>>>
>> This doesn't seem like it should be a config option any more.
>>
> Ideally, it will become some automatic "as smal
Myles Watson wrote:
> On Wed, Nov 11, 2009 at 4:57 PM, Maciej Pijanka
> wrote:
>
>> On 12/11/2009, Myles Watson wrote:
>>
> This doesn't seem like it should be a config option any more.
>
Ideally, it will become some automatic "as small as possible"
configurat
Peter Stuge wrote:
> Myles Watson wrote:
>
>>> It is completely unclear to me why it is safe to write beyond the
>>> struct lb_record
>>>
>> lb_record is just the header. The data follows it, but isn't a
>> member of the struct.
>>
>
> Right, but what checks that the data is not col
nice.
Acked-by: Ronald G. Minnich
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
> memcpy(0518, 0010d91c, c)
>
> I have no idea why 12. I reverted it.
It turns out that option_table is actually a struct cmos_option_table
in the header file.
Here's a better fix:
Index: src/arch/i386/boot/coreboot_table.c
===
On Wed, Nov 11, 2009 at 4:57 PM, Maciej Pijanka
wrote:
> On 12/11/2009, Myles Watson wrote:
This doesn't seem like it should be a config option any more.
>>>
>>> Ideally, it will become some automatic "as small as possible"
>>> configuration.
>>> Unfortunately ld doesn't allow to align every
On Wed, Nov 11, 2009 at 4:46 PM, ron minnich wrote:
> On Wed, Nov 11, 2009 at 3:37 PM, Peter Stuge wrote:
>> ron minnich wrote:
>>> >>> - memcpy(rec_dest, rec_src, rec_src->size);
>>> >>> + memcpy(rec_dest, &option_table, sizeof(option_table));
>>>
>>> completely changes
On 12/11/2009, Myles Watson wrote:
>>> This doesn't seem like it should be a config option any more.
>>
>> Ideally, it will become some automatic "as small as possible"
>> configuration.
>> Unfortunately ld doesn't allow to align everything to an upper boundary,
>> so
>> this requires the link-twi
On Wed, Nov 11, 2009 at 4:37 PM, Peter Stuge wrote:
> ron minnich wrote:
>> >>> - memcpy(rec_dest, rec_src, rec_src->size);
>> >>> + memcpy(rec_dest, &option_table, sizeof(option_table));
>>
>> completely changes the behavior of the code and is wrong.
>>
>> I'm willing to
Author: myles
Date: 2009-11-12 00:59:19 +0100 (Thu, 12 Nov 2009)
New Revision: 4936
Modified:
trunk/src/arch/i386/boot/coreboot_table.c
Log:
Revert my too-hasty commit.
Signed-off-by: Myles Watson
Acked-by: Myles Watson
Modified: trunk/src/arch/i386/boot/coreboot_table.c
=
On Wed, Nov 11, 2009 at 3:37 PM, Peter Stuge wrote:
> ron minnich wrote:
>> >>> - memcpy(rec_dest, rec_src, rec_src->size);
>> >>> + memcpy(rec_dest, &option_table, sizeof(option_table));
>>
>> completely changes the behavior of the code and is wrong.
>>
>> I'm willing to
ron minnich wrote:
> >>> - memcpy(rec_dest, rec_src, rec_src->size);
> >>> + memcpy(rec_dest, &option_table, sizeof(option_table));
>
> completely changes the behavior of the code and is wrong.
>
> I'm willing to be convinced. But sizeof(option_table) is 8
How can that
Myles Watson wrote:
> > It is completely unclear to me why it is safe to write beyond the
> > struct lb_record
>
> lb_record is just the header. The data follows it, but isn't a
> member of the struct.
Right, but what checks that the data is not colliding with something
else.
> > (maybe it is
On Wed, Nov 11, 2009 at 3:31 PM, Myles Watson wrote:
> On Wed, Nov 11, 2009 at 4:06 PM, Peter Stuge wrote:
>> Myles Watson wrote:
>>> How about this:
>>>
>>> Index: src/arch/i386/boot/coreboot_table.c
>>> ===
>>> --- src/arch/i386/bo
On Wed, Nov 11, 2009 at 4:06 PM, Peter Stuge wrote:
> Myles Watson wrote:
>> How about this:
>>
>> Index: src/arch/i386/boot/coreboot_table.c
>> ===
>> --- src/arch/i386/boot/coreboot_table.c (revision 4931)
>> +++ src/arch/i386
Author: myles
Date: 2009-11-12 00:32:36 +0100 (Thu, 12 Nov 2009)
New Revision: 4935
Modified:
trunk/src/arch/i386/boot/coreboot_table.c
Log:
Silence an ugly-looking warning. Two casts were not enough, so just don't cast
it. Trust the option_table generator to get the length correct.
Signed-o
Myles Watson wrote:
> How about this:
>
> Index: src/arch/i386/boot/coreboot_table.c
> ===
> --- src/arch/i386/boot/coreboot_table.c (revision 4931)
> +++ src/arch/i386/boot/coreboot_table.c (working copy)
> @@ -485,11 +48
On Wed, Nov 11, 2009 at 3:50 PM, Myles Watson wrote:
> On Wed, Nov 11, 2009 at 3:49 PM, ron minnich wrote:
>> On Wed, Nov 11, 2009 at 2:39 PM, Myles Watson wrote:
>>
>>> - memcpy(rec_dest, rec_src, rec_src->size);
>>> + memcpy(rec_dest, &option_table, sizeof(option_
On Wed, Nov 11, 2009 at 3:49 PM, ron minnich wrote:
> On Wed, Nov 11, 2009 at 2:39 PM, Myles Watson wrote:
>
>> - memcpy(rec_dest, rec_src, rec_src->size);
>> + memcpy(rec_dest, &option_table, sizeof(option_table));
>
> how can this be right? rec_src->size is 1160, a
On Wed, Nov 11, 2009 at 2:39 PM, Myles Watson wrote:
> - memcpy(rec_dest, rec_src, rec_src->size);
> + memcpy(rec_dest, &option_table, sizeof(option_table));
how can this be right? rec_src->size is 1160, and sizeof(option_table) is 8?
ron
--
coreboot mailing list
>> This doesn't seem like it should be a config option any more.
>>
>
> Ideally, it will become some automatic "as small as possible" configuration.
> Unfortunately ld doesn't allow to align everything to an upper boundary, so
> this requires the link-twice trick or so.
> So for now, I'd like to ke
On Wed, Nov 11, 2009 at 3:21 PM, Peter Stuge wrote:
> Stefan Reinauer wrote:
>> > Maybe make a type with struct lb_record followed by unsigned char [],
>> > then it is more clear what is going on.
>>
>> Or just get the length via read32.
>
> I was thinking about how the source code looks, not so m
Stefan Reinauer wrote:
> > Maybe make a type with struct lb_record followed by unsigned char [],
> > then it is more clear what is going on.
>
> Or just get the length via read32.
I was thinking about how the source code looks, not so much what
happens at run time. But that could also be an impro
Peter Stuge wrote:
> Myles Watson wrote:
>
unsigned char option_table[] = {
0xc8,0x00,0x00,0x00,0x88,0x04,0x00,0x00,0x0c,0x00,
>>> Second 32 bits 0x88,0x04,0x00,0x00 is the length. We're small endian.
>>> So it's 0x488 or 1160 bytes. Does that match?
>>>
>>
Am 11.11.2009 21:28, schrieb Myles Watson:
On Wed, Nov 11, 2009 at 1:16 PM, Patrick Georgi wrote:
3. CONFIG_ROMBASE in kconfig isn't set to the ROM size, but to 4GB-64KB, ie.
the standard start address of the bootblock. That's how it's used anyway
(which didn't show because the linker scri
Author: oxygene
Date: 2009-11-11 21:32:23 + (Wed, 11 Nov 2009)
New Revision: 4934
Modified:
trunk/src/arch/i386/Kconfig
trunk/src/arch/i386/Makefile.inc
trunk/util/cbfstool/cbfstool.c
trunk/util/newconfig/config.g
Log:
Rework bootblock size handling:
- don't pretend to create a boo
Myles Watson wrote:
>> The good news is:
>> chip southbridge/amd/rs780 unconditionally pulls in the graphics driver
>> which is still executed per PCI ID, and not per notation of static.c
>>
>> So it's completely enough to drop the graphics device from
>> Config.lb/devicetree.cb and say
>>
>> chip
On Wed, Nov 11, 2009 at 2:26 PM, Stefan Reinauer wrote:
> Myles Watson wrote:
>>> The good news is:
>>> chip southbridge/amd/rs780 unconditionally pulls in the graphics driver
>>> which is still executed per PCI ID, and not per notation of static.c
>>>
>>> So it's completely enough to drop the gra
On Wed, Nov 11, 2009 at 1:21 PM, Peter Stuge wrote:
> Myles Watson wrote:
>> >> unsigned char option_table[] = {
>> >> 0xc8,0x00,0x00,0x00,0x88,0x04,0x00,0x00,0x0c,0x00,
>> >
>> > Second 32 bits 0x88,0x04,0x00,0x00 is the length. We're small endian.
>> > So it's 0x488 or 1160 bytes. Does th
Myles Watson wrote:
>> The good news is:
>> chip southbridge/amd/rs780 unconditionally pulls in the graphics driver
>> which is still executed per PCI ID, and not per notation of static.c
>>
>> So it's completely enough to drop the graphics device from
>> Config.lb/devicetree.cb and say
>>
>> chip
Myles Watson wrote:
> >> unsigned char option_table[] = {
> >> 0xc8,0x00,0x00,0x00,0x88,0x04,0x00,0x00,0x0c,0x00,
> >
> > Second 32 bits 0x88,0x04,0x00,0x00 is the length. We're small endian.
> > So it's 0x488 or 1160 bytes. Does that match?
>
> Yes, it matches. There are 116 10-byte lines
On Wed, Nov 11, 2009 at 1:50 PM, ron minnich wrote:
> It's not my favorite piece of code.
:)
>> unsigned char option_table[] = {
>> 0xc8,0x00,0x00,0x00,0x88,0x04,0x00,0x00,0x0c,0x00,
>
> Second 32 bits 0x88,0x04,0x00,0x00 is the length. We're small endian.
> So it's 0x488 or 1160 bytes. Doe
It's not my favorite piece of code.
> unsigned char option_table[] = {
>0xc8,0x00,0x00,0x00,0x88,0x04,0x00,0x00,0x0c,0x00,
Second 32 bits 0x88,0x04,0x00,0x00 is the length. We're small endian.
So it's 0x488 or 1160 bytes. Does that match?
So this struct:
> struct lb_record {
>uint
On Wed, Nov 11, 2009 at 12:31 PM, Myles Watson wrote:
> src/arch/i386/boot/coreboot_table.c: In function 'write_coreboot_table':
> src/arch/i386/boot/coreboot_table.c:492: warning: dereferencing
> pointer 'rec_src' does break strict-aliasing rules
> src/arch/i386/boot/coreboot_table.c:491: note: i
Patrick Georgi wrote:
> attached patch cleans up the bootblock size handling:
>
> Signed-off-by: Patrick Georgi
Acked-by: Peter Stuge
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On Wed, Nov 11, 2009 at 1:16 PM, Patrick Georgi wrote:
> 3. CONFIG_ROMBASE in kconfig isn't set to the ROM size, but to 4GB-64KB, ie.
> the standard start address of the bootblock. That's how it's used anyway
> (which didn't show because the linker script moves into top 64K if
> necessary)
This d
Hi,
attached patch cleans up the bootblock size handling:
1. cbfstool create does no longer take a value it doesn't parse anyway
(bootblocksize), but creates a bootblock of the size of the file that's
filled in.
2. kconfig and newconfig are adapted to not pass the value
3. CONFIG_ROMBASE in
Author: oxygene
Date: 2009-11-11 19:31:53 + (Wed, 11 Nov 2009)
New Revision: 4933
Modified:
trunk/src/lib/cbfs.c
Log:
Help track down enable_rom issues in CBFS. If the magic
looks like unmapped memory, point to the wiki page with
more information.
Signed-off-by: Patrick Georgi
Acked-by: P
Am 11.11.2009 14:35, schrieb Carl-Daniel Hailfinger:
Wouldn't this cause the warning to be printed multiple times if a
contiguous section is all 0xff?
That test merely validates the master header. If that one is wrong, CBFS
goes boom, without any further lookup.
And even if it printed the me
src/arch/i386/boot/coreboot_table.c: In function 'write_coreboot_table':
src/arch/i386/boot/coreboot_table.c:492: warning: dereferencing
pointer 'rec_src' does break strict-aliasing rules
src/arch/i386/boot/coreboot_table.c:491: note: initialized from here
#if (CONFIG_HAVE_OPTION_TABLE == 1)
Magnus Christensson wrote:
>> How are you using coreboot+SeaBIOS? Are you using the QEMU coreboot
>> target? Maybe that isn't good enough for Simics?
>
> I'm using naked SeaBIOS.
Ah, ok. That makes sense. Thanks!
//Peter
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/m
Patrick Georgi wrote:
> attached patch hopefully helps track down issues related to late
> enable_rom calls.
>
> Signed-off-by: Patrick Georgi
Acked-by: Peter Stuge
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Peter Stuge wrote:
Magnus Christensson wrote:
I'm not sure how work is divided between Coreboot and Seabios. Does
Coreboot do all the machine specific initialization?
This is the idea.
Ok.
Then the LINT LVTs should already have been initialized.
How are you using coreboot+
Kevin O'Connor wrote:
Hi Magnus,
Is:
for (i = 0, actual_cpu_count = 0; i < MaxCountCPUs; i++) {
int log_cpus = (ebx >> 16) & 0xff;
log_cpus = 1UL << fls(log_cpus - 1); /* round up to power of 2 */
if ((cpuid_features & (1 << 28)) && (i & (log_cpus - 1)) != 0)
> The good news is:
> chip southbridge/amd/rs780 unconditionally pulls in the graphics driver
> which is still executed per PCI ID, and not per notation of static.c
>
> So it's completely enough to drop the graphics device from
> Config.lb/devicetree.cb and say
>
> chip southbridge/amd/rs780
>
Hi Magnus,
Is:
for (i = 0, actual_cpu_count = 0; i < MaxCountCPUs; i++) {
int log_cpus = (ebx >> 16) & 0xff;
log_cpus = 1UL << fls(log_cpus - 1); /* round up to power of 2 */
if ((cpuid_features & (1 << 28)) && (i & (log_cpus - 1)) != 0)
continue;
equivale
On Tue, Nov 10, 2009 at 09:30:47AM +0100, Magnus Christensson wrote:
> I'm not sure how work is divided between Coreboot and Seabios. Does
> Coreboot do all the machine specific initialization? Then the LINT LVTs
> should already have been initialized.
Yes. Coreboot is tasked with initializin
On 11.11.2009 13:55, Patrick Georgi wrote:
> attached patch hopefully helps track down issues related to late
> enable_rom calls.
> If the CBFS header magic is 0x, chances are that this is
> because the lower parts of the ROM aren't mapped yet. Point to
> http://www.coreboot.org/Infrastruct
Hi,
attached patch hopefully helps track down issues related to late
enable_rom calls.
If the CBFS header magic is 0x, chances are that this is because
the lower parts of the ROM aren't mapped yet. Point to
http://www.coreboot.org/Infrastructure_Projects#CBFS, which provides
some desc
Peter Stuge wrote:
> Config.lb_mahogany_k8
>
>> chip southbridge/amd/rs780
>> device pci 0.0 on end # HT 0x9600
>> device pci 1.0 on # Internal Graphics P2P bridge 0x9602
>> chip drivers/pci/onboard
>> device pci 5.0 on end # Internal Graphics
54 matches
Mail list logo
