Boot issues (CBFS?) on VIA pc2500e

[Uwe Hermann]

Hi,

tried to boot-test the VIA p2500e yesterday, but tried a manual
non-kconfig build first, and that one doesn't successfully boot anymore
and thus needs to be fixed first.

The cfbs output was (I used a FILO payload):

Name                           Offset     Type         Size
fallback/payload               0x0        payload      85864
fallback/coreboot_ram          0x14fc0    stage        35069
                               0x1d900    null         337592

Here's a bootlog, there's a "hang" at the end, no further output on
serial afterwards. Any ideas what the issue may be?

Uwe.

[Stefan Reinauer]

Can you try without cbfs? Did it work with cbfs before?

If the issue is new, can you bisect where it happened?

On Oct 1, 2009, at 3:30, Uwe Hermann  wrote:
> Hi,
>
> tried to boot-test the VIA p2500e yesterday, but tried a manual
> non-kconfig build first, and that one doesn't successfully boot  
> anymore
> and thus needs to be fixed first.
>
> The cfbs output was (I used a FILO payload):
>
> Name                           Offset     Type         Size
> fallback/payload               0x0        payload      85864
> fallback/coreboot_ram          0x14fc0    stage        35069
>                               0x1d900    null         337592
>
> Here's a bootlog, there's a "hang" at the end, no further output on
> serial afterwards. Any ideas what the issue may be?
> Uwe.
>
> http://www.hermann-uwe.de  | http://www.holsham-traders.de
> http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
> <minicom_pc2500e_cbfs_nokconfig.txt>
>
> coreboot mailing list: [e-mail]
> http://www.coreboot.org/mailman/listinfo/coreboot

[Myles Watson]

> -----Original Message-----
> From: coreboot-bounces+mylesgw=[e-mail] [mailto:coreboot-
> bounces+mylesgw=[e-mail]] On Behalf Of Uwe Hermann
> Sent: Wednesday, September 30, 2009 7:31 PM
> To: [e-mail]
> Subject: [coreboot] Boot issues (CBFS?) on VIA pc2500e
>
> Hi,
>
> tried to boot-test the VIA p2500e yesterday, but tried a manual
> non-kconfig build first, and that one doesn't successfully boot anymore
> and thus needs to be fixed first.
>
> The cfbs output was (I used a FILO payload):
>
> Name                           Offset     Type         Size
> fallback/payload               0x0        payload      85864
> fallback/coreboot_ram          0x14fc0    stage        35069
>                                0x1d900    null         337592
>
> Here's a bootlog, there's a "hang" at the end, no further output on
> serial afterwards. Any ideas what the issue may be?

It doesn't look like a place I would expect CBFS to be the issue.
> tomk is 0x80000
> tom: 20000000, high_tables_base: 1fff0000, high_tables_size: 10000

512M of RAM = 0x20000000, 64K for high tables.
...
> High Tables Base is 1fff0000.
> Copying Interrupt Routing Table to 0x000f0000... done.
> Copying Interrupt Routing Table to 0x1fff0000... done.
> Wrote the mp table end at: 000f0410 - 000f0568
> Wrote the mp table end at: 1fff0410 - 2001040e

Writing high tables above RAM!  Why is the high MP table so much larger than
the low one?
> Moving GDT to 0x20010800...ok
> Multiboot Information structure has been written.
> Writing high table forward entry at 0x00000500
> Wrote coreboot table at: 00000500 - 00000518  checksum d3dd
> New low_table_end: 0x00000518
> Now going to write high coreboot table at 0x20010c00
> rom_table_end = 0x20010c00
> Adjust low_table_end from 0x00000518 to 0x00001000 
> Adjust rom_table_end from 0x20010c00 to 0x20020000

And more writing above RAM.

I don't know that that is the cause of your trouble, but it isn't good.  An
easy thing to try would be to increase high_tables_size to 0x40000 and see
if you get anything different.  I'm surprised that your mp table is so
large.  Maybe that's where the real problem is?

Thanks,
Myles

[Stefan Reinauer]

Myles Watson wrote:
> > High Tables Base is 1fff0000.
> > Copying Interrupt Routing Table to 0x000f0000... done.
> > Copying Interrupt Routing Table to 0x1fff0000... done.
> > Wrote the mp table end at: 000f0410 - 000f0568
> > Wrote the mp table end at: 1fff0410 - 2001040e
>
> Writing high tables above RAM!  Why is the high MP table so much larger than
> the low one?

Right! Good spotting... something is reaaaally fishy here... Almost 64k
mp table vs 300 bytes.
> > Moving GDT to 0x20010800...ok

And, this alone is good for quite a crash.

Stefan

[Uwe Hermann]

On Thu, Oct 01, 2009 at 01:15:52PM +0200, Stefan Reinauer wrote:
> Myles Watson wrote:
> > > High Tables Base is 1fff0000.
> > > Copying Interrupt Routing Table to 0x000f0000... done.
> > > Copying Interrupt Routing Table to 0x1fff0000... done.
> > > Wrote the mp table end at: 000f0410 - 000f0568
> > > Wrote the mp table end at: 1fff0410 - 2001040e
> >
> > Writing high tables above RAM!  Why is the high MP table so much larger than
> > the low one?
>
> Right! Good spotting... something is reaaaally fishy here... Almost 64k
> mp table vs 300 bytes.
> > > Moving GDT to 0x20010800...ok
>
> And, this alone is good for quite a crash.

I bisected this, the commit that broke the board was r4238, where high
tables support was added. Disabling it in
src/northbridge/cn700/Config.lb results in a successful boot into FILO.

Not sure what the correct fix for working high tables support for this
board/chipset is.

Uwe.

[Carl-Daniel Hailfinger]

On 03.10.2009 19:15, Uwe Hermann wrote:
> On Thu, Oct 01, 2009 at 01:15:52PM +0200, Stefan Reinauer wrote:
> > Myles Watson wrote:
> > > > High Tables Base is 1fff0000.
> > > > Copying Interrupt Routing Table to 0x000f0000... done.
> > > > Copying Interrupt Routing Table to 0x1fff0000... done.
> > > > Wrote the mp table end at: 000f0410 - 000f0568
> > > > Wrote the mp table end at: 1fff0410 - 2001040e
> > >
> > > Writing high tables above RAM!  Why is the high MP table so much larger than
> > > the low one?
> >
> > Right! Good spotting... something is reaaaally fishy here... Almost 64k
> > mp table vs 300 bytes.
> > > > Moving GDT to 0x20010800...ok
> >
> > And, this alone is good for quite a crash.
>
> I bisected this, the commit that broke the board was r4238, where high
> tables support was added. Disabling it in
> src/northbridge/cn700/Config.lb results in a successful boot into FILO.
>
> Not sure what the correct fix for working high tables support for this
> board/chipset is.

High tables are also broken on 690G. I sent a hacky patch for this
(which is unmerged), but we need a real solution.

Regards,
Carl-Daniel

[Myles Watson]

> > > > Wrote the mp table end at: 000f0410 - 000f0568
> > > > Wrote the mp table end at: 1fff0410 - 2001040e
> > >
> > > Writing high tables above RAM!  Why is the high MP table so much larger than
> > > the low one?
> >
> > Right! Good spotting... something is reaaaally fishy here... Almost 64k
> > mp table vs 300 bytes.
> I bisected this, the commit that broke the board was r4238, where high
> tables support was added. Disabling it in
> src/northbridge/cn700/Config.lb results in a successful boot into FILO.
>
> Not sure what the correct fix for working high tables support for this
> board/chipset is.

Uwe,

Could you try this patch so we can narrow down where the problem is?

Thanks,
Myles

[Myles Watson]

> Could you try this patch so we can narrow down where the problem is?

Printing the information in hex will probably be better.

Thanks,
Myles

[Uwe Hermann]

On Tue, Oct 06, 2009 at 12:00:08PM -0600, Myles Watson wrote:
> > Could you try this patch so we can narrow down where the problem is?
>
> Printing the information in hex will probably be better.

Diff of current trunk (buildtarget, not kconfig) with and without your patch.

--- minicom_pc2500e_trunk.cap	2009-10-14 20:02:56.000000000 +0200
+++ minicom_pc2500e_mylespatch.cap	2009-10-14 20:07:33.000000000 +0200
@@ -1,6 +1,6 @@
-coreboot-2.0.0-r4774-pc2500e Wed Oct 14 19:59:59 CEST 2009 booting...
+coreboot-2.0.0-r4774M-pc2500e Wed Oct 14 20:04:27 CEST 2009 booting...
 Calibrating delay loop...
-end 2dfa6557e, start 1dac7af45
+end 2e2687035, start 1dd89cf51
 32-bit delta 4173
 calibrate_tsc 32-bit result is 4173
 clocks_per_usec: 4173
@@ -163,8 +163,8 @@
 PCI: 00:1f.0, bad id 0xffffffff
 do_pci_scan_bridge for PCI: 00:01.0
 PCI: pci_scan_bus for bus 01
