rpi-ft5406 64 bit #1738
Comments
|
The firmware deals in bus addresses. It has no knowledge of whether the OS is 32- or 64-bit, and it doesn't care. The VPU address space is limited to 1GB, with the top two bits indicating certain addressing modes. The ARM's kernel space is configured to start at bus address 0, so the mask is to remove those upper bits and leave you with a bus address ready to map to a suitable kernel virtual address. |
|
@pelwell Ok so the pointer at ts->ts_base from ioremap at the moment should be perfectly valid for use in for example iowrite32? EDIT: |
|
I don't know off the top of my head, and I'm not about to start digging into 64-bit kernel internals until we decide to support it. |
|
@pelwell Thanks for the support, I don't want to waste too much of your time. The last thing though, my error is as follow: Maybe this can tell you more than that the address is invalid? Also, is there any device tree configs (dma maybe) in the normal 32bit tree related to the address translations for this buffer that I can try in my 64bit one? |
|
It's not obvious to me what is going wrong. I suggest you use pr_err() to display some key values in ft5406_thread. If that doesn't help, disassembler ft5406_thread and post it along with the error and I'll see what I can do. Although we aren't using it in the 4.4 tree, the dma-ranges property does the translation from physical addresses to bus addresses. On a Pi 3 it should be: which says that virtual addresses from 0x00000000 to 0x3effffff map to bus addresses 0xc0000000 to 0xfeffffff. |
|
@pelwell It seems dma-ranges was already there and set correctly. Thanks for the help, I finally got it working. I went through all the code that works with shared memory and reimplemented it to be more platform agnostic and I also changed from writel (u32) to wiritng 99 in 8bit because it is just an 8bit number so now everything works. My fork is a bit of mess with all of the other work that I have done (and on 4.8 ...) so I will have to see what I can do to get a pull request for this driver when I get the time. I'm guessing I'll have to send a pull request to the 4.9 branch? |
|
Nice one. I see no problem with you submitting a PR to the 4.8 branch, since that's where the bcmrpi3_defconfig is. |
|
Ok I'll see if I can do that tomorrow. 4.9 also has bcmrpi3_defconfig but it's pretty broken there (another issue I might deal with later). The only problem with this driver (and the rest) on 4.8 at the moment is that I haven't been able to get dt overlays to load on 64bit so I had to add everything to the normal trees. I guess I can submit only the code for the drivers so long and then try to solve that seperately (maybe open another issue) if anyone wants to be able to use it. |
|
When you say overlays don't work, do you mean using the dtoverlay command line utility or via the bootloader (config.txt)? If you can give me a simple concrete example, ideally not requiring external hardware, I'll add it to the list of things to look at. |
|
@pelwell I'm pretty beat right now and will try to send you a complete example first thing tomorrow morning. I'm talking about the config.txt, I haven't tried the utility yet but that's not what I need anyway. From my experience though you should be able to try any overlay in the overlays folder and see that it has no effect on a 64 build, that is after you manually copy the dts though because at the moment the arm64 folder does not have an overlays directory nor a symlink which is also a problem. |
|
OK - I'll give it a try. Thanks for the heads up. |
|
That wasn't too hard - there's a patch in the rpi-4.8.y tree. It still doesn't build the overlays though - I didn't find a satisfactory solution. |
|
I believe the overlay mechanism is working as it should - I tested it using the dtmerge utility which contains the same code, and just now on a Pi3. Having said that, the 64-bit system is not behaving as I would expect it to. For example, I2C isn't showing up even when enabled, which is because bcmrpi3_defconfig is enabling the wrong I2C driver (bcm2708-i2c instead of bcm2835-i2c). With a corrected bcmrpi3_defconfig it works. Note that if you use the dtbs_install make target then the base dtbs will be installed into the "broadcom" subdirectory - not ideal. It will take time to bring the arm64 configuration in line with the existing arm configurations, and some drivers still need attention (no, vcdbg doesn't work yet). |
|
Getting dtmerge built and running on my machine looks like it could be a lot of effort. I doubt if the issue is with the kernel though, I think the problem has to be with the firmware and config.txt . If it's not to much effort I would appreciate if you could check to see if config.txt works for you. I need my machine to load the overlay at boot so if this doesn't work I'll have to work with custom main trees for now. I'm not sure what procedure the firmware uses to communicate the overlay loading, is there any possibility that this could be broken with the different architecture? I'll work on sorting out bcmrpi3_defconfig as my needs dictate. Lucklily having the dtbs in "broadcom" isn't much of a problem for me. |
|
The entire device tree is visible in /proc/device-tree - what you see there is what was written by the firmware, but with directories for nodes and files for properties.
If you want you can also post a link to your overlay (or email me if you prefer - I won't share it) and I'll check it over. |
|
Ok I'll check the proc. I don't have a fancy overlay yet I am simply talking about the standard stuff like the vc4 or touchscreen overlays. The simplest one I'm working with at the moment is rpi-ft5406-overlay.dts. When I make the dtbo, put it in the overlay folder and ask config.txt to load it then nothing happends but when I instead add directly to "/" in bcm2710-rpi-3-b.dts then it works perfectly. Obviously it just isn't loading but I don't know if there is an error or if the firmware just isn't trying to load it. |
|
The overlay loads for me: Make sure you are spelling the overlay name correctly, and underscores are different from hyphens. config.txt needs to contain: |
|
Ok I'll double check. My fix is now at #1740 . I am also now trying to see if perhaps there is an issue with the DDTK flag on my kernel. |
|
I recommend that you skip the mkknlimg step now - the defaults are DDTK on, and it will try both new (.dtbo) and old (-overlay.dtb) overlays - just cp Image to kernel8.img. |
|
I really don't get it, that just doesn't want to work for me. Could userspace make a difference? I am currently on a yocto build and guess I could try raspbian because the 64bit should run it (I hope). PS. I do have the very latest firmware files. |
|
Should I assume that your device tree with the dtoverlay line is the same as without?
|
|
Yes I'm running exactly the same device tree. My config.txt after cleaning the million comments: And it seems that /boot is actually not being mounted automatically. Is this usually done by fstab? Could that be my problem or is loading done directly with regards to the partition? The contents after manual mounting are: |
|
Both your base DTB and your overlay are smaller than mine. Your kernel looks about right though. Can you upload them somewhere so I can a) compare them to mine, and b) try the dtmerge ? |
|
It seems I was messing with the "compatible" value on the overlay and messed it up a bit. After restoring it it is 462B. The restore did not help though. I have posted both on https://www.dropbox.com/sh/6068fga35idjtvj/AAAa-0MgNHVniV2rlAWI4W_8a?dl=0 and I'll see if I can get dtmerge going. |
|
They both look OK to me, and they merge OK. I can see that you've folded in the firmwarekms, dma and dsi nodes, but otherwise they look the same as mine. |
|
Yes I had to fold them in to get them running. I'm compiling a completely clean kernel from git now and will try to see if any of my other changes did something but I doubt it. Are you using normal raspbian as a rootfs? I'm trying figure out an ideal clean setup to just test overlay functionaility with... |
|
I have an NFS-mounted rootfs which has accumulated some cruft, but it's essentially regular Raspbian. |
|
Ok for some reason both my dirty and a clean kernel load the overlay just fine with Raspbian. I don't know if this is because it is a 32bit userspace or if Raspbian is doing some other magic. Strangely enough though the old touch driver also works with the Raspbian userpace and an arm64 kernel. It's also immediately getting the suggested dma buffer accepted by the firmware instead of having to request one from the firmware. I'll build my userspace in 32bit as well to try and see if that's the difference. I do feel my changes to the touch driver are still relevant though because from what I have read dealing directly with iomem pointers as normal pointers is not entirely legal and very dangerous. I still don't get the effect of userspace though. |
|
The point of maximum confusion has now been reached. It seems that when using a 32bit rootfs (my Yocto or Raspbian) even with the 64bit kernel then the overlay loads perfectly. The strangest things though is that it loads by simply being in the overlay folder, I don't even have to pass anything to config.txt I mean wtf? When dealing with Raspbian I found that when I originally started getting the ft5406 errors, I was dealing with slightly oldish firmware and that the latest firmware is fine with the old code so that's why it works on Raspbian. I'm still puzzled with the overlay loading. I'll double check to see that everyhting in my 64 rootfs is the same as the 32 one I just built but it seems there is definitely something userspace involved in overlay loading in some way. |
|
Because the driver is used by the official RPi display it gets special handling by the firmware in the form of loading the overlay. Off the top of my head I can't remember if there are predicates or if it is unconditional, but it isn't magic. |
|
@pelwell Thanks, that actually helps a lot :) EDIT: |
|
I checked, and when the firmware detects one of the components in the display it will attempt to load the rpi-ft5406 and rpi-backlight overlays. |
|
@pelwell Ahhh that makes sense. It seems I have found the problem after messing around with Raspbian etc. There might have been a lot of other things wrong but it seems the main thing is with the |
|
@pelwell I've been playing around and it seems that the flag has to be in the dts makefile if you want to build the file directly but in your location to be built correctly as part of a full build. Should I add it to the dts folder as well or is there a better way to do it? |
|
Submit a PR explaining why you think it is necessary and I'll give it a try. |
|
Hi, I just wanted to add that fixing bcmrpi3_defconfig is very easy. Just copy over the 4.8 version and run it though "make savedefconfig". That usually fixes it. I may submit a PR in the future to fix it on 4.9 once 4.9 is released and declared to be a LTS release. Although I think having a different config for 64 bit and 32 bit doesn't make sense and is a lot of work to maintain. I think it would be relatively easy to share the configuration between the two. |
|
I've confirmed that the touchscreen overlay is automatically being loaded by the firmware and the touchscreen is working fine for ARM64 in 4.9 and 4.10. If things are working for you, perhaps it would make sense to close out the issue? |
I am trying to get the RPI touch screen working on a 64 bit image and have already got VC4 and DSI working, I only need the touch driver. This is proving difficult because the
writel(99, &ts->regs->num_points);line is causing a crash related to paging to an invalid address. I have concluded that this is caused by some invalid address translation because the driver was hard-coded for 32 bit addresses.I have already tried replacing all the direct pointer dereferencing in the code with the explicit io functions but am still facing the same issue.
I have decided that the problem lies in:
With touchbuf being a u32.
I am more than willing to fix this driver myself, I just can't find any information on the firmware interface and therefore have no idea what type of address translation needs to take place. For instance, does it still provide a 32 bit address when running a 64 bit kernel and what is the reason for
touchbuf &= ~0xc0000000? Basically I just need know how I can map the RPI_FIRMWARE_FRAMEBUFFER_GET_TOUCHBUF to a 64 bit virtual address.I guess one also needs to do the right translation when suggesting to RPI_FIRMWARE_FRAMEBUFFER_SET_TOUCHBUF.
The text was updated successfully, but these errors were encountered: