[PATCH] fam10 Kconfig

[Myles Watson]

The big_bootblock patch fixes building but breaks booting.  It is only
for seeing what needs to be fixed with fam10 boards.

fam10.diff makes serengeti_cheetah_fam10 build with a broken
bootblock, and updates lots of Kconfig variables.

Signed-off-by: Myles Watson

Thanks,
Myles

[Marc Jones]

On Mon, Oct 12, 2009 at 11:54 AM, Myles Watson  wrote:
> The big_bootblock patch fixes building but breaks booting.  It is only
> for seeing what needs to be fixed with fam10 boards.
>
> fam10.diff makes serengeti_cheetah_fam10 build with a broken
> bootblock, and updates lots of Kconfig variables.
>
> Signed-off-by: Myles Watson

Thanks Myles, I was just getting interested in Fam10 stuff again. I
had two issues using the patches

I get this on a make config

src/mainboard/msi/ms7135/Kconfig:56:warning: type of 'MEM_TRAIN_SEQ'
redefined from 'integer' to 'boolean'

I tried building and get an ACPI build error.

/home/marc/svn/coreboot-v2/build/coreboot_ram.o: In function
`write_acpi_tables':
(.text+0xc3f4): undefined reference to `AmlCode_ssdt3'
/home/marc/svn/coreboot-v2/build/coreboot_ram.o: In function
`write_acpi_tables':
(.text+0xc401): undefined reference to `AmlCode_ssdt4'
/home/marc/svn/coreboot-v2/build/coreboot_ram.o: In function
`write_acpi_tables':
(.text+0xc409): undefined reference to `AmlCode_ssdt5'
/home/marc/svn/coreboot-v2/build/coreboot_ram.o: In function
`write_acpi_tables':
(.text+0xc410): undefined reference to `AmlCode_ssdt2'
collect2: ld returned 1 exit status

Marc

[Myles Watson]

On Mon, Oct 12, 2009 at 2:54 PM, Marc Jones  wrote:
> On Mon, Oct 12, 2009 at 11:54 AM, Myles Watson  wrote:
> > The big_bootblock patch fixes building but breaks booting.  It is only
> > for seeing what needs to be fixed with fam10 boards.
> >
> > fam10.diff makes serengeti_cheetah_fam10 build with a broken
> > bootblock, and updates lots of Kconfig variables.
> >
> > Signed-off-by: Myles Watson
>
> Thanks Myles, I was just getting interested in Fam10 stuff again. I
> had two issues using the patches

I have to admit I don't know how it built for me :(
> I get this on a make config
>
> src/mainboard/msi/ms7135/Kconfig:56:warning: type of 'MEM_TRAIN_SEQ'
> redefined from 'integer' to 'boolean'

Yes.  Everywhere MEM_TRAIN_SEQ is a boolean, it is an error.  It needs
to be set to 0,1, or 2.  This patch sets it correctly, but doesn't fix
all the others.
> I tried building and get an ACPI build error.
>
> /home/marc/svn/coreboot-v2/build/coreboot_ram.o: In function
> `write_acpi_tables':
> (.text+0xc3f4): undefined reference to `AmlCode_ssdt3'
> /home/marc/svn/coreboot-v2/build/coreboot_ram.o: In function
> `write_acpi_tables':
> (.text+0xc401): undefined reference to `AmlCode_ssdt4'
> /home/marc/svn/coreboot-v2/build/coreboot_ram.o: In function
> `write_acpi_tables':
> (.text+0xc409): undefined reference to `AmlCode_ssdt5'
> /home/marc/svn/coreboot-v2/build/coreboot_ram.o: In function
> `write_acpi_tables':
> (.text+0xc410): undefined reference to `AmlCode_ssdt2'
> collect2: ld returned 1 exit status

This is because CONFIG_ACPI_SSDTX_NUM isn't a boolean.

Thanks for trying it out.  Here's an updated patch that hopefully builds :)

Signed-off-by: Myles Watson

Thanks,
Myles

[Marc Jones]

