From: "Michael Büsch" <mb@bu3sch.de>
To: b43-dev@lists.infradead.org
Subject: Question about SPROM Readout
Date: Sat, 11 Dec 2010 18:49:29 +0100 [thread overview]
Message-ID: <1292089769.20015.14.camel@maggie> (raw)
In-Reply-To: <4D03B736.5030301@lwfinger.net> (sfid-20101211_183847_601258_39942E98)
On Sat, 2010-12-11 at 11:39 -0600, Larry Finger wrote:
> On 12/11/2010 02:47 AM, Michael B?sch wrote:
> > On Fri, 2010-12-10 at 16:06 -0600, Larry Finger wrote:
> >> On the box with the SPROM located at 0x0800 rather than 0x1000, a readout cycle
> >> dumps data from whatever core happens to be mapped in the region 0x0 - 0xFFF. As
> >> this is usually not the ChipCommon core, the SPROM dump is usually garbage.
> >> Similarly, an SPROM write would overwrite lots of things.
> >
> > No wait. The SPROM is not mapped into the core MMIO. It is mapped right
> > above it. So a core switch does not affect it.
> > Core window goes from 0-0x800 (0r 0-0x1000 on PCI-E). Above this, the
> > SPROM is statically mapped.
>
> I see where the io_resource is mapped from 0x100 - 0x7FF, but not where it gets
> changed for PCIe.
We request and map all PCI regions with the sizes that the PCI subsystem
autodetects. So there is no need to "change" something for PCIe.
Note that the region we're interested in is the memory region,
not the I/O region.
> This is the SPROM dump I get on the box in question:
>
> SPROM=$(find /sys -name ssb_sprom)
> cat $SPROM
> DE0168000187570600000000C0000A001400000080000F0047004700830164003009C0FC00000
> 00000000000000001030001000002000200010004000400000002000000030002000E00470000
> 28000001000500C0FCE005FFFFFFFF0A0011010800000000000000DB48000000000000FAAB000
> 00100000000008904B9C98887060010270100E0320000000000000702000000001A04FA000A0E
> 0B090E0200000100000000003F01FFFF0000FC03427B0200900700000000B80B0080140414040
> 0000000FA000000000000004C1DE204AA000000F401410000000000000000009B0800000000A2
> 04000000000000000000000000000000000000000000000000000000004E002A003905D10AB70
> 35517A92A6004420085030000000085033505B8005B0411000300B602640A0000320200001C08
> 46000000000000000000000000000000000000000000000000000000000000000000000000000
> 000010000004252434D5F544553545F5353494400000000000000000000000000000000000039
> 00000050000000C0FC00000000000000000000000000000000000000000000000000000000000
> 000000000000000000000000000000000
>
> These are clearly not the data from a real SPROM.
Yeah, well. Maybe they simply relocated the SPROM again or changed the
way it has to be accessed in another way. Or there simply is a bug in
all that crazy SPROM detect logic that was added for PCIe devices.
--
Greetings Michael.
prev parent reply other threads:[~2010-12-11 17:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-10 22:06 Question about SPROM Readout Larry Finger
2010-12-11 8:47 ` Michael Büsch
2010-12-11 17:39 ` Larry Finger
2010-12-11 17:49 ` Michael Büsch [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1292089769.20015.14.camel@maggie \
--to=mb@bu3sch.de \
--cc=b43-dev@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).