Re: Your confirmation is required to leave the Linuxppc-dev mailing list
On Thu, Sep 18, 2008 at 05:25:14AM +1000, [EMAIL PROTECTED] wrote: Mailing list removal confirmation notice for mailing list Linuxppc-dev We have received a request for the removal of your email address, [EMAIL PROTECTED] from the linuxppc-dev@ozlabs.org mailing list. To confirm that you want to be removed from this mailing list, simply reply to this message, keeping the Subject: header intact. Or visit this web page: https://ozlabs.org/mailman/confirm/linuxppc-dev/4d2fbd77393f49a8596d0a0a1787e12b5e8b3a5c Or include the following line -- and only the following line -- in a message to [EMAIL PROTECTED]: confirm 4d2fbd77393f49a8596d0a0a1787e12b5e8b3a5c Note that simply sending a `reply' to this message should work from most mail readers, since that usually leaves the Subject: line in the right form (additional Re: text in the Subject: is okay). If you do not wish to be removed from this list, please simply disregard this message. If you think you are being maliciously removed from the list, or have any other questions, send them to [EMAIL PROTECTED] -- Robin Hugh Johnson Gentoo Linux Developer Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Your confirmation is required to leave the Linuxppc-dev mailing list
On Thu, Sep 18, 2008 at 05:25:14AM +1000, [EMAIL PROTECTED] wrote: Mailing list removal confirmation notice for mailing list Linuxppc-dev We have received a request for the removal of your email address, [EMAIL PROTECTED] from the linuxppc-dev@ozlabs.org mailing list. To confirm that you want to be removed from this mailing list, simply reply to this message, keeping the Subject: header intact. Or visit this web page: https://ozlabs.org/mailman/confirm/linuxppc-dev/556bf931c2e9e1baf6ec2ed2c5650056b8b2678d Or include the following line -- and only the following line -- in a message to [EMAIL PROTECTED]: confirm 556bf931c2e9e1baf6ec2ed2c5650056b8b2678d Note that simply sending a `reply' to this message should work from most mail readers, since that usually leaves the Subject: line in the right form (additional Re: text in the Subject: is okay). If you do not wish to be removed from this list, please simply disregard this message. If you think you are being maliciously removed from the list, or have any other questions, send them to [EMAIL PROTECTED] -- Robin Hugh Johnson Gentoo Linux Developer Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: going to OLS?
On Fri, Jul 18, 2008 at 08:35:36AM -0500, Kumar Gala wrote: Since OLS is next week I figured I see who around here is going. I'm always interested in putting faces to names and having a lively discussions over beer. So if your headed to OLS respond to this thread and maybe we'll have an inform PPC BoF @ a pub. I'll be there, arriving on Monday evening. -- Robin Hugh Johnson Gentoo Linux Developer Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpfGbk9rcP3k.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Access to PCI Expansion ROMs on PPC
On Sun, Nov 25, 2007 at 11:41:01AM -0800, Robin H. Johnson wrote:
I was looking around for a description of the ROM layout, and instead I
found this: http://developer.apple.com/technotes/tn/tn2000.html
It was relevant because it explicitly mentioned enabling the
PCI_COMMAND_MEMORY bit in the PCI_COMMAND register, which is NOT present
in any path of the sizing code.
...
By doing:
# dev=/sys/devices/pci0001:00/0001:00:03.0/0001:06:00.0/
# echo 1 ${dev}/enable
# echo 1 ${dev}/rom
# cat ${dev}/rom rom
The ROM is successfully returned for two of my 3 cards.
Namely, both of the ones containing x86 BIOS (sata_sil24, ATI X700).
The X1900 does still not return any ROM.
...
I broke my testing kernel temporarily, so I need a bit more testing to
see why the X1900 did not return a ROM. More on that in a couple of
hours.
(Part of this is from an IRC discussion with benh, summarized with
results here).
Thanks to some friends, I added some more PCIe cards to the test set:
The complete list is now:
x86-BIOS:
- Silicon Image, Inc. SiI 3132 Serial ATA Raid II (sata_sil24)
- ATI X700
OpenFirmware (all get relevant nodes in the device-tree after boot):
- ATI X1900
- Nvidia 6600
- Marvell SATA 7042 (sata_mv) [Sonnet Tempo SATA E4P]
For testing, I explicitly enable the device, and then try to read the
ROM. Additionally, I have some debug printk statements scattered about
rom.c and pci-sysfs.c, to detect various parts of the branching.
Additionaly per Jon's suggestion, I also have a bit of code at the end
of the sizing routine:
if (image == rom) { printk(...); return size; }
On the G5, the results are as follows:
- sata_sil24, X700, sata_mv - ROMS readable and valid.
- Nvidia 6600 - Returns junk data, changes between boots.
pci_get_rom_size fails the size decode, the first two readb() both
return 0x33
- ATI X1900 - Returns nulls. pci_get_rom_size fails here, the readbs()
return 0x00.
On an x86_64 (Core2 Duo), the results are as follows:
- sata_sil24 , X700 - ROMS readable and valid.
- sata_mv - appears in lspci, and works, but lspci does NOT show an 'Expansion
ROM' line.
- Nvidia 6600, ATI X1900 - do not show up the kernel at all, or in
lspci. The PCIe Root port [8086:29a1] is entirely missing from the
lspci output.
Regarding the sub-thread on x86 emulation, that is totally out of scope
for this. The 'AtomBIOS' of the ATI cards, consists of multiple parts (I
may have minor errors here, ask airlied if you need more
clarification):
a) Initialization code (I think arch-specific)
b) AtomBIOS script interpreter (I think arch-specific)
c) AtomBIOS scripts (card-specific, but not arch-specific)
d) Data tables (card-specific, but not arch-specific)
The AtomBIOS parts of the various drivers need data from c+d primarily,
and provide their own script interpreter, or not using the scripts, just
the data tables.
--
Robin Hugh Johnson
Gentoo Linux Developer Infra Guy
E-Mail : [EMAIL PROTECTED]
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgpaZ9ER8PI6m.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Access to PCI Expansion ROMs on PPC
On Mon, Nov 26, 2007 at 11:33:00AM -0500, Jon Smirl wrote: Did you check out the cards on x86 and ascertain that they have the standard PCI header in them? 55 AA All PCI ROMs are supposed to have that. If they are missing that the size code in the rom.c isn't going to work right. See my more recent testing summary post to the list, with the message-id of [EMAIL PROTECTED] (http://ozlabs.org/pipermail/linuxppc-dev/2007-November/046880.html) The X1900 and Nvidia OF-based cards do not turn up on the x86_64 box at all (the PCIe root node is entirely missing with them as well), and the sata_mv claims to not have a ROM, but does otherwise work. If these are OF ROM and you are booting on OF firmware, the ROM is getting run. In that case it may not be so simple to turn them back on if they have been hidden using a proprietary register. That's the quirk BenH has referred to. That's the path that I was investigating with the register stuff via airlied's avivotool. There was one register he thought about, but it didn't seem to do much. I also found some instructions to try and view the ROMs from inside OF, some I'm going to try that later today, as that will enable seeing if Linux is changing something critical. -- Robin Hugh Johnson Gentoo Linux Developer Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpB9UQ04gAVt.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Access to PCI Expansion ROMs on PPC
Following up from initial conversation with benh in #ppc64, I did a bit of testing (and then a bit more). Two PCIe cards for my testing: a) sata_sil24 eSATA (x86 BIOS) b) ATI X700 graphics (x86 BIOS) I put the card into an amd64 box, found the relevant 'rom' node ($ROM) under /sys/device/pci*, and dumped it as follows: # echo 1$ROM # cat $ROM /tmp/dump # echo 0$ROM On amd64, this produced the ROM for the cards fine (contained recognizable strings). I then repeated the same on my G5 (PM11,2), while the $ROM files have a non-zero size in sysfs (that corresponds to the size shown by lspci -vv), reading them always results in a 0-byte output. Is the PPC kernel broken? Does something in the PPC architecture forbid this? Instructions to muck with PCI code welcome. This was under 2.6.24_rc3-git1, kernel .config available if needed. Why am I trying to access the PCI ROM? To make my newer X1900 card work under at least one of the newer (ati,radeonhd,avivo) drivers, that all try to access the ATI AtomBIOS for varying data. -- Robin Hugh Johnson Gentoo Linux Developer Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpHxeypjr2ZP.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
