AMD Tilapia / simnow: endless looping in function pci_scan_bus

[Scott]

Hello,

When booting the AMD Tilapia coreboot BIOS on simnow I encounter
an endless loop in pci_scan_bus(). The reason is that pci_scan_bus
expects a valid argument for max_devfn, yet receives 0xFFFFFFFF.

The origin of the invalid max_devfn argument is line 596 of
hypertransport.c:

max = pci_scan_bus(bus, 0x00, ((next_unitid-1) << 3)|7, max);

With my setup, next_unitid is zero, which causes a bad argument
to be passed to pci_scan_bus. As a work-around, I change the code
to recognize and handle this case by passing 0xFF (all devices).

Does anyone else encounter this situation on AMD boards? I ask
because I am using simnow in place of real hardware.

Thanks,
Scott

[Myles Watson]

On Wed, Sep 1, 2010 at 12:50 PM, Scott  wrote:
> Hello,
>
> When booting the AMD Tilapia coreboot BIOS on simnow I encounter
> an endless loop in pci_scan_bus(). The reason is that pci_scan_bus
> expects a valid argument for max_devfn, yet receives 0xFFFFFFFF.
>
> The origin of the invalid max_devfn argument is line 596 of
> hypertransport.c:
>
> max = pci_scan_bus(bus, 0x00, ((next_unitid-1) << 3)|7, max);
>
> With my setup, next_unitid is zero, which causes a bad argument
> to be passed to pci_scan_bus. As a work-around, I change the code
> to recognize and handle this case by passing 0xFF (all devices).
>
> Does anyone else encounter this situation on AMD boards? I ask
> because I am using simnow in place of real hardware.

Juhana Helovuo reported this in the thread "Porting to Asus M4A785-M".

Thanks,
Myles

AMD Tilapia / simnow: endless looping in functionpci_scan_bus

[Scott]

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Myles Watson
Sent: Wednesday, September 01, 2010 02:22 PM
To: Scott
Cc: [e-mail]
Subject: Re: [coreboot] AMD Tilapia / simnow: endless looping in functionpci_scan_bus

On Wed, Sep 1, 2010 at 12:50 PM, Scott  wrote:
> Hello,
>
> When booting the AMD Tilapia coreboot BIOS on simnow I encounter
> an endless loop in pci_scan_bus(). The reason is that pci_scan_bus
> expects a valid argument for max_devfn, yet receives 0xFFFFFFFF.
>
> The origin of the invalid max_devfn argument is line 596 of
> hypertransport.c:
>
> max = pci_scan_bus(bus, 0x00, ((next_unitid-1) << 3)|7, max);
>
> With my setup, next_unitid is zero, which causes a bad argument
> to be passed to pci_scan_bus. As a work-around, I change the code
> to recognize and handle this case by passing 0xFF (all devices).
>
> Does anyone else encounter this situation on AMD boards? I ask
> because I am using simnow in place of real hardware.

Juhana Helovuo reported this in the thread "Porting to Asus M4A785-M".

Thanks,
Myles

AMD Tilapia / simnow: endless looping in functionpci_scan_bus

[Juhana Helovuo]

1.9.2010 23:00, Scott kirjoitti:
> Thanks Myles. That problem description and work-around matches my
> situation exactly. Even if the bad value passed to pci_scan_bus is
> only a side-effect of another problem, special handling for it should
> be considered in order to simplify debugging.
>
> The same thead covers another problem I encounter with Tilapia. When
> I enable ACPI table generation, an overlap causes the seabios payload
> to overwrite the ACPI tables. I temporarily worked around this problem
> by deselecting GFXUMA. I am using PCI video so I can boot with no uma.

Hello,

I had similar problems recently. I did a patch for Asus M4A785-M, which 
is derived from the AMD Tilapia port.

The patch can be found at
http://www.coreboot.org/pipermail/coreboot/2010-August/059989.html

There is another patch that sets up UMA and coreboot/ACPI/etc. tables 
as reserved areas in the multiboot tables. Without this patch booting 
with Grub to Linux suffers from the same problem of overwriting tables.

http://www.coreboot.org/pipermail/coreboot/2010-August/060014.html

I do not know if these are going to be integrated to the Coreboot trunk, 
but currently they are available as patch files.

