Mainline Shield Tablet(st8) support - Weird framebuffer issue.

[winsock]

Visualization:
https://imgur.com/a/KWjF0
https://youtu.be/-yHrsPXEJ2U

Kernel seems to boot fine at the current tip of linux next: (f7ac28a6971b43a2ee8bb47c0ef931b38f7888cf). However it seems like either tegrafb, nvidiafb, or nouveaufb tries to takeover unsuccessfully as seen in the photo/video.

When using @Gnurou's st8 branch it boots farther, gets into userspace and runs init. Then kernel-panics after init fails to mount the rootfs.(I have busybox in the boot image; shouldn't the kernel just drop me down to a minimal shell to mount root manually if it cannot switch to the "real" root?)

Having access to a TTY level or RS232 level interface would help!

Few questions to get the full boot-log:

• Does the shield tablet's/tegra's echi controller offer a debug port? (The specific tegra chipset for the shield tablet is the TD575D-A1)
• Is it possible nvidia could make public if the JTAG/RS-232 interface pins are routed out to an unpopulated connecter on the PCB?

(Fun facts on the PCB there is an unpopulated Mini-PCIE connecter and unpopulated spots for another 2GB of ram.)

The kernel config used:
https://raw.githubusercontent.com/Gnurou/linux/st8/arch/arm/configs/tegra_defconfig
This is the current device tree that uses simplefb: (decompiled after it was compiled in the kernel tree)
https://gist.github.com/winsock/680938e51501c31a5335

Warnings from dtc when decompiling the binary blob

• Warning (ranges_format): /ahub@70300000 has empty "ranges" property but its #address-cells (1) differs from / (2)
• Warning (ranges_format): /ahub@70300000 has empty "ranges" property but its #size-cells (1) differs from / (2)

Pinging @Gnurou - Taking you up on your offer!

[winsock]

@Gnurou, I think I have it it userspace now. Problem is lack of an OTG cable since it didn't auto connect to my wifi(I set it up while chrooted in it with sshd). Will let you know of any progress on using nouveaufb.

[winsock]

@Gnurou Have you tested/tried to use a keyboard or actually used the tablet when you booted to userspace? I cannot seem to get OTG working. Enabled the OTG support in the kernel and every USB Gadget type. Tegra EHCI is compiled in. I see nothing in the log about usb controller init though.

[winsock]

Some progress, I ported the rm31080a touchscreen driver from the 3.10 tegra tree. Bad news still cannot figure out how to enable OTG. I think the issue is that the regulator isn't switching to providing power when a OTG cable is connected and/or a misconfigured device tree. I have been cobbling it together from string dumps of binary blobs and kernel boot logs from android to see what devices are enabled and at what addresses. Here is the messy DTS though if you want to take a look:
https://github.com/winsock/linux-next-st8/blob/st8/arch/arm/boot/dts/tegra124-st8.dts

Oh yea I was able to pull off a systemd journal file via android since the root is just on the sd-card. Doesn't appear to contain anything interesting though.
https://gist.github.com/winsock/27ee5782cfdc00ce8122

[Gnurou]

Hey, sorry for the delay - I am currently traveling.

The picture and video you post seem to indicate that a display clock is turned down. This would happen if a required clock is not referenced in the device tree. You can probably mitigate this by adding the clk_ignore_unused option to your kernel command-line.

I suppose that the video you posted is still using simplefb, as in my tree? If you want to switch to a real driver, you will probably have to remove simplefb first. On ST8 the display driver to use is tegradrm - Nouveau is only used for the GPU, not for display. For a first time I'd suggest to keep simplefb until you can at least get decent input.

OTG is something I am less familiar with. I am not sure about the state of OTG support in the Tegra USB driver. You may want to have a look at the ST8 Android tree to see whether everything is in place. I never used USB in my tree.

I agree that a serial console would be very useful. Since you mention the PCB I assume that you have opened your ST8? If so I can have a look at the schematics to see if the pins are visible. Alternatively, I suspect that you can twiddle the pinmux to route the serial lines over the SD card pins. Then if you can get your hands on a micro-SD sniffer, you should be able to have a serial console (the voltages will probably need to be adjusted somehow - I am not a hardware guy so don't know much about the details).

I will try to have a closer look at your DT in case I can see what is missing for OTG - since I am on the move, it may take a few days, apologies for that! :)

[Gnurou]

A few possibly useful links for the OTG issue:

https://devtalk.nvidia.com/default/topic/872807/usb-otg-functionality-in-jetson-tk1/
https://devtalk.nvidia.com/default/topic/897104/jetson-tk1-usb-otg-client-mode/

These concern L4T though. Mainline is supposed to be less feature-complete, so the tegra-otg driver may not even exist there. @thierryreding , do can you comment on the state of OTG on T124 mainline and whether there is an easy way to put a controller back in host mode?

[Gnurou]

Also what if you change the dr_mode property of the USB phy to "host"? Aren't use able to plug a USB device and use it?

[winsock]

@Gnurou I have two Shields, one taken apart and in "bare" pcb form, and one that is still together. I found that you in fact can put UART over the sd-card interface. It is actually in the st8 3.10 code:
http://nv-tegra.nvidia.com/gitweb/?p=linux-3.10.git;a=blob;f=arch/arm/mach-tegra/board-ardbeg.c;h=6aeba0fdc4ce0f8dbbefda5677535e59761a040a;hb=rel-st8-l-r7-shieldtablet8#l246

You are correct the tegra-otg driver was not in the mainline code, I'll try to port it. If that doesn't make a difference I'll try to set the port to host only mode but the fact that there is no 5v out on the usb port means that I would have to splice in power to make any device work. I'm guessing that's part of what the OTG driver does, signaling the usb regulator to switch to sourcing power instead of sinking it.

Edit:
Oh, don't worry about the delay! It was the weekend, and I understand that people have other things to do then programming!

[winsock]

Is it possible to get a document on all(or most of) of the ST8 hardware specifications if such a document exists? I think part of my issue is that as it stands, my device tree is not functioning too well and possibly re-writting one from scratch without influence from the Tegra 3.10 tree might help remove some bugs.

I have "reversed" a semi complete device list based off of the device tree blob on my device. I don't have a clear picture on the memory mapped devices or their registers and addresses. For that I have been relying on the 3.10 Tegra tree on nv-tegra.nvidia.com.

[winsock]

Some clarification here from "nvidia,tegra124-car.txt" would be nice also:

- clocks : Should contain phandle and clock specifiers for two clocks:
  the 32 KHz "32k_in", and the board-specific oscillator "osc".

None of the existing device trees in mainline for tegra have any reference to the board-specific oscillator "osc." Is it needed? I also cannot find it even in the Android device trees.

[winsock]

I actually cannot get simplefb working again. I reset my branch to the tip of linux-next and started the device tree from scratch and got rid of all of the warnings that I had before. I see nothing preventing simplefb from starting, however all I get now is what I showed in the first post (Except no text behind the screen glitch). I actually really doubt it is a pixel clock issue since I set it implicitly to what I found in the output of the console during android boot.

<7>[    0.140326] disp1 pclk=155774400
<7>[    0.140337] disp2 pclk=297000000

I am assuming DC 1 corresponds to the DSI interface however. Having a skim over the TRM of the K1 was useful in this attempt.

@Gnurou Do you know if the pinout/pinmux of Jetson is similar to the Shield Tablet? (For the pins it does trace out?) Since I do have that document; being a registered embedded developer at nvidia.com

Edit:
Here is the device tree(The whole commit contains only the device tree stuff)
winsock/linux-next-st8@9b7b037

[winsock]

Does the Tegra K1 Datasheet apply to the TD575D? There is no mention of that particular chipset.

[Gnurou]

ST8 layout documents are internal, but I can probably share specific details. That will have to wait until I get back to the office on Jan. 5th. Same thing for trying your tree/code on an actual device.

When the ST8 is powered on, the display is initialized and remains in that state when the kernel takes over. This is that the simple-framebuffer driver takes advantage of (it just writes pixel data into the address of the linear framebuffer used by the bootloader, without any other knowledge of the hardware). If your display breaks, this means the kernel is touching a clock or regulator that affects the display. To avoid this I'd suggest starting with a really minimal DT (and the clk_ignore_unused option) with very few regulators declared. Unless a regulator is declared, the kermel should not touch it, but it tends to switch as many things off as possible as it knows about them. So start with a minimal DT, and add things little by little.

In the past I have also debugged such issues by introducing 1 or 2 seconds delays in the kernel boot sequence to detect when the display corruption happens and "bisect" the exact step (and eventually exact clock/regulator) where it happens. It's a little bit boring, but it works.

For USB, yeah a Y cable that supplies power from another source should be good to get you started - I did the same to run mainline on the SHIELD portable, and it allowed me to use devices. Actually my work on the SHIELD portable might be useful to you too, even though again it's a bit outdated:

https://github.com/linux-shield/kernel/tree/roth

The Jetson TK1 and ST8 are probably too different to use the Jetson as a reference - but a mininal DT to get simplefb to work, and looking at my roth work to enable USB host (while using the exact information contained in the ST8 Android tree) should get you there. I will also try to be more useful when I get back to the office as I am interested in seeing this working! :)

[winsock]

Okay it was actually my memory definition, just using 0x80000000 and a length of 2GiB doesn't work.
This is interesting though, when I uncommented the i2c device tree stuff, the kernel appeared to "hang" and then after 30-45 seconds later then boot.
Also does simplefb provide a drm1.1 interface? If not then I'm somehow using nvidiafb, as I have also seen nvidiafb_init and [drm] Initialized drm 1.1.0.[numbers]

[winsock]

Obviously I don't expect you to reply until you get back to the office it's the holidays! I just will forget to ask these kind of questions if I don't write them out when I think of them! Interesting effect when you remove the linux,initrd-start/end properties in the chosen node. It still boots and I see console text for a split second but the display tries to modeswitch or handoff to nouveau or something and then the display goes blank with backlight on.

[winsock]

It seems like I cannot get init running from my boot image. The only major difference is instead of blindly copying in all the android tegra124 device trees I just heavily based new device trees off the the android ones. Because of that I don't have tegra124-tn8.dsti, tegra124-soc-shield.dtsi, or tegra124-soc.dtsi as well. I just include the mainline tegra124.dtsi directly.

[thierryreding]

simplefb does not provide a DRM interface. The message that you're seeing is the DRM subsystem initializing. Also, even if you're seeing messages about nvidiafb_init() being called that doesn't mean the driver is actually used. There is no device that the driver could bind to, so most likely it's simply registering, but not doing anything else.

On Tegra the driver that you want for display is Tegra DRM. You can enable it using the DRM_TEGRA symbol. But like @Gnurou said that is likely going to make things harder for now. The easiest is to stick with simplefb and completely disable the Tegra DRM driver for now. If enabled it will try to take over the display and fail, because it doesn't know the panel, and might screw up the existing configuration while at it so that simplefb won't display things properly anymore.

[thierryreding]

@Gnurou: There is zero support for USB OTG upstream. I've been meaning to look at this for years now, but it was never important enough. It would be nice to get that working, though, because you could do interesting things like a USB serial port or similar. Or, I guess, an ADB.

It's not trivial to do, though, because I don't think there's a driver for the hardware yet. There's some code in U-Boot that can speak device mode (used for the UMS support) but I don't think the kernel has anything equivalent. Also we do have two devices (in Tegra114 and onwards) that support device mode: USBD and XUSB. USBD might be easier to implement because of the existing U-Boot implementation that could serve as a reference. Well, the downstream implementation could of course also be used. I think ChromeOS now has a device mode driver for XUSB and some infrastructure to dynamically switch between host and device mode, so it might be worth investigating if that gets us anywhere.

[Gnurou]

@winsock hey, so I'm back and can probably be more actively helpful. Is there anything you need me to test / would like information about?

[dcz-self]

Hi,
what is the way to build the 3.10 kernel with UART over SD support? I've tried the Bogdacutu kernel, but none of the tty's seem to be output to the DAT1 pin. I'd like to gather some basic knowledge before I deep dive into the debugging cycle.

Slightly off-topic: is recovery mode available on the production st8 devices? From Tegra Boot Flow, nothing indicates that it's disabled, but also the 3.10 kernel cannot reboot into it out of the box. Can it be triggered otherwise?