Beagle Bone Black 4D Systems 4th Gen 4.3" LCD, could not request pin 40

[Mecha Lec]

I have flagged this under "Beagle Bone Black " but maybe its more of a CAPE issue. 

I have a BBB Revision C, with 4DSystems LCD Cape. 

I am hoping someone on this forum could possibly help with a software related issue. 

I am running 2net 4.1 Kernal ,http://www.2net.co.uk/android4beagle.html

The screen shows "Android" and then this fades out. 

Looking at serial I have this error: 

[ 3.353484] pinctrl-single 44e10800.pinmux: pin 44e108a0.0 already requested by panel; cannot claim for 0-0070
[ 3.363651] pinctrl-single 44e10800.pinmux: pin-40 (0-0070) status -22
[ 3.370239] pinctrl-single 44e10800.pinmux: could not request pin 40 (44e108a0.0) from group nxp_hdmi_bonelt_pins on device pinctrl-single

I think this might be why it doesn't continue with the Kernal but I could be wrong. 

Referring to all available forum posts regarding this LCD I have tried many different options in uEnv.txt to disable HDMI, disable universal cape and alike but nothing seems to work. 
I am not sure what command options are actually relevant to this particular build. 

I have also read that the boot int eh EMMC can also affect the overlays which are being loaded by the image in the SD card. I have ensured I have loaded one of the latest flasher images from official beagle bone site. 
Running just this flasher image, the screen does display correctly so I know it is not a hardware related issue. 

I have also double checked the overlay that is being used and all the pins are correct and match the schematic of the display. 

I am a newbie to Beable Bone Black and Linux so this is incredibly difficult and have spent weeks now trying to overcome this hurdle. 
So any help would be greatly appreciated. 

I have attached the serial outputs from the problamatic SD image and also for my base EMMC. 

Hoping someone could provide some info to push me in the right direction. 

[Venkatesh Vadde]

Scott:

This kind of a problem had troubled me many months back as well, but I moved on to solve it another way using a Raspberry Pi based LCD. While that may not be helping you directly just now, you might want to consider writing to the TI-e2e community, where engineers are paid to support issues like this with the BBB hardware and firmware. Please take this there. I am not ruling out other kind of help you might find here. 

My summary assessment on this display issue has been that the vast majority of people use BBB in embedded mode without displays. Those who do use a display (the small minority) know how to use a simple i2c based interface or the like, and get by. 

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/6f716178-d227-4c24-a3f3-e54ab0fb0b92%40googlegroups.com.

[Robert Nelson]

On Wed, Aug 28, 2019 at 4:28 AM Scott Pannan <scott_...@hotmail.com> wrote:
>
> Thank you for the information.
>
> Yes, I have almost admitted defeat on this. Which is terribly disappointing, because these boards are designed for this purpose.
>
> I was looking to start with the LCD, gain confidence and then extend the functionality to my own hardware hence the reason for this trajectory.
> I know Cape Manager is also part of Rasperberry Pi so maybe I am stuck at a level which is common to both platforms.
>
> I am an embedded engineer, but I haven't played too much in the Linux domain. So I am slowly geting a hold of that domain.
> Embedded devices can be tricky, but there is defined order and structure. If that is obeyed, usually you have good solid results. Especially with silicon that is high volume production.
> I am still trying to work out why this seems so "hard". I am not sure whether its a result of poor architecture, poor documentation or a combination of the two.
>
> It really does frustrate me and upsets me somewhat that we are pushing "newbies" away from development due to complexities which shouldn't be there.
>
> I have seen forum after forum, where people are completely stumped with getting overlays to work. I have even read forums posts from Robert Nelson saying that boot loader of the EMMC gets in the way of the SD boot. Which i find just completely absurd. But maybe its just do you my understanding of the architecture.

Just a couple points..

I don't use Android on these devices, thus i don't support it.. (My
Free time, is My free time. ;) )

The 4.1.x-ti kernel used by: http://www.2net.co.uk/android4beagle.html
was really just a preview release. All the refinement and u-boot
overlay enhancements were done on the: v4.4.x/v4.9.x/v4.14.x releases.

So feel free to swap out the 4.1.x-ti with either 4.4.x-ti or 4.14.x-ti..

With the move to u-boot overlays: the version of u-boot became VERY
important, the bootrom loads u-boot from the eMMC first.. So yeah, if
the version of u-boot doesn't support overlays is installed to eMMC
you have to nuke it. ;)

Regards,

--
Robert Nelson
https://rcn-ee.com/