How does SeaBIOS detect which RAM is usable and which is not? Maybe the 
memory conflict with UMA and ACPI tables could be avoided in a similar 
manner?

Best regards,
Juhana Helovuo

AMD Tilapia / simnow: endless looping in functionpci_scan_bus

[Warren Turkal]

Who's responsible for the tilapia port? I am trying to assign this to
someone in the patchwork system, but I don't know who to assign it to.

Also, is there a testbed that can run this change to make sure it
doesn't break non-tilapia systems?

Thanks,
wt

On Thu, Sep 2, 2010 at 12:18 AM, Juhana Helovuo  wrote:
> 1.9.2010 23:00, Scott kirjoitti:
> > Thanks Myles. That problem description and work-around matches my
> > situation exactly. Even if the bad value passed to pci_scan_bus is
> > only a side-effect of another problem, special handling for it should
> > be considered in order to simplify debugging.
> >
> > The same thead covers another problem I encounter with Tilapia. When
> > I enable ACPI table generation, an overlap causes the seabios payload
> > to overwrite the ACPI tables. I temporarily worked around this problem
> > by deselecting GFXUMA. I am using PCI video so I can boot with no uma.
>
> Hello,
>
> I had similar problems recently. I did a patch for Asus M4A785-M, which is
> derived from the AMD Tilapia port.
>
> The patch can be found at
> http://www.coreboot.org/pipermail/coreboot/2010-August/059989.html
>
> There is another patch that sets up UMA and coreboot/ACPI/etc. tables as
> reserved areas in the multiboot tables. Without this patch booting with Grub
> to Linux suffers from the same problem of overwriting tables.
>
> http://www.coreboot.org/pipermail/coreboot/2010-August/060014.html
>
> I do not know if these are going to be integrated to the Coreboot trunk, but
> currently they are available as patch files.
>
> How does SeaBIOS detect which RAM is usable and which is not? Maybe the
> memory conflict with UMA and ACPI tables could be avoided in a similar
> manner?
>
> Best regards,
> Juhana Helovuo

AMD Tilapia / simnow: endless looping in functionpci_scan_bus

[Myles Watson]

On Fri, Sep 3, 2010 at 9:12 PM, Warren Turkal  wrote:
> Who's responsible for the tilapia port?

In general we haven't made specific people responsible for ports.
Generally there is someone who cares more because they use it.  That
may be you :)

Thanks,
Myles

AMD Tilapia / simnow: endless looping infunctionpci_scan_bus

[Bao, Zheng]

Please see the log when the mahogany_fam10 was created. That is r5221.
That is the problem located in folder amdht, which is about HT
initialization of Family 10.

Zheng
> -----Original Message-----
> From: [e-mail]

[mailto:[e-mail]]
> On Behalf Of Warren Turkal
> Sent: Saturday, September 04, 2010 11:12 AM
> To: Juhana Helovuo
> Cc: Scott; [e-mail]
> Subject: Re: [coreboot] AMD Tilapia / simnow: endless looping
> infunctionpci_scan_bus
>
> Who's responsible for the tilapia port? I am trying to assign this to
> someone in the patchwork system, but I don't know who to assign it to.
>
> Also, is there a testbed that can run this change to make sure it
> doesn't break non-tilapia systems?
>
> Thanks,
> wt
>
> On Thu, Sep 2, 2010 at 12:18 AM, Juhana Helovuo  wrote:
> > 1.9.2010 23:00, Scott kirjoitti:
> > > Thanks Myles. That problem description and work-around matches my
> > > situation exactly. Even if the bad value passed to pci_scan_bus is
> > > only a side-effect of another problem, special handling for it

should
> > > be considered in order to simplify debugging.
> > >
> > > The same thead covers another problem I encounter with Tilapia.

When
> > > I enable ACPI table generation, an overlap causes the seabios

payload
> > > to overwrite the ACPI tables. I temporarily worked around this

problem
> > > by deselecting GFXUMA. I am using PCI video so I can boot with no

uma.
> > Hello,
> >
> > I had similar problems recently. I did a patch for Asus M4A785-M,

which
> is
> > derived from the AMD Tilapia port.
> >
> > The patch can be found at
> > http://www.coreboot.org/pipermail/coreboot/2010-August/059989.html
> >
> > There is another patch that sets up UMA and coreboot/ACPI/etc.

