The short answer is, as far as I know, you can't determine this directly. But there are ways to figure it out.
First, I would pop open the case and see if any of the numbers printed on the mainboard can be used to identify 1.2a or 1.2b. There are numbers on mine, but I don't know what they mean. Otherwise, only thing I can think of is to look at what Pine64 changed about the design.
You have some things working against you. In general, ARM systems don't have automagical discovery of hardware. You install a device tree file like sun50i-a64-pinephone-1.2.dts, and that tells Linux what that hardware looks like. Otherwise, Linux doesn't know how to figure out on its own what hardware it's running on. You can actually provide the wrong device tree, and Linux will try to operate the wrong hardware.
You can check what hardware Linux thinks its running on by looking at the "model" string from the device tree in use. This is what mine says.
Notice that there is no 1.2 "a" or "b". This is because as far as Linux is concerned, there is no difference between 1.2a or 1.2b.
If I had to figure this out, this is what I would do.
On the PinePhone wiki page, you can find schematics, placement drawings, chip datasheets, change lists between revisions, and other junk. You can find photos of different PinePhone mainboard revisions on xnux.eu.
The only change I see between 1.2a and 1.2b is "A bug was fixed, where connecting a VBUS powered device lowered the screen brightness (resistor R1318 changed to NC)." This means they print the same PCB, but they just don't solder this component onto it anymore.
If that's truly the only change, then I see two options. (1) Physically take the hardware apart and see if R1318 is there, or (2) figure out if you can do something in software with PL9-DRVVBUS that would behave differently on 1.2a or 1.2b.
I'll show (1).
I attached some pictures showing how to find R1318. On 1.2a, it should be there. On 1.2b, it should be missing. The trouble is that in order to see this, you have to take things apart. And that includes removing a metal shield from the mainboard so that you can see underneath. You can do it if you're comfortable with that sort of thing and if you're careful.
Sometimes there are exceptions to the rule, and there are other ways to identify hardware versions. Again, you might see the version printed on the PCB. Or a manufacturer might program revision info into flash somewhere. Or GPIOs might be hard-coded in hardware to indicate a hardware revision to software. Or something else. I'm not aware of anything like this for PinePhone, but maybe somebody else knows something I don't.
Maybe somebody could figure out a software solution (2) that doesn't require taking the thing apart. I bet you could configure the GPIO PL9-DRVVBUS as an input, and then you could check if it responds to plugging and unplugging a charger at the USB C port. If R1318 is missing, maybe the GPIO would always report 0, but if populated, the GPIO would flip on and off. I don't know for sure. If you wanted to try this for giggles, I could try studying it some more. But I can't test it myself because I don't have both hardware versions.
Another thread asks, "are there instructions on updating V1.2a to V1.2b?" The answer is, remove resistor R1318. If you convert your 1.2a into a 1.2b, then they will both be 1.2b, so you won't forget which is which :-)
First, I would pop open the case and see if any of the numbers printed on the mainboard can be used to identify 1.2a or 1.2b. There are numbers on mine, but I don't know what they mean. Otherwise, only thing I can think of is to look at what Pine64 changed about the design.
You have some things working against you. In general, ARM systems don't have automagical discovery of hardware. You install a device tree file like sun50i-a64-pinephone-1.2.dts, and that tells Linux what that hardware looks like. Otherwise, Linux doesn't know how to figure out on its own what hardware it's running on. You can actually provide the wrong device tree, and Linux will try to operate the wrong hardware.
You can check what hardware Linux thinks its running on by looking at the "model" string from the device tree in use. This is what mine says.
Code:
pine64-pinephone# dmesg | grep model
[ 0.000000] Machine model: Pine64 PinePhone (1.2)
pine64-pinephone# cat /proc/device-tree/model; echo
Pine64 PinePhone (1.2)Notice that there is no 1.2 "a" or "b". This is because as far as Linux is concerned, there is no difference between 1.2a or 1.2b.
If I had to figure this out, this is what I would do.
On the PinePhone wiki page, you can find schematics, placement drawings, chip datasheets, change lists between revisions, and other junk. You can find photos of different PinePhone mainboard revisions on xnux.eu.
The only change I see between 1.2a and 1.2b is "A bug was fixed, where connecting a VBUS powered device lowered the screen brightness (resistor R1318 changed to NC)." This means they print the same PCB, but they just don't solder this component onto it anymore.
If that's truly the only change, then I see two options. (1) Physically take the hardware apart and see if R1318 is there, or (2) figure out if you can do something in software with PL9-DRVVBUS that would behave differently on 1.2a or 1.2b.
I'll show (1).
I attached some pictures showing how to find R1318. On 1.2a, it should be there. On 1.2b, it should be missing. The trouble is that in order to see this, you have to take things apart. And that includes removing a metal shield from the mainboard so that you can see underneath. You can do it if you're comfortable with that sort of thing and if you're careful.
Sometimes there are exceptions to the rule, and there are other ways to identify hardware versions. Again, you might see the version printed on the PCB. Or a manufacturer might program revision info into flash somewhere. Or GPIOs might be hard-coded in hardware to indicate a hardware revision to software. Or something else. I'm not aware of anything like this for PinePhone, but maybe somebody else knows something I don't.
Maybe somebody could figure out a software solution (2) that doesn't require taking the thing apart. I bet you could configure the GPIO PL9-DRVVBUS as an input, and then you could check if it responds to plugging and unplugging a charger at the USB C port. If R1318 is missing, maybe the GPIO would always report 0, but if populated, the GPIO would flip on and off. I don't know for sure. If you wanted to try this for giggles, I could try studying it some more. But I can't test it myself because I don't have both hardware versions.
Another thread asks, "are there instructions on updating V1.2a to V1.2b?" The answer is, remove resistor R1318. If you convert your 1.2a into a 1.2b, then they will both be 1.2b, so you won't forget which is which :-)