Skip to contentSkip to conversation

ps3: get firmware version

PATCH In review Geoff Levand 3 participants 4 messages Jan 27, 2007 – Jan 29, 2007

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 13/16 ps3: get firmware version

Add a new routine ps3_get_firmware_version() and use it to output the firmware version to dmesg.

---

Changed from a struct to a union and got rid of the output to /proc/cpuinfo. I'll look into arranging something in /proc/device-tree that userspace utils can query.

 arch/powerpc/platforms/ps3/setup.c |   20 ++++++++++++++++++++
 include/asm-powerpc/ps3.h          |   12 ++++++++++++
 2 files changed, 32 insertions(+)
arch/powerpc/platforms/ps3/setup.c +20 -0
@@ -32,6 +32,7 @@
 #include <asm/udbg.h>
 #include <asm/prom.h>
 #include <asm/lv1call.h>
+#include <asm/ps3.h>
 
 #include "platform.h"
 
@@ -41,6 +42,19 @@
 #define DBG(fmt...) do{if(0)printk(fmt);}while(0)
 #endif
 
+int ps3_get_firmware_version(union ps3_firmware_version *v)
+{
+	int result = lv1_get_version_info(&v->raw);
+
+	if (result) {
+		v->raw = 0;
+		return -1;
+	}
+
+	return result;
+}
+EXPORT_SYMBOL_GPL(ps3_get_firmware_version);
+
 static void ps3_power_save(void)
 {
 	/*
@@ -69,8 +83,14 @@ static void ps3_panic(char *str)
 
 static void __init ps3_setup_arch(void)
 {
+	union ps3_firmware_version v;
+
 	DBG(" -> %s:%d\n", __func__, __LINE__);
 
+	ps3_get_firmware_version(&v);
+	printk(KERN_INFO "PS3 firmware version %u.%u.%u\n", v.major, v.minor,
+		v.rev);
+
 	ps3_spu_set_platform();
 	ps3_map_htab();
 
include/asm-powerpc/ps3.h +12 -0
@@ -27,6 +27,18 @@
 #include <linux/device.h>
 #include <scsi/scsi.h>
 
+union ps3_firmware_version {
+	u64 raw;
+	struct {
+		u16 pad;
+		u16 major;
+		u16 minor;
+		u16 rev;
+	};
+};
+
+int ps3_get_firmware_version(union ps3_firmware_version *v);
+
 /**
  * struct ps3_device_id - HV bus device identifier from the system repository
  * @bus_id: HV bus id, {1..} (zero invalid)
Acked-by on v1 13/16
#1 lore raw
Quoted 4 lines · Geoff Levand

Add a new routine ps3_get_firmware_version() and use it to output the firmware version to dmesg.

Quoted 3 lines

Changed from a struct to a union and got rid of the output to /proc/cpuinfo. I'll look into arranging something in /proc/device-tree that userspace utils can query.

What's the current plan for the creating the device tree anyway? I think this should be part of the boot wrapper for the kernel in the ps3 flash, which can write the version into the flattened device tree. The second kernel then gets a copy of that through kboot.

	Arnd <><
#2 lore raw
Quoted 8 lines · Arnd Bergmann
Quoted 3 lines

Changed from a struct to a union and got rid of the output to /proc/cpuinfo. I'll look into arranging something in /proc/device-tree that userspace utils can query.

What's the current plan for the creating the device tree anyway? I think this should be part of the boot wrapper for the kernel in the ps3 flash, which can write the version into the flattened device tree. The second kernel then gets a copy of that through kboot.

Yes, that's hopefully ppossible, start with the static tree from ps3.dts then add some properties in the first stage (romboot) wrapper entry. kboot then passes that to the second stage wrapper entry, which passes it to the second stage kernel. I suppose the second stage wrapper could do some processing on it if needed. Backward compatibility with the 2.6.16 bootloader will probably need that.

To make it work, I need to arrange to do 64 bit HV calls from the 32 bit wrapper. I'm not yet entirely sure how to set that up. Any suggestions would be welcome.

-Geoff

#3 lore raw
Quoted 4 lines

To make it work, I need to arrange to do 64 bit HV calls from the 32 bit wrapper. I'm not yet entirely sure how to set that up. Any suggestions would be welcome.

You can use the ld and std instructions in 32 bits mode to load / store full 64 bits registers. So you can define wrappers for the few HV calls you need that either put all args in an array of 64 bits entries that your asm wrapper then loads in registers using "ld" (and stores back the results using std) or you can define proper wrappers per functions that "turn" the arguments into the right shape for the 64 bits call (a bit harder since 32 bits will pass 64 bits values as 2 registers, so you'd have to write them on the stack and load the combined value with ld...)

Ben.