tables as
> > reserved areas in the multiboot tables. Without this patch booting

with
> Grub
> > to Linux suffers from the same problem of overwriting tables.
> >
> > http://www.coreboot.org/pipermail/coreboot/2010-August/060014.html
> >
> > I do not know if these are going to be integrated to the Coreboot

trunk,
> but
> > currently they are available as patch files.
> >
> > How does SeaBIOS detect which RAM is usable and which is not? Maybe

the
> > memory conflict with UMA and ACPI tables could be avoided in a

similar
> > manner?
> >
> > Best regards,
> > Juhana Helovuo

AMD Tilapia / simnow: endless looping in functionpci_scan_bus

[Myles Watson]

> I had similar problems recently. I did a patch for Asus M4A785-M, which is
> derived from the AMD Tilapia port.
>
> The patch can be found at
> http://www.coreboot.org/pipermail/coreboot/2010-August/059989.html

It would be a lot easier to review if you split the patch into smaller pieces.

1. Use svn cp to copy the tilapia board directory for your board
2. Make the changes so it works for your board (just copy the files
you already have from another location)
3. svn diff

This will produce a patch with only your changes.

Split out work-around patches as well.  Something is broken for your
board, and that needs to be fixed, but I don't think we should change
the PCI scan code.
> There is another patch that sets up UMA and coreboot/ACPI/etc. tables as
> reserved areas in the multiboot tables. Without this patch booting with Grub
> to Linux suffers from the same problem of overwriting tables.
>
> http://www.coreboot.org/pipermail/coreboot/2010-August/060014.html
>
> I do not know if these are going to be integrated to the Coreboot trunk, but
> currently they are available as patch files.

To be committed, patches need to be Signed-off and Acked.  If you've
tested the multiboot patch and it works for you, you could send an
Acked-by: to the list, and it will most likely get committed.  If you
still have other changes that you'd like to make, then submit another
version of the patch with your Signed-off-by: tag.
> How does SeaBIOS detect which RAM is usable and which is not? Maybe the
> memory conflict with UMA and ACPI tables could be avoided in a similar
> manner?

SeaBIOS reads the Coreboot tables.

Thanks,
Myles

[PATCH] Add support for Asus M4A785-M, with build instructions

[Juhana Helovuo]

On Sat, 2010-09-04 at 15:23 -0600, Myles Watson wrote:
> It would be a lot easier to review if you split the patch into smaller pieces.
> Use svn cp to copy the tilapia board directory for your board
> Make the changes so it works for your board (just copy the files
>
> you already have from another location)
> 3. svn diff
>
> This will produce a patch with only your changes.
>
> Split out work-around patches as well.  Something is broken for your
> board, and that needs to be fixed, but I don't think we should change
> the PCI scan code.

Ok, this makes sense. The previous patch I sent was unnecessarily large.

There are now three smaller patches attached:

(1) Changes specific to this board. Fairly small changes from AMD
Tilapia. Requires (2) to work.

(2) Small, hopefully non-intrusive, patches to generic code that are
required to prevent hangups/crashes on this board.

(3) Multiboot table patch required to get UMA and high coreboot tables
locations to Grub and Linux. Independent of (1) and (2).

Signed-off-by: Juhana Helovuo

I tested appying these patches, building and flashing using the
following procedure:

1. Check out Coreboot from SVN
 % svn co svn://coreboot.org/coreboot/trunk coreboot

* The revision used here was 5792.

2. chdir to coreboot

3. svn cp src/mainboard/amd/tilapia_fam10 src/mainboard/asus/m4a785-m

4. patch

% patch -p1 < ../patches/asus-m4a785m-small-patch.patch
 % patch -p1 < ../patches/multiboot-table-after-cb-table-r5756-v2.patch
 % patch -p1 < ../patches/generic-code-patches-for-m4a785m.patch

5. make menuconfig

* Select mainboard vendor & model
 * ROM chip size 1 MByte

* Select: Use VGA console once initialized
 * Select Use onboard VGA as primary video device

* Add payload (grub2 and coreinfo tested to work)

* Add VGA BIOS:

The BIOS for the on-board ATI Radeon HD 4200 can be extracted with dd
from /dev/mem as shown in http://www.coreboot.org/VGA_support . The
bios_extract utility can extract some other option ROMs, but it crashes
before it gets the VGA ROM.

