<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>
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>
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
<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
<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?
<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>
"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?
<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?
<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
<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
<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