#ah yea but those are inherent to the PI
1 messages ยท Page 1 of 1 (latest)
๐
what am i lookin for in dmesg
ah and maybe something went wrong with the drm flag for cmdline, you should see a lot of verboose mesages like this
[ 184.619666] [drm:drm_stub_open [drm]]
[ 184.619785] [drm:drm_open [drm]] comm="Xorg", pid=5384, minor=0
[ 184.619887] [drm:drm_ioctl [drm]] comm="Xorg" pid=5384, dev=0xe200, auth=1, DRM_IOCTL_MODE_GETRESOURCES
[ 184.619972] [drm:drm_ioctl [drm]] comm="Xorg", pid=5384, ret=-95
[ 184.620060] [drm:drm_release [drm]] open_count = 1
[ 184.620142] [drm:drm_file_free.part.0 [drm]] comm="Xorg", pid=5384, dev=0xe200, open_count=1
[ 184.620247] [drm:drm_release [drm]]
[ 184.620329] [drm:drm_release [drm]] driver lastclose completed
[ 184.620477] [drm:drm_stub_open [drm]]
[ 184.620567] [drm:drm_open [drm]] comm="Xorg", pid=5384, minor=0
[ 184.620662] [drm:drm_ioctl [drm]] comm="Xorg" pid=5384, dev=0xe200, auth=1, DRM_IOCTL_MODE_GETRESOURCES
[ 184.620747] [drm:drm_ioctl [drm]] comm="Xorg", pid=5384, ret=-95
[ 184.620833] [drm:drm_release [drm]] open_count = 1
[ 184.620929] [drm:drm_file_free.part.0 [drm]] comm="Xorg", pid=5384, dev=0xe200, open_count=1
[ 184.621016] [drm:drm_release [drm]]
[ 184.621096] [drm:drm_release [drm]] driver lastclose completed
[ 184.622168] [drm:drm_stub_open [drm]]
[ 184.622291] [drm:drm_open [drm]] comm="Xorg", pid=5384, minor=0
[ 184.622394] [drm:drm_ioctl [drm]] comm="Xorg" pid=5384, dev=0xe200, auth=1, DRM_IOCTL_MODE_GETRESOURCES
[ 184.622480] [drm:drm_ioctl [drm]] comm="Xorg", pid=5384, ret=-95
[ 184.622569] [drm:drm_release [drm]] open_count = 1
[ 184.622651] [drm:drm_file_free.part.0 [drm]] comm="Xorg", pid=5384, dev=0xe200, open_count=1
[ 184.622741] [drm:drm_release [drm]]
[ 184.622820] [drm:drm_release [drm]] driver lastclose completed
root@devpi:/home/pi# dmesg | grep drm
[ 0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_headphones=0 snd_bcm2835.enable_headphones=1 snd_bcm2835.enable_hdmi=1 bcm2708_fb.fbwidth=720 bcm2708_fb.fbheight=480 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 console=ttyS0,115200 console=tty1 root=PARTUUID=99c577d8-02 rootfstype=ext4 fsck.repair=yes rootwait loglevel=6 drm.debug=0xf
[ 5.992187] systemd[1]: Starting Load Kernel Module drm...
[ 6.297088] [drm:drm_core_init [drm]] Initialized
[ 6.301348] systemd[1]: modprobe@drm.service: Succeeded.
[ 6.302452] systemd[1]: Finished Load Kernel Module drm.
๐ค
hum, I am running a year old system here so maybe that changed in more recent kernels
but that alone doesn't seem to give me the log messages for DSI either currently. Lemme check my notes if there was more to it to enable those
ok do you mind burning a new pi sd with raspbian lite
ah lets maybe use a full distro, I'm not sure the lite still includes the desktop at all?
that could maybe explain why the drm log doesn't post anything, not entirely sure
I run headless here too but it had the desktop installed so I think that was a full sized Raspberry PI OS
my thinking is that they do not start up drm at all there and without it I think you are missing the kms driver as well to output dsi
sorry had a baby thing to check
oh yeah gooooood point, i do recall that tinydrm you have to 'kick' it by sending data to the framebuf
no worries! currently booting up the fresh system
no just Ethernet and the DSI cable
ok let me boot up and ssh in
ah but I failed to setup stuff through the imager, if you haven't either you might get stuck where I am with finishing the first boot setup because the default pw thing is no more
uhhhh i think i found my problem. its a pi3 not pi 4 ๐ญ
oh! hm but I'm not sure if it should make a huge difference
ah right was just checking that haha
useful they added that but easy to miss too
sigh it erased my default settings, ok reburning
at least its fast on USB 3 + class 10
yea those newer UHS V30/60 cards are really quick!
flashes the image in around 40 seconds
ooh that sounds even better
maybe ill get some of those
ok done
ok i'm in!
send me what you're running and ill duplicate
just finished setup, one sec
ok getting an error atm for dsi
but also found the flag that enabled device tree debug messages
so in config.txt I have added to [all]
dtoverlay=i2c0,pins_44_45
dtoverlay=ICN6211
dtdebug=on
the i2c only needed if you use the I2C over the DSI cable
which atm leads
[ 6.850621] vc4_dsi fe700000.dsi: Failed to create device link (0x180) with 1.panel_disp1
ok wanna keep poking at it to see if you can fix?
this is tragically common with raspi, they like to keep up to date which....means a lot of stuff is constantly breaking ๐
yea ๐ฆ
sorry for the wild goose hunt, should have tested with a new image sooner
it means the device tree file is loading at least but sounds like something in their DT setup changed
some of the warnings you got in the compilation (and I also now got) were not all the typical stuff, some of that is definitely new warnings
@serene lichen ok im gonna be in another window. if you dont wanna work on this now, totally cool just send an email if/when ready for a second test
you may have some luck decompiling the 7 inch dtbo
not dumb, think of how much we are learning ๐
you re absoultey right, still trying to adjust my language with these things ๐
so the reason the offical 7inch overlay doesn't work is because it does a i2c probe for their MCU, that fails and it doesn't proceed to enable DSI. Previously I had worked with the ICN via one of those clone display that emulate that IC while attaching my own panels to their breakout, that then worked just fine with the standard overlay because the only difference between those bridge IC drivers is their IC configuration, the DSI aspect is the same and we don't really care about the config here.
In my overlay I had the actual ICN driver loaded for the bridge fragment, the Pi OS image by default does not include this driver and that seems to fail rather silently.
tldr; fix: need to change to line 26 to
compatible = "toshiba,tc358762"; in the dts
hi back was getting some ๐ต
ok let me scp that over
yah i do not want to 'mimic' their i2c
i know DF robot does, but i think its tacky
ok did you isntall the blinka script to get the ICN i2c going
its the "lazy" route for sure and only really works usefully if you use the same resolution, if you don't will have to touch kernel drivers anyways. What it gets you though is bootloader level DSI as currently only their panel is supported in the firmware
I did but actually not sure if I re-ran it on the new system for the config
oh so with the 7" you will get the rainbow test-square
but with this setup its like, whenever the dsi dtb is loaded after a few secs?
yea essentially as soon as the kernel becomes alive
fairly new yea! It gives you lots of debug info too, quite handy
well not a real menu I guess but it tells you whats happening and what its trying to do which is a bit more handy than the old blinky error codes
being headless has me missing out
transfering config on the new image also seems to work fine
ok im configuring this setup ...
sudo update-alternatives --install /usr/bin/python python /usr/bin/python2.7 1
sudo update-alternatives --install /usr/bin/python python /usr/bin/python3.7 2
#update-alternatives --config python
python --version
pip3 install RPi.GPIO
sudo pip3 install --upgrade setuptools
cd ~
sudo pip3 install --upgrade adafruit-python-shell
wget https://raw.githubusercontent.com/adafruit/Raspberry-Pi-Installer-Scripts/master/raspi-blinka.py
sudo python3 raspi-blinka.py
ah! handy command if you want to verify the overlay loaded ok: sudo vcdbg log msg
ok hold on i have to do an apt update and all that jazz
this might be like 5 minutes - ill post when ready โฒ๏ธ
ok ๐
ok successfully installed blinka, wrote config to icn
now let me compile the dts
still got many warns
sudo cp ICN6211.dtbo /boot/overlays/
ICN6211.dts:58.5-15: Warning (reg_format): /fragment@1/__overlay__/panel_disp1@0:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
ICN6211.dts:71.5-15: Warning (reg_format): /fragment@1/__overlay__/reg_bridge@0:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
ICN6211.dtbo: Warning (pci_device_reg): Failed prerequisite 'reg_format'
ICN6211.dtbo: Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
ICN6211.dtbo: Warning (simple_bus_reg): Failed prerequisite 'reg_format'
ICN6211.dtbo: Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
ICN6211.dtbo: Warning (spi_bus_reg): Failed prerequisite 'reg_format'
ICN6211.dts:57.31-68.6: Warning (avoid_default_addr_size): /fragment@1/__overlay__/panel_disp1@0: Relying on default #address-cells value
ICN6211.dts:57.31-68.6: Warning (avoid_default_addr_size): /fragment@1/__overlay__/panel_disp1@0: Relying on default #size-cells value
ICN6211.dts:70.29-77.6: Warning (avoid_default_addr_size): /fragment@1/__overlay__/reg_bridge@0: Relying on default #address-cells value
ICN6211.dts:70.29-77.6: Warning (avoid_default_addr_size): /fragment@1/__overlay__/reg_bridge@0: Relying on default #size-cells value
ICN6211.dtbo: Warning (avoid_unnecessary_addr_size): Failed prerequisite 'avoid_default_addr_size'
ICN6211.dtbo: Warning (unique_unit_address): Failed prerequisite 'avoid_default_addr_size'
alright so im adding the dtoverlay to /boot/config
dtoverlay=ICN6211
should i still do the cmdline debug step too?
pi@devpiX:~ $ dmesg | grep dsi
[ 0.051794] platform 3f101000.cprman: Fixed dependency cycle(s) with /soc/dsi@7e700000
[ 9.300934] vc4_dsi 3f700000.dsi: Failed to create device link (0x180) with 0.panel_disp1
[ 10.869572] vc4-drm soc:gpu: bound 3f700000.dsi (ops vc4_dsi_ops [vc4])
pi@devpiX:~ $
[pi4]
# Run as fast as firmware / board allows
arm_boost=1
[all]
enable_uart=1
#dtoverlay=i2c0,pins_44_45
dtoverlay=ICN6211
dtdebug=on
[ 9.300934] vc4_dsi 3f700000.dsi: Failed to create device link (0x180) with 0.panel_disp1
yea had them too, haven't looked into them yet but don't seem criticial
pi@devpiX:~ $ sudo vcdbg log msg
Failed to allocate -201253077 bytes for message buffer
????
oh weird
loglevel=6 drm.debug=0x14is what I currently have appended in my cmdline.txt but that won't fix that vcdbg msg
yea can't hurt to remove more differences
console=serial0,115200 console=tty1 root=PARTUUID=bd563b1b-02 rootfstype=ext4 fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles loglevel=6 drm.debug=0x14
let me reboot
kinda rad
luv when so much error log it wraps
haha
ok i do have a pi4
[ 9.726703] vc4_dsi 3f700000.dsi: Failed to create device link (0x180) with 0.panel_disp1
still
oh wow lots of error messages
one sec
oh funnily enough I still get that error too but its outputting DSI happily lol
huge
huh sorta is implying that it is outputting 800x480
let me see if theres any signal on the dsi lines?
no nothing ๐ค
ok what if i put this onto my pi4
yea that looks like a similar setup log as I'm getting atm
yes
(worth checking)
for sure
googling that it seems to pop up for a lot of people on Pi3's
https://github.com/raspberrypi/firmware/issues/1670
lol
welp my pi 4 isnt booting and im somewhat running out of time today - i have a hackchat at 2pm and then 2 hours of video at 6pm
so despite feeling close i do have to put this away
ok!
did you short the pads on the back and use the DSI I2C for the config? (tahts the extended bus thing?)
right yes, totally forgot to write that in the mail. Bridging the pads on the back and the using the i2c0 overlay for pins 44 and 45 to have i2c0 run on the DSI cable
and on the SAMD just empty loop so it doesn't interfere
and yea thats why I had to use extended bus as thats the easy way to make use of i2c0 with Blinka