* If on-board VGA BIOS is added, set VGA device PCI IDs to "1002,9710"

6. make

* The result should be a working coreboot.rom.

This procedure worked for me. Can someone acknowledge that the patches
do not break anything?

The changes required in generic code are a bit ugly, but I am not
familiar enough with Coreboot to figure out any neater solution.

Best regards,
Juhana Helovuo

[PATCH] Add support for Asus M4A785-M, with build instructions

[Myles Watson]

> There are now three smaller patches attached:

Much nicer!  Thanks.
> (1) Changes specific to this board. Fairly small changes from AMD
> Tilapia. Requires (2) to work.
> From your mainboard's Kconfig:

+config DIMM_SUPPORT
+	hex
+	default 0x0004
+	depends on CPU_AMD_SOCKET_AM3

This really worries me.  You shouldn't need to change the type of memory on
the Socket.  I looked at your board online, and they suggest that your board
supports socket AM2, AM2+, and AM3.  That seems like it breaks our model.  I
thought AM2 was DDR2 and AM3 was DDR3.

Anyone want to chip in here?  Marc? Stefan? ... Anyone?
> (2) Small, hopefully non-intrusive, patches to generic code that are
> required to prevent hangups/crashes on this board.

I think these could be reduced further.  I'd like to see the ISA fix be a
Kconfig option in the sb700 Kconfig file.  Something like
SB700_SKIP_ISA_DMA_INIT which defaults to n.  Then in your board you select
it.  It shouldn't print anything at all when it isn't selected, and probably
just one "skipping" message when it is selected.

Returning the value from the watchdog was good for debugging, but I don't
think it's something that should be committed.

In general, the fewer changes the better!
> (3) Multiboot table patch required to get UMA and high coreboot tables
> locations to Grub and Linux. Independent of (1) and (2).

Do we need to dump the tables?  It seems like generating them from the
coreboot tables is nearly trivial.  After you've debugged your code, I don't
think anyone needs to see that debug output.

Thanks,
Myles

[PATCH] Add support for Asus M4A785-M, with build instructions

[Juhana Helovuo]

9.9.2010 22:39, Myles Watson kirjoitti:
> > There are now three smaller patches attached:
>
> Much nicer!  Thanks.
> > (1) Changes specific to this board. Fairly small changes from AMD
> > Tilapia. Requires (2) to work.
>
> From your mainboard's Kconfig:
>
> +config DIMM_SUPPORT
> hex
> default 0x0004
> depends on CPU_AMD_SOCKET_AM3
>
> This really worries me.  You shouldn't need to change the type of memory on
> the Socket.  I looked at your board online, and they suggest that your board
> supports socket AM2, AM2+, and AM3.  That seems like it breaks our model.  I
> thought AM2 was DDR2 and AM3 was DDR3.

Sorry to break your design, but that was what I had to do to get the RAM 
working. I can confirm that I am using DDR2 memory and the CPU is this:

http://products.amd.com/en-na/DesktopCPUDetail.aspx?id=615
> In general, the fewer changes the better!

I agree. The patches could be smaller and neater.

However, I cannot hold on to this board for arbitrarily long, since I 
should put it to production use now that Coreboot is working.  I will 
see what I can do to reduce these patches further, if I just find a 
suitable slot of time.

Best regards,
Juhana Helovuo

[PATCH] Add support for Asus M4A785-M, with build instructions

[Myles Watson]

> > From your mainboard's Kconfig:
> >
> > +config DIMM_SUPPORT
> > hex
> > default 0x0004
> > depends on CPU_AMD_SOCKET_AM3
> >
> > This really worries me.  You shouldn't need to change the type of memory
> > on
> > the Socket.  I looked at your board online, and they suggest that your
> > board
> > supports socket AM2, AM2+, and AM3.  That seems like it breaks our model.
> >  I
> > thought AM2 was DDR2 and AM3 was DDR3.
>
> Sorry to break your design, but that was what I had to do to get the RAM
> working.

I wasn't offended.  I just want to improve the design if it's broken.
> I can confirm that I am using DDR2 memory and the CPU is this:
>
> http://products.amd.com/en-na/DesktopCPUDetail.aspx?id=615

