Librem 5 running postmarketos phosh screen up side down

By Newbyte on 2022-08-03T01:01:54

added category::device device-purism-librem5 release-edge release-v21.12 release-v22.06 labels

I have just installed 20220921-0658-postmarketOS-v22.06-phosh-18-purism-librem5-installer.img.xz and still no joy with up-side-down display, same as previous Also unable to get external monitor connected via Baseus usb hub - this works with Purism PureOS

By bja-au on 2022-10-01T06:36:55

weird, it's fine for me...

is the orientation correct on PureOS? kinda sounds like maybe a sensor problem...

By clayton craft on 2022-10-01T06:36:55

Hi

It's only in Postmarketos I have the problem - it is fine in PureOS :(

Regards

Brian Anderson briananderson@fastmail.com.au

...

====================================================================================== Law of Probability... The probability of being watched is directly proportional to the stupidity of your act.

On 1/10/22 2:36 pm, clayton craft (@craftyguy) wrote:

GitLab

clayton craft https://gitlab.com/craftyguy commented on a discussion #1643 (comment 1121262939):

weird, it's fine for me...

is the orientation correct on PureOS? kinda sounds like maybe a sensor problem...

— Reply to this email directly or view it on GitLab #1643 (comment 1121262939). You're receiving this email because of your account on gitlab.com https://gitlab.com. Unsubscribe https://gitlab.com/-/sent_notifications/REDACTED/unsubscribe from this thread · Manage all notifications https://gitlab.com/-/profile/notifications · Help https://gitlab.com/help

By bja-au on 2022-10-01T06:43:10

Sounds like you're using an incorrect device tree for your device. Phones from Birch and Chestnut batches (imx8mq-librem5-r2) had their sensors oriented in a different way than later ones. With Evergreen, you want to use imx8mq-librem5-r4 (or r3 for Dogwood).

By dos on 2022-10-24T06:08:19

we should be using the right dtb... unless this mechanism broke: https://gitlab.postmarketos.org/postmarketos/pmaports/-/blob/fb9bc89df802cb7cd64c33709c53df53ff81e44b/device/main/device-purism-librem5/uboot-script.cmd#L26

By clayton craft on 2022-10-24T06:08:19

oh, or is there a chance that they have an evergreen device that doesn't have the fuses popped so that it's not showing up as the correct board rev?

By clayton craft on 2022-10-24T06:08:57

Yes, that mechanism isn't reliable. ~~At some point NXP made these fuses unavailable and forgot to change the docs...~~ (actually I'm not 100% sure now, let me verify that) You should fallback to Evergreen, and add cases for r1 and r2 to the script. Ideally, there would be a way for the user to override that choice. Users with earlier revisions from before those fuses were being popped pre-shipment can always do it themselves.

By dos on 2022-10-24T08:15:07

Also, there are phones out there with 5 as board_rev and those should be booted with Evergreen's device tree too.

By dos on 2022-10-24T08:14:07

ughhh, ok. I thought someone told me once that you should not boot the evergreen dtb on earlier revs (birch, chestnut, dogwood)... could those be damaged?

By clayton craft on 2022-10-24T17:27:15

Well, you should not run mismatched device trees. But if you do, then it doesn't really matter which way it goes that much. Some things are going to be broken until you correct it, but there's nothing really hardware-threatening there. The worst things are that Birch & Chestnut use a slightly higher maximum charging current than the rest, and Evergreen uses a slightly higher maximum backlight current than the rest. I wouldn't advice to run it daily for months like that, but it won't really hurt if you get a wrong dts and figure that out, say, a few days later.

Other than that, you're likely going to have issues sensor rotation (this issue), cameras, external screens, proximity sensor, smart card reader and battery gauge readings when using a wrong device tree. LCD timings differ a bit in Evergreen too, although I haven't seen it making a visible difference in practice. In case of Dogwood devices, you'll also miss workaround for the sudden shutdown issue.