On Mon, Oct 12, 2009 at 3:23 PM, Myles Watson  wrote:
> On Mon, Oct 12, 2009 at 2:54 PM, Marc Jones  wrote:
> > On Mon, Oct 12, 2009 at 11:54 AM, Myles Watson  wrote:
> > > The big_bootblock patch fixes building but breaks booting.  It is only
> > > for seeing what needs to be fixed with fam10 boards.
> > >
> > > fam10.diff makes serengeti_cheetah_fam10 build with a broken
> > > bootblock, and updates lots of Kconfig variables.
> > >
> > > Signed-off-by: Myles Watson
> >
> > Thanks Myles, I was just getting interested in Fam10 stuff again. I
> > had two issues using the patches
>
> I have to admit I don't know how it built for me :(
> > I get this on a make config
> >
> > src/mainboard/msi/ms7135/Kconfig:56:warning: type of 'MEM_TRAIN_SEQ'
> > redefined from 'integer' to 'boolean'
>
> Yes.  Everywhere MEM_TRAIN_SEQ is a boolean, it is an error.  It needs
> to be set to 0,1, or 2.  This patch sets it correctly, but doesn't fix
> all the others.
> > I tried building and get an ACPI build error.
> >
> > /home/marc/svn/coreboot-v2/build/coreboot_ram.o: In function
> > `write_acpi_tables':
> > (.text+0xc3f4): undefined reference to `AmlCode_ssdt3'
> > /home/marc/svn/coreboot-v2/build/coreboot_ram.o: In function
> > `write_acpi_tables':
> > (.text+0xc401): undefined reference to `AmlCode_ssdt4'
> > /home/marc/svn/coreboot-v2/build/coreboot_ram.o: In function
> > `write_acpi_tables':
> > (.text+0xc409): undefined reference to `AmlCode_ssdt5'
> > /home/marc/svn/coreboot-v2/build/coreboot_ram.o: In function
> > `write_acpi_tables':
> > (.text+0xc410): undefined reference to `AmlCode_ssdt2'
> > collect2: ld returned 1 exit status
>
> This is because CONFIG_ACPI_SSDTX_NUM isn't a boolean.
>
> Thanks for trying it out.  Here's an updated patch that hopefully builds :)
>
> Signed-off-by: Myles Watson

That builds but a bunch of *.aml are getting put into the top level.
Can they go somewhere in the build/ dir?

Marc

[Myles Watson]

> That builds but a bunch of *.aml are getting put into the top level.
> Can they go somewhere in the build/ dir?

Sure.

Signed-off-by: Myles Watson

Thanks,
Myles

[Marc Jones]

On Mon, Oct 12, 2009 at 4:02 PM, Myles Watson  wrote:
> > That builds but a bunch of *.aml are getting put into the top level.
> > Can they go somewhere in the build/ dir?
>
> Sure.
>
> Signed-off-by: Myles Watson

Acked-by: Marc Jones

[Myles Watson]

On Mon, Oct 12, 2009 at 4:25 PM, Marc Jones  wrote:
> On Mon, Oct 12, 2009 at 4:02 PM, Myles Watson  wrote:
> > > That builds but a bunch of *.aml are getting put into the top level.
> > > Can they go somewhere in the build/ dir?
> >
> > Sure.
> >
> > Signed-off-by: Myles Watson
>
> Acked-by: Marc Jones

Rev 4762.
Thanks,
Myles

[Marc Jones]

On Mon, Oct 12, 2009 at 4:39 PM, Myles Watson  wrote:
> On Mon, Oct 12, 2009 at 4:25 PM, Marc Jones  wrote:
> > On Mon, Oct 12, 2009 at 4:02 PM, Myles Watson  wrote:
> > > > That builds but a bunch of *.aml are getting put into the top level.
> > > > Can they go somewhere in the build/ dir?
> > >
> > > Sure.
> > >
> > > Signed-off-by: Myles Watson
> >
> > Acked-by: Marc Jones

Myles,

This ack was for the big bootblock as well.

Marc

[Myles Watson]

> > > Acked-by: Marc Jones
>
> Myles,
>
> This ack was for the big bootblock as well.

Even though it can never boot?  It ends up putting start too far away
for a 16-bit offset.  I can commit it if you think it will help you.
We need some way to take 4K out of the image so that it can build and
boot.

Thanks,
Myles

[Marc Jones]

On Tue, Oct 13, 2009 at 4:17 PM, Myles Watson  wrote:
> > > > Acked-by: Marc Jones
> >
> > Myles,
> >
> > This ack was for the big bootblock as well.
>
> Even though it can never boot?  It ends up putting start too far away
> for a 16-bit offset.  I can commit it if you think it will help you.
> We need some way to take 4K out of the image so that it can build and
> boot.

I see. I guess not building is safer than not booting for now.
Marc

[Myles Watson]

On Tue, Oct 13, 2009 at 4:21 PM, Marc Jones  wrote:
> On Tue, Oct 13, 2009 at 4:17 PM, Myles Watson  wrote:
> > > > > Acked-by: Marc Jones
> > >
> > > Myles,
> > >
> > > This ack was for the big bootblock as well.
> >
> > Even though it can never boot?  It ends up putting start too far away
> > for a 16-bit offset.  I can commit it if you think it will help you.
> > We need some way to take 4K out of the image so that it can build and
> > boot.
>
> I see. I guess not building is safer than not booting for now.

Yeah.  I'm not sure how hard taking the 4K out would be compared to
implementing failover with CBFS and Kconfig.

Thanks,
Myles