[nycbug-talk] APU

John Baldwin jhb at freebsd.org
Mon Jan 20 15:45:28 EST 2014


On Monday 13 January 2014 18:11:15 Jared Davenport wrote:
> On 01/13/2014 03:05 PM, John Baldwin wrote:
> > On Thursday, January 09, 2014 8:03:52 pm Jared Davenport wrote:
> >> On 01/09/2014 05:50 PM, John Baldwin wrote:
> >>> On Thursday, January 09, 2014 02:40:06 PM Jared Davenport
> >>> 
> >>> wrote:
> >>>> On 01/09/2014 10:13 AM, George Rosamond wrote:
> >>>>> Jared Davenport:
> >>>>>> On 12/19/2013 10:45 AM, George Rosamond wrote:
> >>>>>>> Jared Davenport:
> >>>>>>>> On 12/18/2013 11:45 PM, Jim B. wrote:
> >>>>>>>>> * Jared Davenport <jared at thegridsource.com>
> >>>>>>>>> [2013-12-18
> >>>>>>>>> 
> >>>>>>>>> 22:57]:
> >>>>>>>>>> On 12/18/2013 09:11 PM, Jim B. wrote:
> >>>>>>>>>>> * Jared Davenport <jared at thegridsource.com>
> >>>>>>>>>>> [2013-12-18
> >>>>>>>>> 
> >>>>>>>>>>> 12:20]:
> >>>>>>>>> [snip]
> >>>>>>>>> 
> >>>>>>>>>> Thanks Jim,
> >>>>>>>>>> 
> >>>>>>>>>> I went ahead and added those lines.  Here is the
> >>>>>>>>>> verbose
> >>>>>>>>>> 
> >>>>>>>>>> output: http://pastebin.com/DUhrt8uP
> >>>>>>>>> 
> >>>>>>>>> Ok, I didn't see anything odd.  I would note
> >>>>>>>>> however that FreeBSD 10-RCx is still undergoing
> >>>>>>>>> fixes prior to release.
> >>>>>>>>> 
> >>>>>>>>> pfsense 2.1 (latest stable version) is actually
> >>>>>>>>> based on FreeBSD 8.3 according to the release
> >>>>>>>>> notes.
> >>>>>>>>> 
> >>>>>>>>> If all you want to do is get your board to run
> >>>>>>>>> FreeBSD, try
> >>>>>>>>> 
> >>>>>>>>> installing a slightly older version - 9.1, 9.2, or
> >>>>>>>>> even
> >>>>>>>>> 
> >>>>>>>>> 8.3 directly.
> >>>>>>>>> 
> >>>>>>>>> Releases for amd64 are at:
> >>>>>>>>> 
> >>>>>>>>> ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/
> >>>>>>>> 
> >>>>>>>> Good call on that.  I tried the same configuration,
> >>>>>>>> with FreeBSD 8.4, and it worked!
> >>>>>>>> 
> >>>>>>>> FreeBSD 8.4 dmesgd:
> >>>>>>>> http://www.nycbug.org/?action=dmesgd&dmesgid=2505
> >>>>>>> 
> >>>>>>> Thanks for posting JD!
> >>>>>>> 
> >>>>>>>> FreeBSD 9.2 and FreeBSD 10 were a no-go.  I'm still
> >>>>>>>> not sure why.
> >>>>>>> 
> >>>>>>> Well, the obvious to me would be using mbr v gpt.
> >>>>>>> 
> >>>>>>> What does the BIOS look like?  That could very much
> >>>>>>> matter.
> >>>>>> 
> >>>>>> That very well could be it.  The BIOS says it's coreboot
> >>>>>> 2.08.00,
> >>>>>> 
> >>>>>> specifically,
> >>>>>> 
> >>>>>> coreboot-EDK_2.08.00_20130410_221-1434-g871c820-dirty
> >>>>>> 
> >>>>>> I've added the BIOS message here:
> >>>>>> http://pastebin.com/111eTfZm
> >>>>>> 
> >>>>>>> also, for troubleshooting, I believe that these two
> >>>>>>> should help in the /etc/rc.conf:
> >>>>>>> 
> >>>>>>> rc_debug="YES" rc_info="YES"
> >>>>>>> 
> >>>>>>> I need to get my hands on one or more of these too...
> >>>>> 
> >>>>> Reraising the thread...
> >>>>> 
> >>>>> Did you order through a reseller in the US or through PC
> >>>>> Engines directly?  Pricing?
> >>>>> 
> >>>>> I have a bunch of place I could start using these in the
> >>>>> very near-term.. replacing a lot of older Soekrii and
> >>>>> Alixen.
> >>>> 
> >>>> PC-Engines directly.  This is beta hardware and isn't
> >>>> production-ready quite yet.  There will be a few changes to
> >>>> the final version.
> >>>> 
> >>>> For instance, moving from the AMD T40N to the T40E, to save
> >>>> power and heat.  The current version, I'm told, has problems
> >>>> with heat dissipation, though I've not experienced any issues
> >>>> first-hand.
> >>> 
> >>> Does 9.2 still hang on boot?  If so, can you get a verbose
> >>> dmesg from 9.2 and 'devinfo -u' and 'devinfo -rv' output from
> >>> 8.4?
> >> 
> >> Sorry for the long wait,
> >> 
> >> Here are the outputs:
> >> 
> >> devinfo -rv http://pastebin.com/QYKd6Mvq
> >> 
> >> devinfo -u http://pastebin.com/rUgPgGkm
> >> 
> >> root@:~ # uname -a FreeBSD  8.4-RELEASE FreeBSD 8.4-RELEASE #0
> >> r251259: Sun Jun  2 21:26:57 UTC 2013
> >> root at bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
> > 
> > Ahh, the BIOS is just broken.  For the pcib0 device, it is
> > claiming the entire PCI memio window as a consumer when it should
> > be a resource producer.  Note that it got this correct for I/O
> > ports, but not memory.
> > 
> > Do you have the acpidump handy?
> 
> Here you go.  http://pastebin.com/cG57Wtk8 :)

