<tokyovigilante>
thanks, I have something similar but still having problems even as root, the device seems to be reconnecting itself to the bus each time I try and access it. Good to know eudev works though
<tokyovigilante>
Is there any host kernel config that may be required beyond a standard usb stack?
<apritzel>
tokyovigilante: do you see something in dmesg when the board enters FEL mode? (And is it actually entering FEL mode?)
<tokyovigilante>
lsusb says yes... Bus 001 Device 022: ID 1f3a:efe8 Allwinner Technology sunxi SoC OTG connector in FEL/flashing mode
<tokyovigilante>
cd: I/O error
<tokyovigilante>
but even accessing the /dev fails - cd /dev/bus/usb/001/022 Sat 1:07 PM
<tokyovigilante>
cd: Unknown error trying to locate directory '/dev/bus/usb/001/022'
<tokyovigilante>
[ 1049.467052] usb 1-7: USB disconnect, device number 22
<tokyovigilante>
[ 1049.579260] usb 1-7: new full-speed USB device number 23 using xhci_hcd
<tokyovigilante>
[ 1049.703667] usb 1-7: New USB device found, idVendor=1f3a, idProduct=efe8, bcdDevice= 2.b3
<apritzel>
is that some power issue, maybe? Either on the host or the device side?
gsz has joined #linux-sunxi
<apritzel>
That's the most common problem I had when encountering those kind of issues
<tokyovigilante>
quite possibly, although using the same cable and port as when I was running Fedora.
Daanct12 has joined #linux-sunxi
ftg has quit [Read error: Connection reset by peer]
<tokyovigilante>
USB device 001:043 Allwinner H616 33806c00:9c004808:01070c71:2c6f1e52
<tokyovigilante>
apritzel: do you have a ip-based tftp config? was using network-manager previously to assign the correct static IP to my host
vagrantc has quit [Quit: leaving]
<apritzel>
tokyovigilante: do you mean for when the device provides an Ethernet gadget via OTG, and the host needs to pick that up quickly, because U-Boot is impatient? No, not for that case
<apritzel>
I am using an USB-Ethernet adapter for loading
<apritzel>
tokyovigilante: but I am all ears if you come up with something ;-) I feel like udev might help out here, since there could be rules for network i/f appearing?
<tokyovigilante>
i do, was quite handy having network-manager remember and assign the address. will have a play.
<tokyovigilante>
in theory allow-hotplug in /etc/network/interfaces should work.
hallyn has left #linux-sunxi [#linux-sunxi]
apritzel has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
<tokyovigilante>
in practice it doesn't seem to apply a static IP
<tokyovigilante>
eth2 Link encap:Ethernet HWaddr DE:AD:BE:EF:00:00
<gnarface>
i don't use network-manager myself, but i do know it will conflict with any configuration in /etc/network/interfaces, and at some point in the past couple years they turned mac address randomization on by default, which might further complicate things
<gnarface>
like, for starters, udev assumes the mac address will never change, so when it sees a new one, it thinks it's a new device and iterates the name index
<tokyovigilante>
yup, I'm not using NM either, ironically when I was using it it worked well and would remember the config based on MAC address and would apply the static IP, struggling to do it with kernel networking alone
<gnarface>
possibly unrelated, at some point a few years back, Debian changed the default generation rules for /etc/network/interfaces from using "auto" to using "allow-hotplug" and on most my machines that basically just stopped networking from operating entirely, and i had to change them back to "auto" by hand
<tokyovigilante>
yeah debian has an entire rant about it on their wiki. I'm using Alpine at the moment
<gnarface>
maybe if you actually had a network device that was actually a hotplug capable device it makes more sense but most of my machines do not
<tokyovigilante>
90% of the time its great not to have systemd, 10% I miss it slightly
<tokyovigilante>
interestingly the dev name is eth2 not usb0
<tokyovigilante>
[ 5686.271739] usb 1-8: new high-speed USB device number 96 using xhci_hcd
<tokyovigilante>
[ 5686.476872] usb 1-8: Device not responding to setup address.
<tokyovigilante>
[ 5686.271994] usb 1-8: Device not responding to setup address.
<tokyovigilante>
[ 5686.684677] usb 1-8: device not accepting address 96, error -71
<tokyovigilante>
[ 5686.684777] usb usb1-port8: unable to enumerate USB device
<tokyovigilante>
hmmm, wonder if this is a autosuspend thing too
wasutton3 has joined #linux-sunxi
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
<MoeIcenowy>
apritzel: drm/panel is for panels that attached to other parts of the system, e.g. MIPI DSI panel attached to DSI controller, or RGB panel attached to TCON that needs extra configuration via another bus
<MoeIcenowy>
ah here it means the display data source is another part of the system
<MoeIcenowy>
drm_mipi_dbi and fbtft is similar, except the latter uses deprecated fb subsystem (but supports more panels)
<MoeIcenowy>
they are handling panels that deliver display data via SPI
Jookia has left #linux-sunxi [#linux-sunxi]
parthiban has joined #linux-sunxi
parthiban has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
gsz has joined #linux-sunxi
parthiban has joined #linux-sunxi
Daanct12 has quit [Quit: WeeChat 4.4.3]
apritzel has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<apritzel>
MoeIcenowy: I see, so does this MIPI-DBI driver provide the whole stack then? Because the panel hardware has a built-in framebuffer, so I don't need DE or TCON, for just a status display
parthiban has quit [Ping timeout: 480 seconds]
gsz has quit [Ping timeout: 480 seconds]
bauen1 has quit [Ping timeout: 480 seconds]
<gamiee>
MoeIcenowy, apritzel : (from what I remember and understood) MIPI-DBI is basically improved SPI with more (accelerated) lines for displays. MIPI-DBI peripherals mostly have accelerated R/W pins, multiple data lines, or QSPI modes.
gsz has joined #linux-sunxi
wingrime-ww has quit [Ping timeout: 480 seconds]
warpme has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
ftg has joined #linux-sunxi
tokyovigilante has quit [Read error: Connection reset by peer]
tokyovigilante has joined #linux-sunxi
warpme has joined #linux-sunxi
ity1 has joined #linux-sunxi
ity has quit [Ping timeout: 480 seconds]
<wens>
apritzel: AFAICT the st7789v driver (drivers/gpu/drm/panel/panel-sitronix-st7789v.c) is a full blown display driver
<wens>
author is mripard
warpme has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
hazardchem has quit [Read error: Connection reset by peer]
hazardchem has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
dsimic is now known as Guest703
dsimic has joined #linux-sunxi
Guest703 has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
<MoeIcenowy>
apritzel: yes I think so
<MoeIcenowy>
wens: I think it's not a full display driver
<MoeIcenowy>
only a panel configuring driver
<MoeIcenowy>
for some panels that needs extra configuration sequence
<MoeIcenowy>
gamiee: I think MIPI-DBI is a big concept, with both MCU-bus and SPI-bus included
<MoeIcenowy>
MCU bus seems to be beyond what the kernel currently support now
<apritzel>
yeah, my impression was as well that it's just a panel, when looking at the code
warpme has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
gsz has quit [Ping timeout: 480 seconds]
warpme has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
warpme has joined #linux-sunxi
<loki666>
MasterR3C0RD are your u-boot patches available somewhere, and do you think it would help with the dram detection issue I have on H700?
<gamiee>
MoeIcenowy : yes, it have multiple variations. Need to take look on it someday.
<MasterR3C0RD>
loki666: My U-Boot patches are in a trunk branch on my GitHub, but they aren't set up for the H616 yet. Waiting on boards to start refactoring the H616 side of things so I can get support for the A100 added there
<loki666>
Ok don't hesitate to ping me for testing
<MasterR3C0RD>
Sounds good! For clarification, was your device one of those 3GB/1.5GB devices?
<loki666>
No it's just 1gb LPDDR4, but sometimes it gets detected as 2gb
<MasterR3C0RD>
Ah right, that likely points to some address mapping weirdness. Still need to figure out what causes the mapping quirks on the DRAM controller; perhaps at some point I'll find an A133 board with 4GB of RAM so I can fuzz the address mapping
warpme has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
gsz has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
gsz has joined #linux-sunxi
warpme is now known as Guest731
warpme has joined #linux-sunxi
apritzel has joined #linux-sunxi
Guest731 has quit [Ping timeout: 480 seconds]
ity1 has quit []
ity has joined #linux-sunxi
<hlauer>
Tested a few things with BPI-M2-Ultra V1.0 and V1.1 today: There is no power on the USB port on V1.1 - on V1.0 it's even available when powering on without a sd card. And V1.0 tells also "Port not available" in U-Boot, while still powering the port. Very wierd...
<jakllsch>
or just buggy?
<jakllsch>
(probably DT issue or whatnot)
<hlauer>
Hmm - I thought about a short on the board, but maybe it's something completely different
<jakllsch>
i remember having USB problems on some sunxi board or another in u-boot and it was just poorly done u-boot integration for the board
<jakllsch>
(or SoC or something)
LordKalma has quit [Quit: Server has probably crashed]
LordKalma has joined #linux-sunxi
LordKalma has quit []
LordKalma has joined #linux-sunxi
<apritzel>
mmh, according to the DT and U-Boot's defconfig, GPIO PH23 should control VBUS for the dual USB-A ports
<apritzel>
but the schematics do not reflect that, instead VBUS is hardwired to VCC 5V, so should always be on
<apritzel>
hlauer: so the schematics says it's for v1.0, and that would match your observation
<apritzel>
if you are on the U-Boot prompt, you could try to use "gpio set PH23", and see if that enables power - but that actually already be done by the code, so it's probably not that GPIO
<hlauer>
Yes. Will try, probably out of the running system
<apritzel>
hlauer: you could also try to use "gpio clear ph23" on the v1.0, and see if that turns off the voltage, just to confirm this
<hlauer>
good idea
<apritzel>
hlauer: do you know how new the v1.1 is? Was v1.0 a very early version, and v1.1 came out quickly after that?
<hlauer>
v1.1 contains the A40i, v1.0 the R40. So v1.1 is rather new
warpme has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
<hlauer>
lots of sellers images are still showing the R40, but this seems not to be available anymore
<apritzel>
right, so we assume that the initial wave. during the initial enablement, was v1.0
<hlauer>
I read a comment in a german microcontroller forum about a non compatible version without R40, so I got the v1.1 one about half a year ago
<apritzel>
so Armbian has PH23 as well in their DT, but two vendor-provided Ubuntu 16.04 images (with BSP based DTs) do not mention any requirement for USB, nor use PH23 anywhere
gsz has quit [Ping timeout: 480 seconds]
<hlauer>
What needs to be changed in DT to remove PH23? Then I could try if the usb setup of PH23 is resetting the SoC - that would explain, that there seems to be kernels out which are working on v1.1
<apritzel>
hlauer: just remove or comment the two vbus-supply lines in the usbphy node, at the end of the DT
<apritzel>
and maybe remove the whole reg_vcc5v0 node at the beginning, just to be sure
vagrantc has joined #linux-sunxi
<apritzel>
hlauer: that would be for Linux, in U-Boot also remove the two _VBUS_PIN lines from the defconfig file
<apritzel>
tested this on the BPi M2 Berry, its little sister: PH23 there is required and works as expected: if I disable it, no USB device is detected
<apritzel>
hlauer: do you have *any* working image? Something from BPi, for instance? Then you could dump /sys/kernel/debug/gpio in there and check for used GPIOs
<MasterR3C0RD>
Not sure how useful it is, but I took the A523 user manual PDFs from the DeciHD repo, merged it, added an outline/bookmarks and removed the Allwinner watermark in the background
<MasterR3C0RD>
s#useful#useful and/or if I'm allowed to upload it to the wiki#
<apritzel>
very useful indeed, I found the three-split very annoying to work with!
<apritzel>
so can you please try to upload it?
<MasterR3C0RD>
Sure; the ToC is a little barebones, and some of the contents links are broken because of the merging, but I can improve the ToC as time progresses at least
<apritzel>
what tools did you use? pdftk?
<MasterR3C0RD>
pdftk to concatenate and add the outline, qpdf to decompress/recompress the PDF, mutils to extract the images and find the files for the watermark, and sed to remove the watermark draw commands
<MasterR3C0RD>
Probably a better way to do it but I couldn't figure it out; if it works it works HAHA
<apritzel>
ah, yeah, I also used UNIX tools in the past to remove watermarks
<apritzel>
how did you add the outline exactly? do you have some index text file with titles and page numbers?
<MasterR3C0RD>
I used some tool I found (HandyOutliner) to manually create the outline at first, then turned into a pdftk outline since I wanted to add the outline without corrupting anything else :))
<apritzel>
curious how complicated it is to add entries for each clock, as in the other manuals, so one can quickly jump to say "0x830 SMHC0"
<apritzel>
if you send me the index file, I would be happy to create those entries
<MasterR3C0RD>
Sure, I'll gist them. The file is not fun to play with though; pdftk uses probably the worst format ever to define the "bookmarks"