Since there's much more Evergreens out there than any other batch, I'd say that it's the most reasonable to default to Evergreen when there's no fuse data available.

Also, regardless of the above, you should definitely default to the latest device tree when the reading is higher than what you currently support. The latest revision has 5 stored, but your script fell back to Birch only because it was handling values up to 4.

By dos on 2022-10-25T04:39:10

Well, you should not run mismatched device trees.

Well, devices should properly advertise which rev they are if loading the correct DT is important, but I digress :P

The worst things are that Birch & Chestnut use a slightly higher maximum charging current than the rest, and Evergreen uses a slightly higher maximum backlight current than the rest. I wouldn't advice to run it daily for months like that, but it won't really hurt if you get a wrong dts and figure that out, say, a few days later.

And this part worries me. How likely is it that a user would recognize that any problem they do happen to observe is in fact due to running the wrong DT? Anyways, maybe the actual risk is small that someone would run the wrong DT for more than "a few days"... except for all Birch, Chestnut owners that don't have any fuse/board info... in their case we're going to default to Evergreen (as you requested), and then end up running it for more than a few days, right?

The latest revision has 5 stored, but your script fell back to Birch only because it was handling values up to 4.

Because I was operating under the assumption that the birch dts was "safe" for all revs, and running the wrong dts in other situations might cause harm... so it was a defensive stance.

I guess another "solution" is to basically make anything earlier than Evergreen "unsupported" in pmOS, and only install/use the Evergreen DT. All others are running pmOS at their own risk, or something. Yes, it sucks.

I know Purism ships 1 image per DT (or used to, not sure if you still do), but that's not something that will work here... which is why I tried to use the board rev to pick the right DT.

By clayton craft on 2022-11-04T06:06:19

Because I was operating under the assumption that the birch dts was "safe" for all revs, and running the wrong dts in other situations might cause harm... so it was a defensive stance.

Nothing is "safe" when mismatched, as in I'm not going to give any guarantees. Such combinations are untested and, as evidenced by this issue existing, they visibly break functionality. However, while I'm not going to declare it "safe", I don't really expect any hardware damage to happen because of mismatched DT rev either.

in their case we're going to default to Evergreen (as you requested), and then end up running it for more than a few days, right?

I would expect them to notice that something is wrong (just like in this ticket) and look up why that may be the case, at which point they can blow the relevant fuse themselves. We're talking about a small number of devices here, so that should be manageable.

I guess a sane thing to do would be to default to r2 when the fuse isn't set at all, but use the latest one you know about (so right now r4) in cases where it's set to a higher rev than the latest one you support. The currently shipped hw revision is 5, which is newer and different than 4, but the changes aren't relevant to the device tree so r4 is being used for them both. In the future, 6 and more could get introduced - and you want your script to use the latest available device tree in such case and not fall back to the oldest one which differs the most, as that doesn't make much sense.

By dos on 2022-11-07T13:25:15

mentioned in commit a19cbca8

By clayton craft on 2022-11-04T06:16:08

mentioned in merge request !3614 (merged)

By clayton craft on 2022-11-04T06:16:53

@bja-au could you give this a try? !3614 (merged)

By clayton craft on 2022-11-04T06:18:29

mentioned in commit 2a756c8c

By clayton craft on 2022-11-19T05:13:38

mentioned in commit 2ccd927e

By clayton craft on 2022-12-01T17:25:10

closed with commit 2ccd927e

mentioned in commit f4030e5f

By clayton craft on 2022-12-01T17:30:36

Librem 5 running postmarketos phosh screen up side down

Describe your issue

What's the expected behaviour?

What's the current behaviour?

How to reproduce your issue?

What device are you using?

On what postmarketOS version did you encounter the issue?

On what environment did you encounter the issue?

Phone environments

Other

How did you get postmarketOS image?

What's the build date of the image? (in yyyy-mm-dd format)

Additional information

Child items 0

Activity