-malloc Enter, size 1100, free_mem_ptr 00020000
-malloc 00020000
+malloc Enter, size 1100, free_mem_ptr 00022000
+malloc 00022000
 PCI: 01:00.0 [1106/3344] ops
 PCI: 01:00.0 [1106/3344] enabled
 PCI: 01:01.0, bad id 0xffffffff
@@ -651,9 +651,9 @@
 Check fallback/payload
 CBFS: follow chain: fff80000 + 38 + 13fe8 + align -> fff94040
 Check fallback/coreboot_ram
-CBFS: follow chain: fff94040 + 38 + 88de + align -> fff9c980
+CBFS: follow chain: fff94040 + 38 + 8961 + align -> fff9ca00
 Check 
-CBFS: follow chain: fff9c980 + 28 + 53638 + align -> ffff0000
+CBFS: follow chain: fff9ca00 + 28 + 535b8 + align -> ffff0000
 CBFS:  Could not find file pci1106,3344.rom
 rom base, size: 0
 BAD SIGNATURE 0x0 0x10
@@ -696,7 +696,23 @@
 High Tables Base is 1fff0000.
 Copying Interrupt Routing Table to 0x000f0000... done.
 Copying Interrupt Routing Table to 0x1fff0000... done.
+0: entries 0, mpc_length 2c, mpe_length 0
+1: entries 1, mpc_length 40, mpe_length 0
+2: entries 4, mpc_length 58, mpe_length 0
+3: entries 5, mpc_length 60, mpe_length 0
+4: entries 6, mpc_length 68, mpe_length 0
+5: entries 12, mpc_length c8, mpe_length 0
+6: entries 22, mpc_length 148, mpe_length 0
+7: entries 24, mpc_length 158, mpe_length 0
 Wrote the mp table end at: 000f0410 - 000f0568
+0: entries 0, mpc_length ffff, mpe_length 0
+1: entries ffff, mpc_length ffff, mpe_length ffff
+2: entries ffff, mpc_length ffff, mpe_length ffff
+3: entries ffff, mpc_length ffff, mpe_length ffff
+4: entries ffff, mpc_length ffff, mpe_length ffff
+5: entries ffff, mpc_length ffff, mpe_length ffff
+6: entries ffff, mpc_length ffff, mpe_length ffff
+7: entries ffff, mpc_length ffff, mpe_length ffff
 Wrote the mp table end at: 1fff0410 - 2001040e
 Moving GDT to 0x20010800...ok
 Multiboot Information structure has been written.

Uwe.

[Myles Watson]

> +7: entries 24, mpc_length 158, mpe_length 0
>  Wrote the mp table end at: 000f0410 - 000f0568
> +0: entries 0, mpc_length ffff, mpe_length 0
> +1: entries ffff, mpc_length ffff, mpe_length ffff

Something else is writing here.  I looked back in the log and found this :

Setting variable MTRR 3, base:  448MB, range:   32MB, type WB

It looks like you have 32MB of video memory, so the high tables have
to be lower than 480 MB for it to work.

Can you try the attached patch?  It's mostly the same debug, but it
adds the code to fix the placement of the tables.

Signed-off-by: Myles Watson

Thanks,
Myles

[Uwe Hermann]

On Wed, Oct 14, 2009 at 12:33:18PM -0600, Myles Watson wrote:
> > +7: entries 24, mpc_length 158, mpe_length 0
> >  Wrote the mp table end at: 000f0410 - 000f0568
> > +0: entries 0, mpc_length ffff, mpe_length 0
> > +1: entries ffff, mpc_length ffff, mpe_length ffff
>
> Something else is writing here.  I looked back in the log and found this :
>
> Setting variable MTRR 3, base:  448MB, range:   32MB, type WB
>
> It looks like you have 32MB of video memory, so the high tables have
> to be lower than 480 MB for it to work.

Indeed, there's "default CONFIG_VIDEO_MB = 32" in Options.lb.
> Can you try the attached patch?  It's mostly the same debug, but it
> adds the code to fix the placement of the tables.
>
> Signed-off-by: Myles Watson

Yep, works great, thanks! The board boots to FILO now.

Feel free to commit the northbridge.c fix (without the mptable debug code).

Acked-by: Uwe Hermann

We need to check all other northbridges, I assume a few others will have
the same problem.

Uwe.

[Myles Watson]

> Yep, works great, thanks! The board boots to FILO now.
>
> Feel free to commit the northbridge.c fix (without the mptable debug code).

:)
> Acked-by: Uwe Hermann

Rev 4775.
> We need to check all other northbridges, I assume a few others will have
> the same problem.

Yes.

Thanks,
Myles