2

I am just learning. I have installed email, bluetooth and several other items on my RaspberryPi. Now I have purchased a 5" screen to use and the drivers are on a separate img file provided by the screen manufacturer. How can I get the drivers from that img onto the original image that I have been using and working with?

Randy Campbell
  • 23
  • 3
  • Hello and welcome. Please be more specific (e.g. what screen not a screen). The thing is, that this image does not simply contain the driver but a full OS with this driver included (and/or maybe some nasty kernel patch). – Ghanima Nov 08 '15 at 19:51
  • Thank you Ghanima, the display is a Uniker Raspberry Pi 2 Model B Quad Core for Raspberry Pi Model (B+) 5- Inch 800x480 Pixel Hdmi input Touch Screen & Stand Case purchased from Amazon. Yes the issue is that the driver is embedded in a full OS – Randy Campbell Nov 08 '15 at 20:11
  • Does the vendor not support separate driver files? – Ghanima Nov 08 '15 at 20:36
  • No, I looked for separate drivers first. – Randy Campbell Nov 08 '15 at 22:24

1 Answers1

1

This Q&A explains how to mount the partitions in the manufacturers image.

Here's what you'll need:

  • From the 1st partition, kernel.img or (for a Pi 2) kernel7.img. Copy this and rename it mykernel.img. Edit your config.txt and add a line:

    kernel=mykernel.img

    Make sure there's no other kernel= line in there.

  • In the second partition, look in /lib/modules. There is probably one directory in there with a tuplesque name like 3.18.4. There probably is not a directory in your second partition with that exact name, in which case you can just copy the whole directory in. If by some chance you do have a pre-existing one, rename it first (e.g., 3.18.4-backup) to keep a copy.

  • In the /lib directory there will be a firmware directory in both filesystems. There's probably nothing in there you need, but just in case, you don't want versions of things you already have, so, e.g.,

    cp -an /mnt/image/lib/firmware/* /lib/firmware/

This presumes you have the whole image mounted on a running pi which is unlikely because of its size; obviously you'll have to use the real paths.

If you ever have to rebuild the kernel or a module, you'll have to use an exact match version wise and this is still not guaranteed to work. Keep in mind when viewing documentation, etc., here your kernel version is going to be well behind the current. The manufacturer probably made this image when they started distribution and they will never bother updating it, because it is a methodology that plays on the naivete of the consumer to start with.

My recommendation is to never, ever buy anything that comes with drivers packaged this way, or that refers to drivers for a specific kernel version, unless they also make it clear the source is available. At least one distributor of TFT screens (Adafruit) has (I think) mainlined their driver, meaning it now comes with updated kernels (instead of the other way around). Their are also existing in-tree drivers in some cases. This is a much better solution, but most manufacturers will not bother with it for philosophical reasons and because, as mentioned, they are targeting people who won't know any better until well after the product has been paid for, and their reputation as manufacturers and distributors is not significant to their marketing model (sell cheap generic goods online).

Community
  • 1
goldilocks
  • 58,859
  • 17
  • 112
  • 227
  • Thank you very much for explaining the process. Also, thank you for the advise to beware when purchasing. I am a little embarrassed as I am usually very careful with my Mac and Window machines. – Randy Campbell Nov 10 '15 at 15:54
  • The situation on Mac and Windows is a little more straightforward and it is understandable that people new to linux get caught this way. Basically, there is a lot more motivation for manufacturers to play the game properly with OSX and Windows. A significant issue on linux is that things are much simpler if the source code for a driver is available, but this model goes against the grain of the industry generally. While it shouldn't matter much in most cases (manufacturers have often provided the code for in-tree drivers), – goldilocks Nov 10 '15 at 16:23
  • ...a complex problem may arise when one manufacturer wants to include parts from another (very common). The Pi itself falls prey to this -- while presumably the designers of the Pi would happily cooperate since it is a primarily linux based platform, Broadcom, who make the SoC, do not; the reason I've seen given for using that the BCM chip anyway was to keep the cost down. This means the Pi people must maintain their own kernel. Likewise, people who make screens driven by chips from a third party will easily run into a parallel issue. – goldilocks Nov 10 '15 at 16:23