Thanks.
> > In general, the fewer changes the better!
>
> I agree. The patches could be smaller and neater.
>
> However, I cannot hold on to this board for arbitrarily long, since I should
> put it to production use now that Coreboot is working.  I will see what I
> can do to reduce these patches further, if I just find a suitable slot of
> time.

I appreciate the work that you've done.  I've attached patches that
I've reduced a little more.  Would you test/review them?  If they
work, I'll commit them.

Signed-off-by: Myles Watson

Thanks,
Myles

[PATCH] Add support for Asus M4A785-M, with build instructions

[Myles Watson]

Would you mind applying these and testing too?

Signed-off-by: Myles Watson

Thanks,
Myles

[PATCH] Add support for Asus M4A785-M, with build instructions

[Juhana Helovuo]

On Fri, 2010-09-10 at 09:54 -0600, Myles Watson wrote:
> I appreciate the work that you've done.  I've attached patches that
> I've reduced a little more.  Would you test/review them?  If they
> work, I'll commit them.
>
> Signed-off-by: Myles Watson

Thanks for your trouble of cleaning up.

I tried the patches you sent just now. Since Socket/DIMM type
configuration was changed in rev 5800, I tested these against rev 5799.

Patching and building is ok. Booting looks fine, Grub2 comes up and
loads Linux. However, Linux cannot find SATA controller, and because of
that, the booting fails. (Although Grub just loaded the kernel and
initrd from SATA.)

Linux gives the following complaints that I have not seen before:

[    1.620006] pci 0000:00:12.0: OHCI: BIOS handoff failed (BIOS bug?) ffffffff
[    2.424005] pci 0000:00:12.1: OHCI: BIOS handoff failed (BIOS bug?) ffffffff
[    2.431115] pci 0000:00:12.2: EHCI: unrecognized capability 02
[    3.236005] pci 0000:00:13.0: OHCI: BIOS handoff failed (BIOS bug?) ffffffff
[    4.040005] pci 0000:00:13.1: OHCI: BIOS handoff failed (BIOS bug?) ffffffff
[    4.047129] pci 0000:00:13.2: EHCI: unrecognized capability 02
[    4.852005] pci 0000:00:14.5: OHCI: BIOS handoff failed (BIOS bug?) ffffffff
...
[    6.524010] ahci 0000:00:11.0: controller reset failed (0xffffffff)
[    6.530976] ahci 0000:00:11.0: PCI INT A disabled
[    6.536129] ahci: probe of 0000:00:11.0 failed with error -5
[    6.542497] ehci_hcd 0000:00:13.2: PCI INT B -> GSI 19 (level, low) -> IRQ 19
[    6.550296] ehci_hcd 0000:00:13.2: EHCI Host Controller
[    6.556084] ehci_hcd 0000:00:13.2: new USB bus registered, assigned bus number 1
[    6.574836] ehci_hcd 0000:00:13.2: can't setup
[    6.579802] ehci_hcd 0000:00:13.2: USB bus 1 deregistered
[    6.585744] ehci_hcd 0000:00:13.2: PCI INT B disabled
[    6.591369] ehci_hcd 0000:00:13.2: init 0000:00:13.2 fail, -110
[    6.597905] ehci_hcd: probe of 0000:00:13.2 failed with error -110
[    6.608546] sd 1:0:0:0: [sda] 15621984 512-byte logical blocks: (7.99 GB/7.44 GiB)
[    6.613539] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    6.613588] ohci_hcd 0000:00:12.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    6.613609] ohci_hcd 0000:00:12.0: OHCI Host Controller
[    6.613626] ohci_hcd 0000:00:12.0: new USB bus registered, assigned bus number 1
[    6.645506] sd 1:0:0:0: [sda] Write Protect is off
[    6.650743] sd 1:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't suppoA
[    6.660904]  sda: sda1 sda2 < sda5 >
[    6.666370] sd 1:0:0:0: [sda] Attached SCSI disk
[    6.676803] sr0: scsi3-mmc drive: 0x/48x cd/rw xa/form2 cdda tray
[    6.683415] Uniform CD-ROM driver Revision: 3.20
[    6.692578] sd 1:0:0:0: Attached scsi generic sg0 type 0
[    6.698631] sr 1:0:1:0: Attached scsi generic sg1 type 5
[   14.612006] ohci_hcd 0000:00:12.0: USB HC takeover failed!  (BIOS/SMM bug)
[   14.619415] ohci_hcd 0000:00:12.0: can't setup
[   14.624264] ohci_hcd 0000:00:12.0: USB bus 1 deregistered
[   14.630262] ohci_hcd 0000:00:12.0: PCI INT A disabled
[   14.635877] ohci_hcd 0000:00:12.0: init 0000:00:12.0 fail, -16
[   14.642263] ohci_hcd: probe of 0000:00:12.0 failed with error -16
[   14.649008] ohci_hcd 0000:00:12.1: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[   14.656848] ohci_hcd 0000:00:12.1: OHCI Host Controller
[   14.662579] ohci_hcd 0000:00:12.1: new USB bus registered, assigned bus number 1
[   22.668004] ohci_hcd 0000:00:12.1: USB HC takeover failed!  (BIOS/SMM bug)
[   22.675470] ohci_hcd 0000:00:12.1: can't setup
[   22.680290] ohci_hcd 0000:00:12.1: USB bus 1 deregistered
[   22.686118] ohci_hcd 0000:00:12.1: PCI INT A disabled
[   22.691742] ohci_hcd 0000:00:12.1: init 0000:00:12.1 fail, -16
[   22.698163] ohci_hcd: probe of 0000:00:12.1 failed with error -16
[   22.704836] ohci_hcd 0000:00:13.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[   22.712793] ohci_hcd 0000:00:13.0: OHCI Host Controller
[   22.718541] ohci_hcd 0000:00:13.0: new USB bus registered, assigned bus number 1
[   30.724004] ohci_hcd 0000:00:13.0: USB HC takeover failed!  (BIOS/SMM bug)
[   30.731397] ohci_hcd 0000:00:13.0: can't setup
[   30.736232] ohci_hcd 0000:00:13.0: USB bus 1 deregistered
[   30.742097] ohci_hcd 0000:00:13.0: PCI INT A disabled
[   30.747628] ohci_hcd 0000:00:13.0: init 0000:00:13.0 fail, -16
[   30.754124] ohci_hcd: probe of 0000:00:13.0 failed with error -16
[   30.760783] ohci_hcd 0000:00:13.1: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[   30.768663] ohci_hcd 0000:00:13.1: OHCI Host Controller
[   30.774442] ohci_hcd 0000:00:13.1: new USB bus registered, assigned bus number 1
[   38.796004] ohci_hcd 0000:00:13.1: USB HC takeover failed!  (BIOS/SMM bug)
[   38.803405] ohci_hcd 0000:00:13.1: can't setup
[   38.808328] ohci_hcd 0000:00:13.1: USB bus 1 deregistered
[   38.814324] ohci_hcd 0000:00:13.1: PCI INT A disabled
[   38.819841] ohci_hcd 0000:00:13.1: init 0000:00:13.1 fail, -16
[   38.826275] ohci_hcd: probe of 0000:00:13.1 failed with error -16
[   38.833071] ohci_hcd 0000:00:14.5: PCI INT C -> GSI 18 (level, low) -> IRQ 18
[   38.840934] ohci_hcd 0000:00:14.5: OHCI Host Controller
[   38.846780] ohci_hcd 0000:00:14.5: new USB bus registered, assigned bus number 1
[   46.852004] ohci_hcd 0000:00:14.5: USB HC takeover failed!  (BIOS/SMM bug)
[   46.859434] ohci_hcd 0000:00:14.5: can't setup
[   46.864302] ohci_hcd 0000:00:14.5: USB bus 1 deregistered
[   46.870312] ohci_hcd 0000:00:14.5: PCI INT C disabled
[   46.875922] ohci_hcd 0000:00:14.5: init 0000:00:14.5 fail, -16
[   46.882333] ohci_hcd: probe of 0000:00:14.5 failed with error -16
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.

It seems that also the USB controller initialization fails, although I did not test if it worked.

Aside from the AHCI/OHCI/EHCI -drivers failing, the boot logs seem to be the same as before.

I tried to look at the patch code, but could not figure out why this is happening.

Best regards,
Juhana Helovuo

[PATCH] Add support for Asus M4A785-M, with build instructions

[Myles Watson]

> I tried the patches you sent just now. Since Socket/DIMM type
> configuration was changed in rev 5800, I tested these against rev 5799.
>
> Patching and building is ok. Booting looks fine, Grub2 comes up and
> loads Linux. However, Linux cannot find SATA controller, and because of
> that, the booting fails. (Although Grub just loaded the kernel and
> initrd from SATA.)
>
> Linux gives the following complaints that I have not seen before:
> It seems that also the USB controller initialization fails, although I did not test if it worked.
> Aside from the AHCI/OHCI/EHCI -drivers failing, the boot logs seem to be the same as before.
>
> I tried to look at the patch code, but could not figure out why this is happening.

So it works with my updated patch, but not with the uma & reserved
patches?  Or does it not work at all?  Does it still work with your
previous patch set?

Could you send a full log with the last working version and the first
broken version from this list?

1. Your original patches
2. 5799 + my board patch
3. 2 + uma.diff
4. 3 + reserved.diff

uma.diff & reserved.diff should be independent, so you could try
2+reserved.diff also

I attached an updated patch that should apply to 5800 if that's easier/better.

Thanks,
Myles

[PATCH] Add support for Asus M4A785-M, with build instructions

[Juhana Helovuo]

On Sat, 2010-09-11 at 07:03 -0600, Myles Watson wrote:
> > I tried to look at the patch code, but could not figure out why this is happening.
>
> So it works with my updated patch, but not with the uma & reserved
> patches?  Or does it not work at all?  Does it still work with your
> previous patch set?

Hmm. Sorry about the ambiguity.

Booting works ok with 5792 + my original patches.

SATA controller failure was with 5799 + your simplified patches.

I did not yet get to test uma.diff and reserved.diff at all.

I'll do some more testing to narrow down where the failure is. The first
thing to check would be to see if the cause was in different patches
(original vs. simplified) or trunk code (5792 vs. 5799).

Then I'll see what uma.diff and reserved.diff do.

Best regards,
Juhana Helovuo

[PATCH] Add support for Asus M4A785-M, with build instructions

[Marc Jones]

On Thu, Sep 9, 2010 at 1:39 PM, Myles Watson  wrote:
> > There are now three smaller patches attached:
>
> Much nicer!  Thanks.
> > (1) Changes specific to this board. Fairly small changes from AMD
> > Tilapia. Requires (2) to work.
>
> From your mainboard's Kconfig:
>
> +config DIMM_SUPPORT
> hex
> default 0x0004
> depends on CPU_AMD_SOCKET_AM3
>
> This really worries me.  You shouldn't need to change the type of memory on
> the Socket.  I looked at your board online, and they suggest that your board
> supports socket AM2, AM2+, and AM3.  That seems like it breaks our model.  I
> thought AM2 was DDR2 and AM3 was DDR3.

That used to be true, but you can have AM3(AM2+) with DDR2, as with
this board. Yeah, thanks AMD..... :) Connecting the socket to the
memory type was convenient, but I was never really comfortable with
it. It may be time to disconnect them.

Marc

[PATCH] Add support for Asus M4A785-M, with build instructions

[Myles Watson]

On Fri, Sep 10, 2010 at 9:30 AM, Marc Jones  wrote:
> On Thu, Sep 9, 2010 at 1:39 PM, Myles Watson  wrote:
> > > There are now three smaller patches attached:
> >
> > Much nicer!  Thanks.
> > > (1) Changes specific to this board. Fairly small changes from AMD
> > > Tilapia. Requires (2) to work.
> >
> > From your mainboard's Kconfig:
> >
> > +config DIMM_SUPPORT
> > hex
> > default 0x0004
> > depends on CPU_AMD_SOCKET_AM3
> >
> > This really worries me.  You shouldn't need to change the type of memory on
> > the Socket.  I looked at your board online, and they suggest that your board
> > supports socket AM2, AM2+, and AM3.  That seems like it breaks our model.  I
> > thought AM2 was DDR2 and AM3 was DDR3.
>
> That used to be true, but you can have AM3(AM2+) with DDR2, as with
> this board. Yeah, thanks AMD..... :) Connecting the socket to the
> memory type was convenient, but I was never really comfortable with
> it. It may be time to disconnect them.

Thanks Marc.  I didn't realize that we'd gotten ourselves into a mess there.

Thanks,
Myles