ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development - Did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait for an answer! - This channel is logged at https://oftc.irclog.whitequark.org/linux-sunxi
gnarface has quit [Remote host closed the connection]
sunshavi_ has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
KREYREN_oftc has quit [Remote host closed the connection]
Asara has quit [Quit: leaving]
KREYREN_oftc has joined #linux-sunxi
Asara has joined #linux-sunxi
gnarface has joined #linux-sunxi
macromorgan has quit [Ping timeout: 480 seconds]
<veremitz> A20 .. lol ..
montjoie_ has joined #linux-sunxi
montjoie has quit [Ping timeout: 480 seconds]
macromorgan has joined #linux-sunxi
sunshavi has joined #linux-sunxi
paulk has quit [Ping timeout: 480 seconds]
paulk has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 5.2.0 Quasar http://www.kvirc.net/]
JohnDoe_71Rus has joined #linux-sunxi
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
junari has joined #linux-sunxi
macromorgan has quit [Ping timeout: 480 seconds]
<diego71> A20 is a nice little cpu
<JohnDoe_71Rus> but old
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<machinehum> libv: What were the laptops they were selling at Fosdem?
<machinehum> The ones they used for AV?
<libv> machinehum: yes
warpme has joined #linux-sunxi
<libv> machinehum: they buy them cheaply in bulk from a reseller of old corporate laptops
<libv> like 100s of them
<libv> and they are used as both av ones, and as terminals for people at the info stands
<libv> machinehum: btw, if you want to see how some of them were used in the previous video setup, there's a picture in my slides of my 2020 talk: https://archive.fosdem.org/2020/schedule/event/videobox/
<libv> JohnDoe_71Rus: ageist.
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<machinehum> Do you remember the model of latops they used?
<machinehum> T470's?
<libv> would have been a 2
<libv> t2xx
<libv> i would have to ask
<libv> why so?
<libv> and this changes every year depending on what is available
<machinehum> Just curious
<machinehum> Shopping around for a new laptop and kinda kicking myself I didn't pick one up there
<libv> well, ever since i learned that someone ported coreboot to a hp 820-g2, i decided to stick with my 840-g2 for a bit longer
<libv> and i even picked up a few others and fully decked them out to match my 840, and used one as a shell replacement
<libv> i got a socket for the bios chips as well
<libv> just have not gotten around to it
<libv> it sadly lacks 4x pcie nvme, and usb-c, but since i am not doing yocto builds on this machine, it's perfectly adequate
<libv> and it still has buttons on the touchpad
<libv> (yes, i am old)
<machinehum> nice, also thanks for link to the video box. I think usb-c is a hard and fast requirement for me
<libv> try to find some old corporate laptops, they are everywhere
<libv> just googling for a 4+y old laptop should get you plenty of hits
<machinehum> tyty
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<libv> half the corporate laptops sit in dockingstations for 3 years before they get replaced
<libv> the other half might see some abuse
<tokyovigilante> I do love a good thinkpad, have a new one and an X230 tablet you can pry from my cold dead hands. Run linux and a tiling WM about as well as each other
<tokyovigilante> apritzel: have powered up the cldo4 line but no wifi yet
<Jookia> tokyovigilante: have you checked with a meter the chip has power? it could also be there's a reset gpio
Schimsalabim has quit [Ping timeout: 480 seconds]
<tokyovigilante> I have not, good idea
<tokyovigilante> was hoping all my power troubles were over
Schimsalabim has joined #linux-sunxi
<tokyovigilante> any advice on where exactly? the wifi chip is on the top right of the board but don't have a pin-out
<tokyovigilante> getting 1.8v from what I assume is pin 1
<tokyovigilante> ah, thanks the FCC
<tokyovigilante> hmm, should really be finding 3.3v somewhere
<Jookia> tokyovigilante: pin 1 is NC you probably want to check pin 4. but if the pins aren't exposed that might be difficult
<Jookia> pin 31 is reset
apritzel has joined #linux-sunxi
<tokyovigilante> oh no, seems I just can't cope with copy and paste, missed a DT chunk
<tokyovigilante> [ 19.913216] rtw_8821cs mmc2:0001:1: Direct firmware load for rtw88/rtw8821c_fw.bin failed with error -2
<tokyovigilante> feel like that is promising
<tokyovigilante> although wonder if it should be looking at mmc1
<Jookia> yes, that is promising
<Jookia> i think these match based on an ID on the sdio bus
<Jookia> so this might be correct
<Jookia> not sure
<Jookia> but definitely grab the firmware!
<tokyovigilante> it's ther
<tokyovigilante> *ther
<tokyovigilante> *there, but have just realised it probably doesn't like being xzipped in the fedora image
<tokyovigilante> [ 16.656924] rtw_8821cs mmc2:0001:1: Firmware version 24.11.0, H2C version 12
<tokyovigilante> more like it
<tokyovigilante> wlan0: disconnected "wlan0" wifi (rtw_8821cs), 02:06:51:1A:39:6E, hw, mtu 1500
<Jookia> woo!
<Jookia> time to do some wpa_supplicant and dhcp? :)
<tokyovigilante> wlan0: connected to likeaboss "wlan0" wifi (rtw_8821cs), 68:8F:C9:13:55:57, hw, mtu 1500 ip4 default, ip6 default inet4 192.168.1.200/24
<tokyovigilante> Network<anager even!
<tokyovigilante> Sep 27 13:00:55 fedora sshd[350]: Server listening on :: port 22.
<Jookia> congratulations on wifi :)
<gamiee> tokyovigilante : this is amazing! great job :)
<tokyovigilante> Thanks! Pretty sure you get 99% of the credit
<tokyovigilante> and apritzel did all the DT work for me
<tokyovigilante> Just got in over SSH, time to throw this serial adaptor in the bin...
<gamiee> haha, keep the serial in, it might be still needed
<tokyovigilante> I'm sure I will inevitably break something in the next 5 minutes
<Jookia> serial over usb otg is a good compromise i've found
<tokyovigilante> Just running a very slow `dnf upgrade`
<apritzel> tokyovigilante: awesome, great news, was already about to ask ...
<tokyovigilante> Jookia: does that work? I'm using it for fel-boot, can you then get a serial console?
<apritzel> tokyovigilante: well, it's serial over USB, so requires some more software layers to work, which makes it less useful in debugging situations
<Jookia> yeah, it's not very useful for early boot
<tokyovigilante> ok, will leave it in pieces a bit longer
<apritzel> but it's definitely possible, and you can get even at least one more USB device over the same wire, typically, like networking or mass storage
<Jookia> i find USB ethernet and static IPs over OTG a really good compromise when it comes to doing kernel development because you can easily just rsync/copy over files and tell it to reboo then wait, read logs, etc
<apritzel> tokyovigilante: can you post a boot log somewhere. I am actually surprised the AXP717 driver worked right away without acting up (b/c I didn't actually test it)
<tokyovigilante> I have made a small change to it to also set DCDC2, will collect one
<Jookia> having to constantly move SD cards around gets old fast
<tokyovigilante> the u-boot axp driver I mean, your kernel one seems fine
<apritzel> I also updated the DT, being a bit more daring now that we know what voltages the BSP programs
<Jookia> tokyovigilante: but congrats on getting this far!
<apritzel> I am actually surprised it easily boots for you, I was expecting the kernel turning off regulators killingthe boot process
<apritzel> tokyovigilante: out of curiosity, do you get a late "random: crng init done" message from the kernel? I see that only after like 4 minutes or so
<tokyovigilante> That's the whole axp driver I've got, and the DT is in that tree now
<tokyovigilante> I haven't seen that yet but will keep an eye
<apritzel> the kernel should report that crng message at some point, the question is just how long it takes
<tokyovigilante> There's the boot log up til login
<Jookia> looks like the init is after 11 seconds
<tokyovigilante> oh yup, good spot
<Jookia> hopefully this weekend or next week i'll be able to get back to kernel hacking :)
<tokyovigilante> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
<tokyovigilante> 457 root 20 0 463292 343296 32512 R 98.7 34.6 2:28.60 dnf
<tokyovigilante> poor H700
<tokyovigilante> How fast is this thing really?
<tokyovigilante> DNF5 got a C rewrite and is much faster to be fair
<tokyovigilante> I'm still getting "Failed to set core voltage! Can't set CPU frequency" about 75% of the time in SPL, how worried should I be? I was pleased to get the DRAM timings right but not clear if they are totally correct
<apritzel> tokyovigilante: those poor A53 cores running at 1 GHz are really nothing to write home about. And together with HighSpeed SD card this just gives you a slow system
<tokyovigilante> heh fair
<apritzel> tokyovigilante: we don't have cpufreq yet (hopefully in the next cycle), so the CPU frequency is stuck at what's set in U-Boot
<tokyovigilante> not expecting miracles ofc, I'm hoping to build my hobby SDL music player and a couple of linux pixel game ports, and have those plus the ability to run a terminal and connect a bluetooth keyboard
<tokyovigilante> Total download size: 430 M
<tokyovigilante> Is this ok [y/N]:
<tokyovigilante> got there in the end...
<apritzel> and this U-Boot message might mean it's actually even slower
<tokyovigilante> apparently it's 1.5Ghz for what its worth
<tokyovigilante> I have mentally approximated it to an rPi3, which I don't find to bad, have a couple round the house doing various IOT jobs
<apritzel> tokyovigilante: I am pretty sure it's not running at 1.5GHZ
<apritzel> I mean that's the max frequency we support, but without cpufreq you won't get that
<tokyovigilante> right
<apritzel> tokyovigilante: try this tool, that's good ol; "mhz": https://paste.c-net.org/SweetieVirgins
<apritzel> it's a statically linked arm64 binary, so should work everywhere, and measure the actual CPU frequency, with some clever algorithms
<tokyovigilante> cool
<tokyovigilante> getting a whole bunch of these, but wifi seems fine
<tokyovigilante> [ 1162.678042] rtw_8821cs mmc2:0001:1: timed out to flush queue 1
<tokyovigilante> getting about 2MB/sec for my upgrade
<tokyovigilante> 406 MHz, 2.4631 nanosec clock
<tokyovigilante> some room to improve then ;)
<apritzel> that's what I thought, and that's probably due to that U-Boot message
<apritzel> can you power cycle? that should avoid the message, and then you should get 1 GHz ish
<Jookia> 406MHz? Pentium 3 sounds...
<tokyovigilante> yup, will let this upgrade run
<Jookia> congrats on getting a working system so far though :)
<apritzel> tokyovigilante: also, as a hack, if you put "return 0;" just before the rsb_init() call in TF-A's plat/allwinner/sun50i_h616/sunxi_power.c, that might avoid the message and thus the slow frequency
<tokyovigilante> thanks! I had very little to do with it though
<tokyovigilante> apritzel: I think the message is actually from SPL rather than TF-A
<tokyovigilante> will give it a try though, clearly TF-A is also failing
<tokyovigilante> U-Boot SPL 2024.04-rc3-00011-g1b2bbe2a6d-dirty (Mar 08 2024 - 23:08:56 +1300)
<tokyovigilante> DRAM: 1024 MiB
<tokyovigilante> Failed to set core voltage! Can't set CPU frequency
<tokyovigilante> Trying to boot from FEL
<tokyovigilante> NOTICE: BL31: v2.10.0(debug):v2.10.0-503-g27b0440a8
<apritzel> tokyovigilante: yes, the message is from SPL, because TF-A "messes up" the PMIC, and doesn't return it to I2C mode
<tokyovigilante> right
<apritzel> or actually this might not help, because in case of a reboot I think it's the kernel leaving the PMIC in RSB?
<Jookia> power management and clocking, the two worst things in embedded
<apritzel> yes, but also fun, since you can play around and eventually fix things
<apritzel> and get a 200% performance improvement!!!
<Jookia> or save a lot of battery :D
<apritzel> very true
<tokyovigilante> 300% with cpufreq
<apritzel> +200% I meant, didn't want to pull that old marketing trick ...
<tokyovigilante> heh very good
warpme has quit []
<Jookia> '100% improvement!' followed my brain making hdd clicking noises
<libv> apritzel: i am about try a new version of the infobox, where the stupid headerXX/labelXX/dataXX crap no longer is necessary
<JohnDoe_71Rus> for video A20 needs hdmi-audio. but it still wip
<libv> there should also be some logic, so multiple values can be handled per field transparently
<libv> JohnDoe_71Rus: it also has no h264 encoding, or sprites in the rather powerful display engine
<libv> and some bugs in display and clocking that i have not upstreamed
<apritzel> libv: please don't upstream bugs ;-)
* libv frowns at apritzel
<libv> the code i wrote in 19 and 20 for the fosdem videobox uses quite a bit of the display engine, and i ran into all sorts of things that were never tested or implemented
<tokyovigilante> I thought that was what point releases were for? ;)
<tokyovigilante> LUDICROUS SPEED
<tokyovigilante> 1007 MHz, 0.9930 nanosec clock
<tokyovigilante> nice
<tokyovigilante> sudo dnf install crysis
<tokyovigilante> that's with skipping rsb_init in TF-A
<Jookia> interesting
<Jookia> tokyovigilante: are you going to end up making some SD card images with fedora for people to try and test? :)
<tokyovigilante> I hadn't intended to, I'm hoping some of the other groups making BSPs based on the vendor ones will migrate over to using mainline kernel and 64-bit userspace, but if not, needs must
<tokyovigilante> realistically this is literally just the fedora 39 server image with a manually built kernel copied in. I could probably just delete the EFI partitions, stuff the kernel image in /, put u-boot on at the EFI 128k offset, and call it a day though
<apritzel> tokyovigilante: wait, what, is the vendor firmware ARMv7?
dsimic is now known as Guest2210
<tokyovigilante> not the ideal system for a tiny handheld with a d-pad for an interface though, they're really just made to boot straight into retroarch
dsimic has joined #linux-sunxi
<tokyovigilante> apritzel: no it runs a 64-bit kernel, circa v4.9, but a 32-bit userspace, and the video/GL driver they provide is 32-bit and a binary blob, so there's no way to run anything 64 bit with a GUI
Guest2210 has quit [Ping timeout: 480 seconds]
sunshavi has quit [Remote host closed the connection]
sunshavi has joined #linux-sunxi
warpme has joined #linux-sunxi
<apritzel> tokyovigilante: ah, interesting choice
<tokyovigilante> There's a chap on the muOS board who's keen to work on a rootfs
<apritzel> and I agree there is little point in floating ($nr_boards * $nr_distros) images around
<tokyovigilante> I'm 95% sure this is the LCD, are the wiki instructions on plugging in the specs still acurate?
<apritzel> well, the problem is not so much the display data, most parameters can be already found in the vendor DT
<tokyovigilante> yeah, I'm keen to just get what I can mainlined, and hope to move the community along a bit, relying on closed source vendor BSPs seems like a dead end
<apritzel> the problem is that there is no upstream *display engine* for the H616 even
<gamiee> tokyovigilante: I forgot, on what device do you working on?
<tokyovigilante> H700, in one of these: https://anbernic.com/products/rg35xx-plus
<Jookia> tokyovigilante: panel drivers aren't too hard to make, but you will need the panel init code
<apritzel> on top of that we would need RGB LCD support, which is actually not in the H616 (just in T507 & H700)
<gamiee> ah yeah, I just wanted to be sure, because there was someone working on mainline for projector :D
<gamiee> so I got bit confused D:
<apritzel> not sure if jernej has TCON code beyond HDMI in his DE33 patches
<Jookia> tokyovigilante: if you can get the GPL code of the BSP kernel you should be able to yank the panel driver. maybe
<Jookia> but yeah you need DE first
<tokyovigilante> heh, I think Anbernic are worse than Allwinner in that regard
<gamiee> if it's really that display from buydisplay.com , there should be documentation with init code.
<tokyovigilante> allegedly this is the driver chip - https://www.buydisplay.com/download/ic/NV3052C-Datasheet-V0.2.pdf
<apritzel> as a customer you would have the legal right to ask for the GPL code
<libv> in a similar vain, i marked all the display work beyond a33 for u-boot as TODO
<libv> as it is disabled per default in the sunxi config
<libv> seems like it was never completed for u-boot
<apritzel> what do you mean with display, exactly?
<tokyovigilante> apritzel: I know in theory, but they are distributing 64GB of pirated roms in their BSP
<apritzel> I know ;-)
<libv> hdmi, lcd
<libv> tokyovigilante: it's only 45GiB
<tokyovigilante> oh, that's not so bad then ;)
<apritzel> libv: HDMI works fine on the A64, and at least some LCDs through bridges
<apritzel> (Pinebook, Pinetab, Teres-I)
<gnarface> afaik hdmi audio is still not working on the A64
<apritzel> we don't have DE support for R40, H6, H616. There is some R40 patch somewhere, and allegedly the H6 is not far from that, but nobody cares enough about "graphical output" in U-Boot to upstream that
<gnarface> at least, it's still not working on the pinebook
<tokyovigilante> I really need macromorgan to pop in, he did heaps of display work with the other Rockchip-based Anbernic devices, noting the Allwinner one may be different
<tokyovigilante> I'm not so worried about u-boot either, but obviously want output from linux
<apritzel> you could somewhat cheat Linux output through simplefb, if U-Boot sets everything up, that's was the solution for a time on A64
<apritzel> but I think for the H616 native Linux support is actually closer
<apritzel> libv: that's the legacy code
<libv> ... ok?
<libv> oh,
<libv> config VIDEO_DE2
<apritzel> check for SUNXI_DE2 below
<apritzel> exactly
<libv> *sigh*
<libv> will fix later
<apritzel> actually somewhat needs to refactor that old sunxi code to fit into DM_VIDEO, DE2 is actually more compliant in this regard
<apritzel> but I think that involves porting all the panel code, too ...
<libv> well, when i originally wrote the u-boot hdmi code in 2014, u-boot was still all global variables and it had no real abstractions like a device model
<tokyovigilante> hey I'm not complaining, got all the way to wifi in a week! :)
<libv> coming from coreboot half a decade earlier, which had that from its start, i still cannot believe uboot survived to this day
<tokyovigilante> interesting
<tokyovigilante> "Anbernic sends me the devices for free and I mainline/maintain them as best I can." Maybe not so bad after all
<libv> and since JohnDoe_71Rus decided to complain about allwinner a20 being old, the universe just rewarded me with my bga stencils for it arriving early
<libv> just now
<libv> in case i do need to go there for a fosdem videobox, it was worth getting those now while they are still available
<tokyovigilante> I'm out, thanks for the help again guys
<Jookia> tokyovigilante: o/
<apritzel> tokyovigilante: cu!
<JohnDoe_71Rus> my cb2 rest on shelf scince 2013 :( but can show youtube
<apritzel> libv: U-Boot changed massively in the last decade, and DM is everywhere now. I actually expect someone to pull the plug on non-DM_VIDEO at some point
<apritzel> I expect the actual older display engine conversion not being too hard, but IIUC the panels would need to plug in quite differently
<libv> JohnDoe_71Rus: my cubietruck with its acryl semi-case has its ethernet and usb ports getting corroded by my greasy fingerprints of 11ys ago and the dust that's on it
<libv> so yeah, my a20s are collecting dust as well
<libv> olimex still is able to buy them in bulk from allwinner as needed though
<libv> apritzel: ok
<libv> as for DM, it took them long enough, even with such a limited and simplistic codebase
<libv> back then
<libv> while writing the original a20 hdmi code for it, i was all the time wondering why people did not just use coreboot on this hw instead
<libv> perhaps due to the fallacy of anything arm being "embedded"
<JohnDoe_71Rus> fingerprints was at ethernet out the box. some cubietech worker :)
<libv> speaking of a20, does anyone have a useful scribd account?
<libv> it would be nice to add this schematic to the wiki: https://www.scribd.com/doc/262751231/ORANGEPI-A20-V1-1-schematic-pdf
<Jookia> oh that reminds me
<Jookia> there's a rp-t113 som but the only way to download the bsp is through baidu
<Jookia> there's a service that is like 'pay us $5 and we'll upload it to a google drive', has anyone used something like this
<apritzel> Jookia: why would you need the BSP? To find the DT in there? Or the schematic?
<Jookia> both i think yes
<Jookia> and i guess do a sanity check that the hardware works :)
<libv> don't we have a few people here with access to baidu directly?
<Jookia> i think all the services for wechat/qq/etc don't take australian phone numbers
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
<machinehum> libv: Is there a reason why a simple mirrorless camera can't be used?
<machinehum> Holy shit the video box innerards ;o
<libv> machinehum: no idea, this is a rented camera (x25)
<libv> machinehum: this is the splayed out version
<libv> i actually only disassembled this thing 2 weeks ago
<libv> it also includes an extra bit, namely the WIP videobox based on the a20 lime
<machinehum> ahh
<machinehum> Oh maybe the cameras you rent have wireless mic support and stuff?
<libv> yeah, did you not see that when you helped with teardown?
<libv> they have 2 XLR inputs, which is balanced audio (somewhat like lvds, so two wires carry opposite signals and noise gets cancelled out)
<libv> and optional phantom power (12/24/48V)
<libv> which is important for some mics
<libv> a used cam is about 1600, the wireless mic is about 700
<machinehum> That's actually quite a bit cheaper than I would assume
<machinehum> Smart, I see
<libv> well, that's notsocheap when you need more than 25 of those
<libv> in 2013, when they were gearing up for doing full video recording for 2014, they were calling around rental shops
<libv> first asking for cameras and wireless mics
<libv> only to then reveal that like 28 would be needed
<libv> the story i heard from some of the core organizers then is that at one such rental shop the answer was "what? wtf are you doing?"
<machinehum> lol
<machinehum> How much does it cost to rent all that?
<machinehum> The boxes you're showing in the video, are these the same you used this year?
<libv> no real idea, but fosdem doubled it budget in 2014
<libv> nope, they now moved to a usb capture device and a laptop
<libv> which was not without problems
<machinehum> ah, so doubled the amount of laptops
<machinehum> One per room (in the room), one per room (in the server room)
<machinehum> That was a really silly way of saying that lol. Two per room: one in the room and in the actual serverroom?
<wigyori> Jookia: which t113 board/som do you have?
<Jookia> wigyori: i have the mango pi mq but my boss is testing the rp-t113/
<wigyori> that's the one which has 100meg ethernet, but is using the clock from the soc ?
<Jookia> i'm not sure, it might be
<wigyori> couldn't get the ethernet working on that on mainline
<Jookia> interesting, i have working ethernet on that with mainline
<wigyori> which kernel ?
<Jookia> 6.6 i think
<wigyori> hmm, okay
<Jookia> i didn't do anything fancy, i just connected a phy
<machinehum> libv: Awesome talk I wantched the whole thing. Makes me wanna do A20 things
<apritzel> machinehum: please don't, let it enjoy its retirement ;-)
<Jookia> i use an a20 lime2 for testing some things. they're pretty cool
<machinehum> apritzel: lol
<machinehum> Are they EOL/hard to get etc...?
warpme has quit []
macromorgan has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
warpme has quit []
bauen1 has joined #linux-sunxi
qwestion has quit [Ping timeout: 480 seconds]
<jernej> tokyovigilante, apritzel: H616 LCD (LVDS or RGB) support is pretty trivial on top of my H616 HDMI patches. MIPI DSI probably not, but I haven't looked into that.
<apritzel> jernej: ah, good to know, thanks!
<apritzel> so tokyovigilante could take your patches, to first get HDMI to work (there is a mini-HDMI socket), and then we hope for macromorgan to plumb the LCD on top ...
<apritzel> which might stuff like the backlight (PWM?) and surely some secret power rails ...
<apritzel> *might involve
warpme has joined #linux-sunxi
<jernej> pwm is annoyingly close to that in D1, they basically just shifted few bits arounds for no apparent reason
<jernej> anyway, do we know panel type? rgb, lvds, dsi?
<apritzel> pwm> yes, I have a patch to abstract those bits away, on top of the proposed D1 series
<apritzel> haven't tested or finished that, though
<macromorgan> I have a RGB panel to work with
<apritzel> the panel type is RGB
<macromorgan> sorry, I've been sidelined the last week with a broken computer, just now got it back up and running so I can look again at the H700
<apritzel> macromorgan: ah, great, welcome back (from your Rockchip vacation?)
bauen1_ has joined #linux-sunxi
<macromorgan> that, plus I had a CPU die on me and in the process of troubleshooting it I acidentally killed my OS install
<apritzel> ouch
<macromorgan> first time in 30 years I had a CPU straight die without another underlying root cause, which is why it was such a pain to troubleshoot
<apritzel> macromorgan: if you scroll up the logs, tokyovigilante got it booted from SD, with serial and WiFi, including the AXP Linux driver
<gamiee> macromorgan: intel or amd? (via? :o :D )
<macromorgan> sweet!
<macromorgan> AMD... my Ryzen 5900x died 3 months out of warranty
bauen1 has quit [Ping timeout: 480 seconds]
<macromorgan> upgraded to a 5950x... didn't want to switch to AM5 because I have so much RAM in my system and didn't want to rebuy it in DDR5
<apritzel> macromorgan: we were hoping for your panel experience to close that gap ;-)
<gamiee> ouch, that sucks. But what happens to devices? Last week, my Pixel just softbricked itself. (I recovered it thid Monday, OTA somehow fixed it)
<jernej> apritzel: have you implemented passthrough mode by any chance in PWM driver?
<macromorgan> okay... let me dust off my device and start working again
<apritzel> jernej: ah, no, that was indeed another thing on my todo list. Shouldn't be such a big thing, though, we can surely copy that bit from the other drivers
<apritzel> (that's actually the thing I was after: to enable the clock for the AC300)
<jernej> I think you don't actually need it, since driver can chose APB1 parent and create 24 MHz clock from it
<jernej> but passthrough would be more efficient for sure
<jernej> macromorgan: is BSP DT accessible somewhere?
<jernej> tnx
junari has quit [Ping timeout: 480 seconds]
chewitt has quit [Quit: Zzz..]
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<macromorgan> so where was the H700 at? Sorry but I don't have IRC logs anymore either (broken computer). I really should get a bouncer...
<gamiee> (also, for bouncer, I recommend Quassel, best IRC bouncer and app ever)
<apritzel> macromorgan: tokyovigilante figured out working DRAM parameters earlier this week. And we made a basic DT, which includes the AXP
<macromorgan> sweet
<apritzel> there is more code to write for the AXP, the patch I made just covers the regulators (which are blockers)
<apritzel> there is the whole interrupt part, which is mostly transferring the IRQ names and bits from the datasheet into a struct in the driver
<apritzel> then there is battery charging, which should mostly be a copy & paste job from the AXPs, I guess the 803 might be a good candidate
<macromorgan> okay cool. Let me build a Debian environment. Right now I had resigned to using the vendor U-Boot but if you guys have open working all the better.
<apritzel> and then there is the USB type-C support, which requires a new driver to be written, because it's the first AXP chip supporting this
<apritzel> there are some low hanging DT fruits about the buttons: I put one in, this would need to be verified, then copied
<apritzel> USB is another thing to try. We probably want the single port to be a "fixed device" one for now, until we get AXP type-C support
KREYREN_oftc has quit [Remote host closed the connection]
<apritzel> this would allow USB gadgets, which will also help development
warpme has quit []
apritzel has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
bauen1_ has quit [Ping timeout: 480 seconds]
vagrantc has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
hentai has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<Jookia> uh, not an ad, but baidudownloader dot com came through and i now have the sdk for the rp-t113
<gamiee> baidudownloader dot com is amazing
<gamiee> I have multiple stuff downloaded through them, it always worked perfectly
<Jookia> oh that's good to know
<Jookia> i MIGHT be ending up making a dt/port for this boards/om. i don't actually have the board yet though
<Jookia> libv: this thread might have the orange pi schematic but requires registration. i registered but maybe someone else here has an account: www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=42
acmeplus has joined #linux-sunxi
acmeplus has quit []
warpme has joined #linux-sunxi
<tokyovigilante> Not getting anything from the buttons with gpio status
<Jookia> are you sure they're gpio buttons?
<tokyovigilante> Not at all, was just a suggestion from apritzel
<Jookia> ah
<tokyovigilante> Obviously they may not be... any way to find out from the vendor BSP?
<Jookia> hmm
<Jookia> device tree can give some hints if the adc is being used i think
<tokyovigilante> Could just boot and see what xev says I suppose
<Jookia> yeah that would work
<Jookia> if you have a live system you can figure it out from /sys
<tokyovigilante> oh no here it is, they're all in the vendor DT as GPIOs
<Jookia> nice!
<tokyovigilante> I assume that's where apritzel got the one he put in from
JohnDoe_71Rus has quit [Quit: KVIrc 5.2.0 Quasar http://www.kvirc.net/]
warpme has quit []
warpme has joined #linux-sunxi
warpme has quit []
<libv> Jookia: so you have access?
<libv> about the t113 sdk/bsp, is this something we should carry on dl.?
colinsane has quit []
colinsane has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel> yes, in the vendor DT all buttons are GPIOs, I just picked one as an example
<apritzel> tokyovigilante: in U-Boot, try "gpio status -a", that should list all pins, regardless of U-Boot knowing about them or not
<apritzel> or maybe name one specifically (like "gpio status pa6"), I think this works as well
<tokyovigilante> found those, just don't seem to be getting any response when I run with/without button pressed
KREYREN_oftc has joined #linux-sunxi
<tokyovigilante> PA6 not showing as configured either
<apritzel> try "md.l 0x300b000 5"
<tokyovigilante> 0300b000: 77777777 00077777 00000000 00000000 wwwwww..........
<tokyovigilante> 0300b010: 00000000 ....
<apritzel> right, now do: "mw.l 0x300b000 0", then repeat the above command
<apritzel> this configures PA0-PA7 as GPIO input, the lowest byte in the last word then contains the status of those pins
<apritzel> then keep dumping the registers while pressing buttons, according to the DT there were several on PortA
<tokyovigilante> 0300b000: 00000000 00077777 00000000 00000000 ....ww..........
<tokyovigilante> 0300b010: 000000ff ....
<tokyovigilante> 0300b010: 000000bf
<tokyovigilante> that's with d-pad up pressed then released
<apritzel> here we go: PA6
<tokyovigilante> PA6: input: 1 [ ]
<tokyovigilante> more like it
<tokyovigilante> and pressexd
<tokyovigilante> PA6: input: 0 [ ]
<tokyovigilante> only d-pad up is working, but the 4 other buttons are, and some of the back buttons
<apritzel> so now you have a nice mechanical exercise, perfect procrastination excuse ;-)
<tokyovigilante> fair ;) how do I get that enablement bit into DT form?
<apritzel> I guess you figured, but in the vendor DT "<0x4b 0x00 0x06 ..." means: primary GPIO controller (PA-PK), port A (0=A, 1=B, ...), pin 6
<tokyovigilante> yup, but that doesn't seem to be effective without that extra bit we just twiddled
<apritzel> look at that gpio-keys node in my update patch
<tokyovigilante> yeah I have that one for the dpad-up in mine currently
<apritzel> I don't know if U-Boot cares about those bits, but the kernel should
<apritzel> ah, you need CONFIG_BUTTON_GPIO in U-Boot
<apritzel> then they should be listed in the normal "gpio status" output
<tokyovigilante> but the PA bank wasn't configured as input
<tokyovigilante> ah right
<apritzel> maybe we miss GPIO A from the U-Boot driver, PortA is not connected on the H616
<tokyovigilante> I've got PA1-31, and by default only PA13-31 are input currently
<apritzel> well, those pins are not implemented, so the bits are forced to zero
<apritzel> you can probe this by writing 0xffffffff to the first four words
<apritzel> and then check which bits stick if you read that back
<apritzel> (4 bits per pin)
<tokyovigilante> ok, CONFIG_BUTTON_GPIO wasn't enabled eiher
<tokyovigilante> Interestingly the mappings in the vendor DT are wrong, ie the Y button is on the left/west, but is hardcoded as 0x133 which is BTN_NORTH (or BTN_X)
<libv> if you would have to categorize the 35xxp, what would you call it, handheld console?
<libv> and would we label the nes and snes mini as console?
<libv> what about the c64 mini?
<tokyovigilante> That's what Anbernic calls it, the RG35XX is basically a Game Boy clone
<tokyovigilante> Can you guys think in hex? I have never quite managed it
<libv> depends on what you call thinking in hex
<apritzel> I find decimal quite annoying, so yeah, hex it is
<libv> tokyovigilante: start python, paste your hex value in there, to print a decimal value in hex run: "%X" % (whatever calculation you want)
<tokyovigilante> fair
<tokyovigilante> Oh no I just mean having to think what 0x0b is, rather than just seeing 11
<libv> if you've been banging bits for a longer time, then basic A-F is normal
<libv> then it is also normal to start to know which bit is which in a 32bit hex value, which comes from looking at datasheets too much
<tokyovigilante> I would best describe myself as an amateur script kiddie, who spent most of the 2010s on a mac and so can only cope with high-level languages (NOT C++) using hand-holding system frameworks, so I have skiied well off the green slope here
<libv> tokyovigilante: if unsure: run python, "0x%X" % (1 << 23)
<libv> i hate programming in python, but i usually have some python interpreter open somewhere to do some calculations for me
<tokyovigilante> I feel like every time I want to use python, I get started with something and then it can't do GL, or run a tight loop fast, and I go back to swift
<apritzel> less heavy than Python and more readily available: on the shell: printf "%d\n" 0x1234
<libv> but then you would have to type printf all the time
<tokyovigilante> that's the other thing that throws me, 4660 is a much larger number than 0x1234 in my head, but not in reality
<apritzel> or install radare2: "rax2 1234", "rax2 0x123*8" "rax2 -k 0xb0*16"
<libv> whereas a python interpreter is just open for me somewhere, and when i need it for something, i tend to need it for multiple things
<tokyovigilante> ok, just to be clear, for example, gpios = <0x4b 0x04 0x01 0x00 0x01 0x02 0x01>;
<tokyovigilante> would be PE1?
hentai has quit [Quit: SIGTERM]
<apritzel> yes
<apritzel> that translate then into: <&pio 4 1 GPIO_ACTIVE_LOW>; in mainline
<tokyovigilante> yup
<tokyovigilante> ok, all done, apart from for some reason the vendor one defines L3 and R3 which aren't on the device
<libv> ok, so i do have access to the dl machine directly
<libv> so if the T113 SDK/BSP needs to be stored there, hit me up
<tokyovigilante> and I don't need anything else in the DT for "md.l 0x300b000 5"? The PA6 GPIO wasn't registered until I did that
<apritzel> in U-Boot? I think that was due to missing CONFIG_BUTTON_GPIO
bauen1 has joined #linux-sunxi
<tokyovigilante> have enabled that now with the same behaviour
<tokyovigilante> yeah in u-boot
<tokyovigilante> haven't tried booting into linux to test yet
<tokyovigilante> realistically it's irrelevant for u-boot
<apritzel> indeed, but it's typically easier to hack those things in U-Boot, since there is no jealous kernel in the way
<tokyovigilante> true
<tokyovigilante> should I have AXP_GPIO enabled?
<tokyovigilante> nice, all working in linux, slightly weird most showing two keycodes (using showkey)
<tokyovigilante> keycode 4 release
<tokyovigilante> keycode 32 release
<tokyovigilante> keycode 4 release
<tokyovigilante> keycode 32 release
<tokyovigilante> that's for d-pad up, also weird release event for both press and release
<tokyovigilante> I mean, I love linux, but I also hate linux
<tokyovigilante> I love how the irony goes completely over the head of half the reviewers
<libv> why love or hate linux?
<libv> isn't it just a fact, something that is just there?
<libv> (yes, i am bored, i am poking at mediawiki crap)
<tokyovigilante> I have a job which is not at all about software, but relies entirely on capable software, so I am encouraged to feel very strongly about it
<tokyovigilante> most of the things we like run on linux (and are technically embedded), and most we hate run on windows
<tokyovigilante> But also that book is written by people who love linux, and have written what I take as very sharp satire about its flaws, basically linux sucks, because all software sucks, linux just sucks less ;)
<tokyovigilante> But you also don't have to be philisophical, agreed
<tokyovigilante> ok, this should be accurate as per the vendor DT for all the buttons