01:15 <swiftgeek> this is probably more archlinuxarm issue, but on recent kernel USB kicks in extremely late in boot, even getty starts sooner

01:15 <swiftgeek> and this is despite all usb modules being built in

01:17 <swiftgeek> getty starts in 17th second, USB host kicks in nearly a second later

01:19 <swiftgeek> (with message: ehci-platform 1c14000.usb: EHCI Host Controller )

01:46 <swiftgeek> actually blacklisted every single module and USB doesn't work anymore

01:49 <smaeul> is phy-sun4i-usb a module?

02:36 <swiftgeek> adding axp20x_adc to initrd helped

02:43 <swiftgeek> now the second hickup is having it detect partitions

02:44 <swiftgeek> and that's something I observed on RK3288 as well, partitions on USB devices would not be detected early on

02:45 <swiftgeek> but at exactly the same time, it's detected just fine on mmcblk0

02:47 <swiftgeek> maybe i should just load every single module used into initcpio and see what happens

02:56 <swiftgeek> that helped with having /dev/sda1 but it doesn't end up being detected as particular label lol

02:57 <swiftgeek> or (part)uuid

02:58 <swiftgeek> and an attempt to mount it fails too xD

03:00 <swiftgeek> works after hotplug though lol

03:18 <swiftgeek> looks like hotplug works after > [ 33.772875] vcc3v0: disabling

03:20 <swiftgeek> yeah the entire usb path is extremely strange on both rk3288 and at least A20 xD

03:21 <swiftgeek> i guess i will find last kernel that works, take that config and just rebuild for newest kernel

03:22 <swiftgeek> but the strangest part for me is that it works just fine after it boots from say, mmcblk0 xD

03:27 <swiftgeek> right, and now any USB storage device plugged in while booting will cause some kind of glitchy behaviour xD

03:52 <swiftgeek> k luckily 5.16.x works fine, so that shouldn't be a massive gap to 5.19

04:00 <swiftgeek> nope just lucked out on few boots, damn xD

10:33 <bauen1> hm, so I can't easily change my nick from bauen1_ to bauen1 when on this channel, since unregistered users are muted I think ? Is there a better way around this than to part, nick, join again ?

10:42 <bauen1> or do people just register their alternative names to nickserv too ?

11:34 <hramrach> bauen1: there is some way to register alts too

11:35 <hramrach> link the registration to one nick, even

15:48 <swiftgeek> I guess I will make some AXP209 and others sanity check in uboot script, so I know for sure whether AXP has a faulty state, or something is wrong with linux

15:48 <swiftgeek> sucks that AXP's I2C isn't on any header for easier troubleshooting

21:28 <bauen1> so I'm still trying to get the external tpm2 to work, this time on my pine64-lts and with linux, as u-boot still refuses to talk to it, but debian doesn't actually build the sun6i spi drivers ...

21:31 <swiftgeek> I guess I can use this https://stackoverflow.com/questions/45533708/need-to-detect-i2c-value-in-uboot-as-a-script to detect AXP209 in uboot script using 03h register

21:32 <swiftgeek> Is it possible to set a blinky led in uboot?

21:32 <swiftgeek> for "attention required"

21:32 <bauen1> swiftgeek: if it's connected to a gpio pin, you can always use the `gpio` command to do that

21:32 <swiftgeek> welp

21:33 <swiftgeek> i guess solid will do too for now

21:34 <swiftgeek> or maybe I can have infinity loop in script waiting for input, printing something with carriage return to not mess up the logs too much

21:46 <swiftgeek> huh compared two uboot versions by accident and on latest PMIC is listed but attempt to read that address fails

21:48 <swiftgeek> ah it works with 03.1

21:49 <swiftgeek> then not sure what .0 .1 .2 are

21:51 <swiftgeek> https://stackoverflow.com/questions/48075876/i2c-md-command-syntax i guess i will need to look up more i2c device datasheet examples

22:01 <swiftgeek> oh

22:01 <swiftgeek> I guess uboot's echo doesn't support escape characters

22:06 <swiftgeek> is it because puts takes single character at once?

22:10 <swiftgeek> or i don't get how echo works there

22:15 <swiftgeek> echo -n \n\n\n somehow strips all \, but puts with \n in it clearly works

22:16 <swiftgeek> maybe it will work from script and not hush shell

22:39 <bauen1> *sight*, obviously it's benefitial if the underlying SPI driver in u-boot works

22:41 <bauen1> now I'm back at the point where the receing values are shifted by one bit

22:48 <bauen1> this isn't even limited to SPI1, but seems to affect the entire sunxi-spi driver (and then probably for both the a64 and the h6), e.g. `sspi 0:0 128 9F` (SPI NOR FLASH request ID command) will return `00EF4018000000000000000000000000` for both the SBC winbond flash and the external winbond flash, but it's supposed to return 00EF4016 (6 instead of 8)

22:59 <bauen1> or it is supposed to read 4018

23:15 <bauen1> yeah, pretty sure it's supposed to be that, so that is working as expected

23:15 <bauen1> so why isn't my precious little tpm thingy doing the right thing ...

23:25 <swiftgeek> huh setexpr seems to imply i can just load memory into a variable though not sure if that's useful for binary

23:27 <swiftgeek> setexpr.w test *${kernel_addr_r}

23:27 <swiftgeek> nice :D

23:28 <swiftgeek> it's actually a hex form so i can do whatever easily

23:56 <mnemoc> wiki back online, apologies for the inconveniences