This is the busted part:

            Name (CRES, ResourceTemplate ()
            {
                IO (Decode16,
                    0x0CF8,             // Range Minimum
                    0x0CF8,             // Range Maximum
                    0x01,               // Alignment
                    0x08,               // Length
                    )
                WordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, 
EntireRange,
                    0x0000,             // Granularity
                    0x0000,             // Range Minimum
                    0x0CF7,             // Range Maximum
                    0x0000,             // Translation Offset
                    0x0CF8,             // Length
                    ,, , TypeStatic)
                WordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, 
EntireRange,
                    0x0000,             // Granularity
                    0x0D00,             // Range Minimum
                    0xFFFF,             // Range Maximum
                    0x0000,             // Translation Offset
                    0xF300,             // Length
                    ,, , TypeStatic)
                Memory32Fixed (ReadOnly,
                    0x000A0000,         // Address Base
                    0x00020000,         // Address Length
                    )
                Memory32Fixed (ReadOnly,
                    0x00000000,         // Address Base
                    0x00000000,         // Address Length
                    )
            })
            Method (_CRS, 0, NotSerialized)
            {
                CreateDWordField (CRES, 0x38, MM1B)
                CreateDWordField (CRES, 0x3C, MM1L)
                Store (TOM1, MM1B)
                ShiftLeft (0x10000000, 0x04, Local0)
                Subtract (Local0, TOM1, Local0)
                Store (Local0, MM1L)
                Return (CRES)
            }

The problem here is the Memory32Fixed resources should instead be 
ResourceProducer resources like the WordIO resources above.  Otherwise, the 
BIOS is claiming that the PCI0 device consumes those resources rather than 
making them available to child devices.  A similar entry on my laptop 
(ThinkPad x220) looks like this:

                DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, 
Cacheable, ReadWrite,
                    0x00000000,         // Granularity
                    0x000A0000,         // Range Minimum
                    0x000BFFFF,         // Range Maximum
                    0x00000000,         // Translation Offset
                    0x00020000,         // Length
                    ,, , AddressRangeMemory, TypeStatic)

I haven't looked at the new BIOS posted to the list yet, but you could search 
for 'ResourceProducer' in the acpidump to see if this has changed.  It should 
only be used for the Host-PCI bridge device.

-- 
John Baldwin



More information about the talk mailing list