hyperpixel 4.0 screen blank running octoprint on a Raspberry Pi 4.0 8gb (kernel 5.4.51 bug) #81
Comments
|
When the screen is blank, are you able to ascertain if the backlight is on or off? Also for the sake of everyone's sanity do you have time to try this setup using the regular Raspberry Pi OS, to eliminate the possibility that either the Pi or HyperPixel is at fault. We don't test outside of Raspian/Raspberry Pi OS since there just aren't enough hours in the day (and by we, I mean.. there's only really me), but with any luck we'll get to the bottom of this. The HyperPixel4 is a particularly easy device to upset if OctoPrint does anything non-standard with video, or changes any GPIO pin state. |
|
Philip
1st of all thanks for coming to my rescue
Will give it a go tonight when I get home and let you know
Is there a Particular source for the OS you want me to use?
And full version not lite confirm?
I will try and get some pictures of the screen back light can’t remember exactly what I saw when now 🤦🏼
…Sent from my iPhone
Cheers
Phil
On 6 Jul 2020, at 11:38, Philip Howard ***@***.***> wrote:
When the screen is blank, are you able to ascertain if the backlight is on or off?
Also for the sake of everyone's sanity do you have time to try this setup using the regular Raspberry Pi OS, to eliminate the possibility that either the Pi or HyperPixel is at fault.
We don't test outside of Raspian/Raspberry Pi OS since there just aren't enough hours in the day (and by we, I mean.. there's only really me), but with any luck we'll get to the bottom of this. The HyperPixel4 is a particularly easy device to upset if OctoPrint does anything non-standard with video, or changes any GPIO pin state.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
The last OS I've fired up and tested with was- "Raspberry Pi OS (32-bit) with desktop" - speciffically This is the desktop (not lite) without the extra cruft version, so it's a 1.1G download. I'll see if I can re-image this for testing. Do you have a link to the specific Octoprint image you were using? |
|
Hi
Here you go this is where I got the version of Octoprint from….
Octoprint on a pi4 8gb - Get Help - OctoPrint Community Forum <https://community.octoprint.org/t/octoprint-on-a-pi4-8gb/20670/23>
After your 1st Email I was going to use this Raspberry Pi Imager -
Raspberry Pi Downloads - Software for the Raspberry Pi <https://www.raspberrypi.org/downloads/>
shall I try it tonight or do you want me to wait until you reimage the other file?
Once again thanks for your help
Cheers
Phil
… On 6 Jul 2020, at 14:43, Philip Howard ***@***.***> wrote:
The last OS I've fired up and tested with was- "Raspberry Pi OS (32-bit) with desktop" - speciffically 2020-05-27-raspios-buster-armhf.zip - direct link: https://downloads.raspberrypi.org/raspios_armhf/images/raspios_armhf-2020-05-28/2020-05-27-raspios-buster-armhf.zip <https://downloads.raspberrypi.org/raspios_armhf/images/raspios_armhf-2020-05-28/2020-05-27-raspios-buster-armhf.zip>
This is the desktop (not lite) without the extra cruft version, so it's a 1.1G download.
I'll see if I can re-image this for testing.
Do you have a link to the specific Octoprint image you were using?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#81 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQFHPDBCIPSSXSBUKBQLFMDR2HIJ5ANCNFSM4ORALWLA>.
|
|
Thanks I've imaged Octoprint and think I'm now encountering the same issue as you. My initial debugging steps don't seem to suggest that any DPI interface is being set up at all, and now I can't seem to SSH back into my Pi. D'oh! This might be a fundamental problem with the beta 64bit Raspberry Pi OS and need a bit of sleuthing and a bug report. |
|
Im working through the install as you suggested….
So far ……
Ok so I downloaded Raspberry Pi imager for Mac OS from the raspberrypi.org site.
I unpacked the imager and using Raspberry Pi Imager v1.3. flashed the recommended OS to the SD card. It was labelled ‘ a Port of Debian with the \raspberry Pi Desktop’ (although I note it was 32-Bit version...presumably still runs on 64Bit Pi) released 2020-05-27. The write was successful
I needed a headless setup so I followed these instructions…..
For headless setup, SSH can be enabled by placing a file named ssh, without any extension, onto the boot partition of the SD card from another computer. When the Pi boots, it looks for the ssh file. If it is found, SSH is enabled and the file is deleted. The content of the file does not matter; it could contain text, or nothing at all.
And also….
You will need to define a wpa_supplicant.conf file for your particular wireless network. Put this file in the boot folder, and when the Pi first boots, it will copy that file into the correct location in the Linux root file system and use those settings to start up wireless networking.
wpa_supplicant.conf file example:
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=<Insert 2 letter ISO 3166-1 country code here>
network={
ssid="<Name of your wireless LAN>"
psk="<Password for your wireless LAN>"
}
So on first boot up the Hyperpixel display was backlit with a blank screen (but no hyperpixel drivers installed so far).
I too am struggling to connect with SSH but I forgot to insert the country code in wpa_supplicant.conf.
Not sure if that is critical but will correct anyway.
To answer one of your other questions the screen is backlit now I have the raspberry Pi desktop on (see attached but wasn’t like this when using octoprint !)
Once again thanks for your help
… On 6 Jul 2020, at 21:11, Philip Howard ***@***.***> wrote:
Thanks I've imaged Octoprint and think I'm now encountering the same issue as you.
My initial debugging steps don't seem to suggest that any DPI interface is being set up at all, and now I can't seem to SSH back into my Pi. D'oh!
This might be a fundamental problem with the beta 64bit Raspberry Pi OS and need a bit of sleuthing and a bug report.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#81 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQFHPDFCODBPAWWHLE4PCADR2IVWZANCNFSM4ORALWLA>.
|
|
I failed to connect via SSH the first time, also, but it magically worked after I rebooted. 🤷 I knew WiFi was working, at least, because I could ping the Pi. Now imaging vanilla Raspberry Pi OS 64bit Beta to see if I encounter the same issue, because I totally broke my setup and had to do something |
|
Hi
No that didn’t work either and I am unable to see my raspberry Pi on my network
I will try ethernet and see if I can see it that way 😩🤷🏼🤦🏼🔨
Cheers Phil
… On 6 Jul 2020, at 21:11, Philip Howard ***@***.***> wrote:
Thanks I've imaged Octoprint and think I'm now encountering the same issue as you.
My initial debugging steps don't seem to suggest that any DPI interface is being set up at all, and now I can't seem to SSH back into my Pi. D'oh!
This might be a fundamental problem with the beta 64bit Raspberry Pi OS and need a bit of sleuthing and a bug report.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#81 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQFHPDFCODBPAWWHLE4PCADR2IVWZANCNFSM4ORALWLA>.
|
|
Sounds like you are having more fun than me!
… On 6 Jul 2020, at 21:29, Philip Howard ***@***.***> wrote:
I failed to connect via SSH the first time, also, but it magically worked after I rebooted. 🤷 I knew WiFi was working, at least, because I could ping the Pi. Now imaging vanilla Raspberry Pi OS 64bit Beta to see if I encounter the same issue, because I totally broke my setup and had to do something
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#81 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQFHPDFNDKJAXPM2CIFDM43R2IXY3ANCNFSM4ORALWLA>.
|
|
Ok some progress….
I can see the raspberry pi on the network connected via ethernet and I was able to sucessfully ping.
Presumably I could load the the hyperpixel 4.0 Drivers through the router but you will have to explain how. Sorry you are working with a total NOOb!!!
Cheers
Phil
… On 6 Jul 2020, at 21:42, phil brown ***@***.***> wrote:
Sounds like you are having more fun than me!
> On 6 Jul 2020, at 21:29, Philip Howard ***@***.*** ***@***.***>> wrote:
>
>
> I failed to connect via SSH the first time, also, but it magically worked after I rebooted. 🤷 I knew WiFi was working, at least, because I could ping the Pi. Now imaging vanilla Raspberry Pi OS 64bit Beta to see if I encounter the same issue, because I totally broke my setup and had to do something
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub <#81 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQFHPDFNDKJAXPM2CIFDM43R2IXY3ANCNFSM4ORALWLA>.
>
|
|
It looks like the In the mean time I have managed to get display output to work (on the Raspberry Pi OS Beta 64bit image at least) with some changes to Specifically the end of my config now looks like this: Note: Then we use Touch input wont work at all with this config- unfortunately- but it might be possible to whip up a dtoverlay that just configures touch. Also the system wont be aware of the backlight in any meaningful way, so it will be always-on. Finally, setting the display orientation with So... I have some progress. |
|
Once again thanks for your help. Sorry for the late response only just got home.
So at this stage is there anything else you want me to do?
I was unable to ‘ssh’ my pi yesterday despite setting up wpa_supplicant. I was able to access my pi through ssh previously using octoprint so I know the wireless side of thing is working on the pi.
Cheers
Phil
…Sent from my iPhone
On 7 Jul 2020, at 10:53, Philip Howard ***@***.***> wrote:
It looks like the hyperpixel4.dtbo just wont load on an 64bit Pi 4 configuration, or against a 5.x kernel. Device-tree stuff baffles me at the best of times, so I'm going to have to appeal to the powers-that-be for some help with this.
In the mean time I have managed to get display output to work (on the Raspberry Pi OS Beta 64bit image at least) with some changes to /boot/config.txt.
Specifically the end of my config now looks like this:
#dtoverlay=hyperpixel4
gpio=0-25=a2
gpio=19=op,dh
enable_dpi_lcd=1
dpi_group=2
dpi_mode=87
dpi_output_format=0x7f216
dpi_timings=480 0 10 16 59 800 0 15 113 15 0 0 0 60 0 32000000 6
Note: dtoverlay=hyperpixel4 is commented-out because it just doesn't work.
Then we use gpio= to configure the alt-mode of the DPI (display parallel interface) pins to alt2 so the video signal is sent out on GPIO. And finally set BCM19 to an output, driven high to enable the backlight.
Touch input wont work at all with this config- unfortunately- but it might be possible to whip up a dtoverlay that just configures touch. Also the system wont be aware of the backlight in any meaningful way, so it will be always-on.
Finally, setting the display orientation with hyperpixel4-rotate wont persist because it fails to set the touch mapping and crashes out.
So... I have some progress.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Right now I think there's nothing to be done- though I've just pushed up a Pi4 64bit beta branch you culd try it's still a work in progress: https://github.com/pimoroni/hyperpixel4/tree/pi4-64bit-beta Install process should be as follows: |
|
Ok will give it a go thanks
Cheers
Phil
… On 7 Jul 2020, at 20:33, Philip Howard ***@***.***> wrote:
Right now I think there's nothing to be done- though I've just pushed up a Pi4 64bit beta branch you culd try it's still a work in progress: https://github.com/pimoroni/hyperpixel4/tree/pi4-64bit-beta
Install process should be as follows:
git clone https://github.com/pimoroni/hyperpixel4 -b pi4-64bit-beta
cd hyperpixel4
sudo ./install.sh
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Just commented on the now closed #88 so putting it here too I have the 2gb version of pi4 Problem started after the last 1-3 updates:
The touch seems to be working - i touched the screen a couple of times as i have the screensaver on for it to wake up and while the screen didn't come on the hotend began to heat up. The screen comes on briefly when starting and then just blank with no backlight
|
|
Also posting details from my closed duplicate for the benefit of others. Describe the bug I previously opened this as a faulty on the OctoDash GitHub page: UnchartedBull/OctoDash#848 I have since conclusively ruled out OctoDash as a factor as a clean installation of OctoPrint/OctoPi, installing the HyperPixel 4 drivers and then running sudo apt update and sudo apt full-upgrade causes the issue. This points to the HyperPixel 4 drivers having an issue with the latest Pi updates. To Reproduce Image SD card with the current OctoPi image https://octopi.octoprint.org/latest Update to Octoprint 1.4.0 from within OctoPi web interface and reboot. Install HyperPixel 4 driver and reboot. curl https://get.pimoroni.com/hyperpixel4 | bash Screen is working correctly at this point and is in 'portait'. Run latest Pi updates sudo apt update sudo apt full-upgrade Reboot and you get a black screen. OctoPi is up and running and available via the web interface and SSH. Your HyperPixel 4 Let us know which HyperPixel 4 board you're using. Note: if you're having a problem with the original HyperPixel you should go to: https://github.com/pimoroni/hyperpixel Your Raspberry Pi Give as much detail about your Pi and OS as possible. We only officially support Raspbian, but might be able to point you in the right direction if the problem is with another OS. Extra debugging information If you're having a problem with touch, try checking dmesg for related errors: And check i2c is working: ls /dev/i2c-* You should see something like: pi@raspberrypi:~ $ ls /dev/i2c-* Command fails And your HyperPixel 4 touch is showing up (there should be an address blocked out with UU in the below command): i2cdetect -y X ( where X is the number of i2c bus found in the command above) For example: pi@raspberrypi:~ $ i2cdetect -y 7 Command fails Here is the list of updates loaded by the sudo apt update: pi@octopi:~ $ sudo apt full-upgrade |
|
The biggest thing I see is that the xwindow system is not running at all. I suspect that the desktop components are missing because the octopi image is built without them as a headless system. |
|
In all cases it's worth first trying the Kernel 5.4.51 fixes in #89 I believe OctoPi is academic in this case, since these same problems occur on stock Raspberry Pi OS when updating. |
|
the tried |
|
You're a step ahead of me! I'm just updating my non-64bit OctoPi image now. IIRC I had backlight working via the /sys/class interface, but the whole shebang is nothing if not a miserable mess when it comes to display power management. The dtoverlay still sets up the backlight module, and the /sys/class interface being present is a good sign. The backlight pin is BCM 19. |
|
Just before I reboot with the new updates, I can confirm on Kernel 4.19.75-v7l+ with these new changes to the HP4 overlay that the following works: Backlight off: And yes, as of the updates and Kernel 5.4.51-v7l+ these commands no longer work. big sigh Looks like a fix is incoming- raspberrypi/linux#3767 (DON'T run rpi-update, just wait for a new official release- otherwise you might just fix one thing and break ten others) If I had more time, I'd probably do more thorough testing with pre-release kernels and catch these kind of problems before they're released into the mainstream. |
Gadgetoid
changed the title
|
I have been running 32-bit (waiting to take on yet another early system). For that I have published a my work-around for the 32-bit space. See https://github.com/TxBillbr/octodash-hyperpixel-fix . the 3Dprinting community is rapidly adopting OctoDash running on a pi screen and the HyperPixel has been difficult for a number of people. The work-around has been tested on 4.19.118. and I am testing 5.4 today. |
|
Issue #88 has been marked as being a duplicate of this, but reading the thread, this seems to be focusing on there being a bug in how it runs on the 64bit version of Raspberry OS. But right now I'm seeing how 2x Pi4@2G and 2x Pi4@4G are all crashing whenever I do:
The only way it works is if I skip step 2. Something in the upgrade is breaking things, and #88 describes it better. Pi3B has no issues whatsoever even when upgrading. TxBillbr I'm keen to try out your workaround tomorrow and see if that solves my issue. My test setup for whoever is interested (4x Pi3B, 2x Pi4@2G, 2x Pi4@4G): pic |
|
I upgraded to 5.4 kernel and the solution breaks. Here are the dmesg lines for Goodix... Linux octopi 5.4.51-v7l+ #1327 SMP Thu Jul 23 11:04:39 BST 2020 armv7l GNU/Linux Goodix shows loaded by lsmod with zero use count: goodix 20480 0 i2c is /dev/i2c-11 |
|
Same problem as @mikenosko. Only difference is pi revision C03111 |
|
@TxBillbr in my case I have If you're running HyperPixel4 on a Pi 4 you might be running into the race condition on startup that causes the touchscreen to swap i2c address. You should try the |
|
@reneb86 it is my understanding that the problem, and solution, for both Pi 4 64bit and 32bit are the same. I've confirmed this on a Pi 4 4GB using both the OctoPi 64bit beta and latest OctoPi 32bit release. For anyone wanting to try the fix, this is the version without the weird i2c glitch fix: And if touch doesn't work for you, remove that clone, remove You can check which i2c address the touchscreen is using: It will be either 0x14 or 0x54. To re-iterate above there is currently an issue with the backlight control kernel module on the released version of kernel 5.4.51. We'll have to sit tight for a fix to that. |
|
@Gadgetoid#4451, I did a full gamut of testing with the patch branch and it seems that applying the installation on a 4.x kernel machine and then upgrading still breaks the solution (yields a black screen, no backlight). Running it on a clean installed Raspian 5.4-based image seems to work well. In the upgrade scenario I get no i2c ports and no DSI shows up. The /devices tree does have the i2c input assigned. doing the modprobe and looking at i2c, the screen is at 0x14. xrandr sees no screen to manage. On shutdown I get a quick glimpse of the kernel shutdown messaging. So something is running that prevents the operation of the screen. As soon as that is killed the screen operates for a split second before it is killed too. I have a video of it if that is useful. I tried with vc4-fkms-v3d both enabled and disabled with the same results. I am on roughly the same version of kernel ( 5.4.51-v7l+ #1327). Tomorrow, I'll take a peek to see what has changed between 1327 and 1331. pi@octopi:~ $ dmesg | grep Goodix dbgmessages.zip It's getting late. I will start in on it first thing a.m. US Central time. |
|
@TxBillbr ah! You've set the little rusty cogs in my brain in motion and a thought has clicked into place- Insofar as I understand, a dtoverlay may be compiled differently depending upon the running kernel. This means the overlay compiled against 4.x, and unmanaged by the official upstream kernel packages, will sit unchanged during the upgrade to 5.x and ultimately be incompatible. D'oh! The correct fix here is for us to upstream our dtoverlay so that a new version is installed for each kernel update. There's a small hitch here in that our i2c-compatibility fudge probably wouldn't meet the scrutiny for upstream inclusion. This is something I haven't pushed for before, but I'm going to look into it now. The other problem with upstream is it's generally a much slower process to get a modified dtoverlay through the pipeline and onto a users Pi. I don't think our dtoverlays change all that much though, so perhaps that isn't a problem. Maybe also there's a more immediate fix to this to catch issues during upgrades... but I'm not sure. Thank you for your thorough testing! |
|
@Gadgetoid Just did an rpi-update and the kernel 5.4.51-v7l+ #1332.. Screen is on! Rotation and i2c don't appear to be correct, but continuing tests. X and Y are swapped, but we have a cursor. |
Just did an |
|
@tusing if you've used the |
Thanks @Gadgetoid - I already did that though. Here's what I did:
Here is my While the backlight is on, unfortunately I still have a black screen :( Edit: Commenting out the items under |
|
If you're not building from a fresh GitHub directory be careful that the dtoverlay files might not regenerate- you should remove |
|
@Gadgetoid Thanks for all your efforts on this. I have updated my OctoDash document to reflect the current state. https://github.com/TxBillbr/octodash-hyperpixel-fix |
|
@TxBillbr thanks for all your feedback & support here. Though I think I'm far from done with this cursed display 😆 I guess my next port of call for this is to see how much of the HyperPixel 4 driver I can get upstreamed so we don't have a repeat of this issue with another kernel release. |
|
FYI - With the rpi kernel now updated and having the updated overlays (ie reinstalling hyperpixel4 pi4-i2c-fix branch) this seems to work OK now. editing didn't try the rotation as it already displays right for me... thanks @Gadgetoid! |
|
I have this same issue where the screen is blank with a small fixed cusor top left screen, Pi4b 8gb 4" hyperpixel and loaded up 18.1 beta. Dcustom Carlin has been helping me but we are now properly stuck, did this issue ever get resolved? Thanks guys |
|
video-1600630855.mp4.zip |
|
While I now have a picture again (after removing all old hyperpixel stuff and running the install from the branch patch-pi4-i2c-fix), it flickers in lines. As if the image is moving quickly from top to bottom and leaving some artifacts on the screen. Touch works, backlight works. My setup: My /boot/config.txt: |
Are you able to provide an update on this issue? I imagine a lot of users, my self included; have been holding off on running updates on our Pi's becuase we'll lose our displays. Pimoroni really need to get this sorted because they are still selling the screens with no bulletin to new owner's that their screens are not going to work. |
|
I'll try to spend some time this week to update my pi4s with latest code and os updates to determine latest status from my side. |
Hi @TxBillbr , Any updates on how you went. I know there are a bunch of us waiting to run updates on our Pi4's to fix/allow updating of other Octoprint related plugins, etc. |
|
Sorry, I haven't gotten to it. I've been sidelined with some health issues for a few weeks. I'll do my best to get to that as soon as possible. |
|
Hi @TxBillbr Can we please have an update on this? |
|
I run a large Holiday lighting show every year. It will likely be a couple of weeks before I can get to this. I'll do my best to get to this.
…-----Original Message-----
From: "morphias2004" <[email protected]>
Sent: Saturday, November 28, 2020 12:32am
To: "pimoroni/hyperpixel4" <[email protected]>
Cc: "Bill Brothers" <[email protected]>, "Mention" <[email protected]>
Subject: Re: [pimoroni/hyperpixel4] hyperpixel 4.0 screen blank running octoprint on a Raspberry Pi 4.0 8gb (kernel 5.4.51 bug) (#81)
Hi [ @TxBillbr ]( https://github.com/TxBillbr )
Can we please have an update on this?
—
You are receiving this because you were mentioned.
Reply to this email directly, [ view it on GitHub ]( #81 (comment) ), or [ unsubscribe ]( https://github.com/notifications/unsubscribe-auth/AKTLEKHSAYA2JP3Q2K5A6PLSSCKRNANCNFSM4ORALWLA ).
|
|
Has there since been any progress on this? Running out of options and may have to return screen.. |
|
I haven't looked at it in a while and thought it had been resolved with a
later firmware/kernel release.
…On May 20, 2021 12:55:16 AM Flux ***@***.***> wrote:
Has there since been any progress on this? Running out of options and may
have to return screen..
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
To summarise I am having problem configuring a new hyperpixel 4.0 screen to work with Octoprint and a Raspberry Pi4 8gb. The issue appears to be a software one as there appears to be evidence the screen is actually working. If any one can help resolve this matter it would be appreciated.
Please help
I am having problems setting up an hyper pixel 4.0 rectangular touchscreen with a raspberry pi4b 8gb. I would like to to use this to remotely monitor my 3D printer (Prusa I3 MK3s) with octoprint. Both were recently purchased from Pimoroni. This is my first Pi purchase and I am not familiar with Raspberry Pis, Terminal or Github so please be nice! However I am reasonably intelligent and enjoy learning new things and don't necessarily expect thing to work straight away. I have spent several days trying to get it to work properly using various forums and you tube videos. I must confess I am at a loss as what to do next.
I have connected the hyperpixel 4.0 to the GPIO header on the raspberry pi using the standoffs supplied with the screen. Nothing else is connected to the Raspberry Pi. The Raspberry Pi is powered using a standard Raspberry USB C PSU.
I successfully flashed Octoprint (OctoPI64-0.18.0-beta.img) to a 16gb sd card using etcher. Maybe the fact that Octoprint is Beta version is the issue but according to the Octoprint webpage the standard version doesn’t play nicely with the 8gb Raspberry Pi4 so I have no alternative. I modified the WPA/WPA2 settings in |octopi-wpa-supplicant.txt and successfully logged onto the Raspberry Pi using a web browser (Safari). I configured Octoprint and then connected it to the printer and all appears to be normal. For all of this time the screen was blank as expected as the screen drivers were not installed but you could see portions of the screen backlit.
I then tried to follow this video to set up Octoscreen https://youtu.be/OJ59hXSyBoI which is where my problems started …..
(timeline 5.00 minutes) The curl https://get.pimoroni.com/hyperpixel4 | bash gave me the error message. ‘This hardware is not supported, sorry! Config files have been left untouched’.
So I used….
Last login: Sun Jul 5 17:01:53 on ttys000
The default interactive shell is now zsh.
To update your account to use zsh, please run
chsh -s /bin/zsh.For more details, please visit https://support.apple.com/kb/HT208050.
phils-MBP-17530:~ philbrown$ ssh [email protected]
[email protected]'s password:
Linux octopi 5.4.42-v8+ #1319 SMP PREEMPT Wed May 20 14:18:56 BST 2020 aarch64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sun Jul 5 16:17:09 2020 from fe80::49d:4acf:331c:9023%wlan0
SSH is enabled and the default password for the 'pi' user has not been changed.
This is a security risk - please login as the 'pi' user and type 'passwd' to set a new password.
Access OctoPrint from a web browser on your network by navigating to any of:
https is also available, with a self-signed certificate.
OctoPrint version : 1.4.0
OctoPi version : 0.18.0
pi@octopi:~ $ git clone https://github.com/pimoroni/hyperpixel4 -b pi4
Cloning into 'hyperpixel4'...
remote: Enumerating objects: 54, done.
remote: Counting objects: 100% (54/54), done.
remote: Compressing objects: 100% (41/41), done.
remote: Total 291 (delta 20), reused 36 (delta 12), pack-reused 237
Receiving objects: 100% (291/291), 730.19 KiB | 1.42 MiB/s, done.
Resolving deltas: 100% (135/135), done.
Which appeared to have worked. Followed by …..
pi@octopi:~ $ cd hyperpixel4
pi@octopi:~/hyperpixel4 $ sudo ./install.sh
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
[sudo] password for pi:
Notice: building hyperpixel4.dtbo
Created symlink /etc/systemd/system/multi-user.target.wants/hyperpixel4-init.service → /etc/systemd/system/hyperpixel4-init.service.
Installed: /usr/bin/hyperpixel4-init
Installed: /etc/systemd/system/hyperpixel4-init.service
Installed: /boot/overlays/hyperpixel4.dtbo
Config: Added dtoverlay=hyperpixel4 to /boot/config.txt
Config: Added gpio=0-25=a2 to /boot/config.txt
Config: Added enable_dpi_lcd=1 to /boot/config.txt
Config: Added dpi_group=2 to /boot/config.txt
Config: Added dpi_mode=87 to /boot/config.txt
Config: Added dpi_output_format=0x7f216 to /boot/config.txt
Config: Added dpi_timings=480 0 10 16 59 800 0 15 113 15 0 0 0 60 0 32000000 6 to /boot/config.txt
After rebooting, use 'hyperpixel4-rotate left/right/normal/inverted' to rotate your display!
left - Landscape, power/HDMI on bottom
right - Landscape, power/HDMI on top
normal - Portrait, USB ports on top
inverted - Portrait, USB ports on bottom
Which also appears correct, followed by
pi@octopi:~/hyperpixel4 $ sudo reboot now
Connection to octopi.local closed by remote host.
Connection to octopi.local closed.
On rebooting the Raspberry Pi the screen remained blank after initially flashing breifly. I was expecting to see command line text as in the video @ https://youtu.be/OJ59hXSyBoI (timeline 6:17 mins)
I then tried to rotate the screen in case that was causing the issue
pi@octopi:~ $ hyperpixel4-rotate
Unsupported orientation:
Try one of: left, right, normal, inverted
My inexperience shows with the incorrect command above…. corrected below!
pi@octopi:~ $ hyperpixel4-rotate right
Rotating display
Can't open display
[sudo] password for pi:
Traceback (most recent call last):
File "", line 15, in
File "/usr/lib/python2.7/dist-packages/screenlayout/xrandr.py", line 43, in init
version_output = self._output("--version")
File "/usr/lib/python2.7/dist-packages/screenlayout/xrandr.py", line 64, in _output
raise Exception("XRandR returned error code %d: %s"%(status,err))
Exception: XRandR returned error code 1: Can't open display
Setting matrix: 0 1 0 -1 0 1
Unable to connect to X server
Saving touch settings to /etc/udev/rules.d/98-hyperpixel4-calibration.rules
Whilst most of this code ran I notice a couple of exceptions/errors is the problem I don’t understand what they mean or how to correct!
pi@octopi:~ $ sudo reboot
Connection to octopi.local closed by remote host.
Connection to octopi.local closed.
Having rebooted the display briefly appeared (< 2 seconds) showing command line text similar to video @ https://youtu.be/OJ59hXSyBoI (timeline 6:17 mins) followed by the blank screen. It gives the impression that some video config was being overwritten later in the boot up sequence but that’s a wild guess on my part.
Further on in the video video @ https://youtu.be/OJ59hXSyBoI (timeline 7:30 mins) suggest there could be a conflict with dtoverlay=vc4-fkms-v3d. So I commented out this line as suggested (#dtoverlay=vc4-fkms-v3d)
Another reboot still gave a blank video screen strangely this time I didn’t notice any command line text.
For info the end of the config.txt file looks like this…..
dtoverlay=hyperpixel4
gpio=0-25=a2
enable_dpi_lcd=1
dpi_group=2
dpi_mode=87
dpi_output_format=0x7f216
dpi_timings=480 0 10 16 59 800 0 15 113 15 0 0 0 60 0 32000000 6
And also for info I provide the following script
pi@octopi:/boot $ ls /dev/i2c-*
/dev/i2c-11
pi@octopi:/boot $ sudo nano /dev/i2c-11
[sudo] password for pi:
pi@octopi:/boot $ i2cdetect -y 11
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
pi@octopi:/boot $ cat /proc/cpuinfo | grep Revision
Revision : d03114
pi@octopi:/boot $ lsb_release --description
Description: Debian GNU/Linux 10 (buster)
pi@octopi:/boot $ uname -r
5.4.42-v8+
pi@octopi:/boot $ sudo vim /boot/config.txt
sudo: vim: command not found
The text was updated successfully, but these errors were encountered: