buzzmarshall has quit [Quit: Konversation terminated!]
renrelkha has quit [Quit: bye]
renrelkha has joined #beagle
ikarso has joined #beagle
vd has quit [Ping timeout: 256 seconds]
Shadyman has quit [Quit: Leaving.]
xet7 has quit [Remote host closed the connection]
Guest5940 has joined #beagle
<Guest5940>
hi
<Guest5940>
someone knows how to flash firmware on BeagleBone Black?
Guest5957 has joined #beagle
<Guest5957>
it is possible to reflash BIOS on BeagleBone Black?
xet7 has joined #beagle
Guest5940 has quit [Ping timeout: 256 seconds]
Guest5957 has quit [Ping timeout: 256 seconds]
otisolsen70 has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
zjason` is now known as zjason
Guest5975 has joined #beagle
Guest5975 has quit [Ping timeout: 256 seconds]
Guest5960 has joined #beagle
<Guest5960>
why do I get disconnected?
GenTooMan has quit [Ping timeout: 252 seconds]
Guest5960 has quit [Ping timeout: 256 seconds]
GenTooMan has joined #beagle
<zmatt>
hmm, does the web chat client not auto-reconnect?
<zmatt>
after a ping timeout
buzzmarshall has joined #beagle
lucascastro has joined #beagle
starblue has joined #beagle
starblue has quit [Quit: WeeChat 3.0]
calculus has quit [Ping timeout: 252 seconds]
calculus has joined #beagle
<GenTooMan>
it's probably as "simple" as possible so probably not
<GenTooMan>
zmatt remember a web "programmer" wrote the code which means "GOK" what they did and did not do.
<zmatt>
it's kiwiirc, the main developer of which is Darren Whitlen (prawnsalad) who has worked on lots of irc-related projects for many years including the ircv3 specification
zmatt-test has joined #beagle
<zmatt>
(it's also definitely not a very simple client)
zmatt-test has quit [Client Quit]
russ has quit [Ping timeout: 252 seconds]
russ has joined #beagle
vd has joined #beagle
<vd>
zmatt hi -- The screen is working! I compared the old working dts and mine was missing &epwmss1 { status = "okay"; }; !
<zmatt>
ah yeah whenever you enable an ehrpwm, ecap, or eqep module, you also need to ensure the parent epwmss is enabled
<zmatt>
not sure why really
<zmatt>
they could just have been left enabled by default, I'm pretty sure the kernel would automatically suspend them if none of the three child devices are enabled
<vd>
ok good to know
<vd>
so the device tree works both with the tilcdc,panel driver with timings and no port nodes, OR with the okaya compatible (panel-simple) but requires the port nodes in the lcdc and panel
<vd>
also all power-supply are not necessary in the end. I choose to use the okaya compatible and remove the dummy supply.
<vd>
I prefer not to specify my own panel-info / display-timings if an existing driver works fine)
<vd>
the power-supply documented as required but in fact isn't is a mystery.
<vd>
My very last step now will the the touchscreen on spi1 and/or trying to run a web browser as a PoC (a light fb ideally)
buzzmarshall has quit [Quit: Konversation terminated!]
<zmatt>
well, it's giving a warning on the missing power-supply property right?
<vd>
well I don't see it anymore
<vd>
can it be because of pwmss1?
<zmatt>
no?
<vd>
ho no it's there for the pwm-backlight and panel-simple: "supply power not found, using dummy regulator"
<vd>
does SPI has bus discovery?
<zmatt>
no
<vd>
with evtest I have an Atmel input for the screen and touching it generates lots of input
<vd>
I only enabled the SPI1 pinmux
<zmatt>
if you didn't declare an spi device then whatever is generating those events is not an usb device
<zmatt>
*an spi device
<vd>
but that's definitely the touchscreen
<vd>
can it be because of the panel-simple driver?
<zmatt>
no
<zmatt>
is it not an usb device/
<zmatt>
or instead of guessing you can also just check
<zmatt>
e.g. in sysfs, or using udevadm
<zmatt>
ls -l /sys/class/input
<vd>
I'm not guessing, I just run evtest and touched the screen and a lot of inputs are generated
<vd>
event1 is ../../devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1/usb1/1-1/1-1.4/1-1.4.1/1-1.4.1:1.1/0003:03EB:215D.0002/input/input2/event1
<zmatt>
guessing about how the device is connected I mean
<zmatt>
voila, it's an usb device
<zmatt>
not spi
<vd>
I get that, maybe I was unclear but what I was trying to say it that I'm confused that touching the screen generates events on this event1 input
<zmatt>
why are you confused about that?
<vd>
i donno, i thought the touchscreen was a SPI device which I did not even declare yet, so what are these events?
<zmatt>
well, it's clearly not an SPI device but a usb device
<zmatt>
hence it got auto-discovered
<vd>
I'm even more confused then. On the schematics I have a ad7843 device using the pins MCASP0_*, the AIN* (and GPMC_AD10 for LCD_PEN_INT# aka PENIRQ#). I've pinmuxed the MCASP0_* pins as SPI1 mode, that's all I've done so far
<zmatt>
an external digitizer for a 4-wire touchscreen is kinda weird in itself since 4-wire touchscreens can be connected directly to the BBB
<zmatt>
regardless, it sounds like you have some investigating to do regarding how to reconcile what the schematic says with the appearance of a usb touchscreen device
<vd>
would that help if I try to recompile the dts without the spi1 pinmux to see what happens?
<zmatt>
no
<vd>
or with &spi1 disabled
<zmatt>
spi has nothing to do with usb
<zmatt>
and enabling an spi bus (with or without pinmux) does absolutely nothing until you also declare one or more spi devices on that bus
<vd>
ha
<zmatt>
if your schematic doesn't show a usb-connected touchscreen controller, then your schematic doesn't match your hardware (which will make your job a fair bit more... interesting)
<vd>
that is totally likely that they cannot get the spi touchscreen to work so went with an usb one on top
<vd>
if that's the case, it wouldn't hurt to declare the spi touchscreen as the schematics described anyway I suppose
<zmatt>
it probably would
<vd>
it would hurt?
<zmatt>
either the spi touchscreen controller is omitted, which would confuse the driver, or it's present but not connected to the touchscreen, which means you'd get bogus data
<vd>
in that case I can declare it but set status = "disabled".
<zmatt>
you could but that would be pointless
<vd>
the thing is that the spi device is certainly there, even unused. Can an USB device be disabled via device tree?
<zmatt>
I mean, it seems implausible that they'd literally add one touchscreen on top of another... it seems more likely they connected the touchscreen to a usb touchscreen controller instead of the spi touchscreen controller
<zmatt>
check the hardware I guess
<vd>
I will
<vd>
how do I get the name of the product?
<vd>
I can only find the product and vendor ID
<zmatt>
I mean, that's enough to look the thing up online, but you can also try using lsusb
<vd>
wtf, the board rebooted itself
xet7 has quit [Read error: Connection reset by peer]
xet7 has joined #beagle
<vd>
zmatt: Bus 001 Device 006: ID 03eb:215d Atmel Corp.
<zmatt>
huh, 03eb is indeed Atmel, but 03eb:215d is not in the usb.ids list and has zero google hits
<zmatt>
custom?
* vd
asks around
otisolsen70 has quit [Quit: Leaving]
buzzmarshall has joined #beagle
vagrantc has joined #beagle
calculus has quit [Ping timeout: 245 seconds]
calculus has joined #beagle
GenTooMan has quit [Ping timeout: 240 seconds]
GenTooMan has joined #beagle
<vd>
zmatt I finally got the answer, new iteration of the hardware (which I obviously don't have the schematics for) use an atmel usb touchscreen...
<vd>
SPI touchscreen will need to be supported too, and I don't know if the LCD_PEN_INT# irq line is used with the usb or not
<vd>
I hope a single devicetree could support both spi and usb touchscreen? (I have to confirm first if the usb one *replaces* the spi one or if the spi one is there but just unused)