<swiftgeek>
ok, figured it out after re-applying old overlays, one of them was critical for board actually booting
<swiftgeek>
so I guess it's time to build new uboot and figure out how to apply overlays from uboot... I guess something grew in size and some addresses are no longer valid
<swiftgeek>
might be something to do with setexpr fdtovaddr ${fdt_addr_r} + F000
Danct12 has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
swiftgeek: what U-Boot version is this? You should have $fdtoverlay_addr_r defined automatically
<apritzel>
and then it's just a matter of "load ... $fdtoverlay_addr_r overlay.dtbo; fdt move $fdtcontroladdr $fdt_addr_r; fdt apply $fdtoverlay_addr_r"
<swiftgeek>
indeed it's already there now
Danct12 is now known as Guest530
Danct12 has joined #linux-sunxi
Guest530 has quit [Ping timeout: 480 seconds]
<swiftgeek>
I should switch to btrfs since uboot supports it now xD
Danct12 is now known as Guest531
Danct12 has joined #linux-sunxi
<swiftgeek>
but there is no crc32 in sun4i-ss so maybe not
Guest531 has quit [Ping timeout: 480 seconds]
<apritzel>
are you sure that CRC32 is a bottleneck?
<apritzel>
and the 64-bit cores have an instruction anyway, not sure that the crypto device is really beneficial there
Danct12 is now known as Guest533
Danct12 has joined #linux-sunxi
<swiftgeek>
A13 ARMv7 here ;D
Hypfer is now known as Guest534
Hypfer has joined #linux-sunxi
Guest533 has quit [Ping timeout: 480 seconds]
Guest534 has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
WinDOS_6-22 has joined #linux-sunxi
warpme has quit []
Danct12 has quit [Ping timeout: 480 seconds]
PizDOS_6-22 has quit [Ping timeout: 480 seconds]
Danct12 has joined #linux-sunxi
apritzel has joined #linux-sunxi
Danct12 is now known as Guest538
Danct12 has joined #linux-sunxi
<apritzel>
btrfs on an A13? are you sure that's a good idea?
Guest538 has quit [Ping timeout: 480 seconds]
<swiftgeek>
well seeing lack of crc32 I don't think so
warpme has joined #linux-sunxi
<apritzel>
I am more concerned about BTRF's memory consumption and overall need for resources. I am not sure that an ancient checksum algorithm is a problem for even a decade old CPU core
<apritzel>
swiftgeek: or do you have numbers that show that's a problem?
<swiftgeek>
oh if memory consumption is a problem then that will be easier to test
Danct12 has quit [Remote host closed the connection]
<apritzel>
I remember some saying from the old days (>10 years ago) that you better have a spare Gigabyte of RAM when you want to run btrfs in anger
<swiftgeek>
> No FDT memory address configured
<swiftgeek>
fdtcontroladdr and fdt_addr_r are set (and fdtoverlay_addr_r)
junari_ has joined #linux-sunxi
<swiftgeek>
it throws that error on `fdt move $fdtcontroladdr $fdt_addr_r`
junari__ has quit [Ping timeout: 480 seconds]
<swiftgeek>
noticed "fdt addr ${fdt_addr_r}; fdt resize" somewhere but with that I get "failed on fdt_overlay_apply(): FDT_ERR_NOSPACE"
Danct12 has joined #linux-sunxi
<swiftgeek>
with fdt resize 8192, I get "libfdt fdt_check_header(): FDT_ERR_BADMAGIC"
WinDOS_6-22 has quit [Remote host closed the connection]
PizDOS_6-22 has joined #linux-sunxi
<apritzel>
swiftgeek: do you have the latest U-Boot? There was a fix to "fdt move" a few weeks ago
<swiftgeek>
it's years old
<apritzel>
please don't do that ;-)
<apritzel>
so then it's: "fdt addr $fdtcontroladdr; fdt move $fdtcontroladdr $fdt_addr_r; fdt apply ..."
PizDOS_6-22 has quit [Read error: Connection reset by peer]
<apritzel>
but if you run an ancient U-Boot, you probably don't want to use the embedded DTB anyway
PizDOS_6-22 has joined #linux-sunxi
<apritzel>
so if you do it the old way, you probably load a DTB from somewhere, to $fdt_addr_r. Then it should be "fdt addr $fdt_addr_r; fdt resize; fdt apply ..."
<apritzel>
but you should seriously consider updating U-Boot, I think there were some fixes in the FDT overlay code meanwhile
<swiftgeek>
yeah nothing is working, I guess I need to downgrade kernel again
<swiftgeek>
though maybe building uboot and loading over fel would be faster
WinDOS_6-22 has joined #linux-sunxi
Danct12 is now known as Guest541
Danct12 has joined #linux-sunxi
<apritzel>
definitely. And you should more look forward than downgrading ;-)
Guest541 has quit [Ping timeout: 480 seconds]
PizDOS_6-22 has quit [Ping timeout: 480 seconds]
warpme has quit []
<swiftgeek>
"go 0xffff0020" isn't working for me, huh
WinDOS_6-22 has quit [Read error: Connection reset by peer]
PizDOS_6-22 has joined #linux-sunxi
<swiftgeek>
so entering fel might be not feasible heh
warpme has joined #linux-sunxi
<swiftgeek>
yeah it's hopeless
<swiftgeek>
"UBOOT" pin should enter FEL right?
<swiftgeek>
welp doesn't do anything any different
<swiftgeek>
apritzel: no difference with newer uboot
PizDOS_6-22 has quit [Remote host closed the connection]
PizDOS_6-22 has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
Danct12 has quit [Quit: WeeChat 3.8]
koty0f has joined #linux-sunxi
JohnDoe_71Rus has quit []
swiftgeek is now known as swiftgeek_
apritzel_ has joined #linux-sunxi
apritzel has joined #linux-sunxi
swiftgeek has joined #linux-sunxi
<apritzel>
swiftgeek: you can always enter FEL by writing fel-sdboot.sunxi (from sunxi-tools) to an SD card
<swiftgeek>
stock nand bootloader is somehow able to pull it off maybe, so maybe I should dump uboot from there and see where it jumps
<swiftgeek>
or maybe the way with go is broken
bauen1_ has joined #linux-sunxi
<apritzel>
using "go ..." is a bit of a hack, it relies on the CPU and some peripherals to be in certain states
<swiftgeek>
then it would be great to have dedicated command for it
<apritzel>
yes, patches welcome ;-) It has been tried, but not really in anger, and it's not easy to pull it off in a general way
bauen1 has quit [Ping timeout: 480 seconds]
<swiftgeek>
if state is too hard to achieve, maybe some cookie in some scratch register would do, but then it wouldn't be self contained to a single command
<swiftgeek>
(assuming reset state is closest the correct)
friendlyguy has quit []
<koty0f>
Hello. I'm trying to use configfs usb ethernet gadget on A64. I followed the wiki https://linux-sunxi.org/USB_Gadget/Ethernet. I have now kernel compiled with CONFIG_USB_MUSB_GADGET=y and dr_mode se to peripheral in dtb. I am at the point where I can create the gadget and the usb0 interface is in `ip a` list. But when I connect the board to PC it does not connect, no logs, nothing as well as on the PC. I tested that PC does correctly detect my
<koty0f>
android phone. I just noticed weird thing. Even when USB0 should work in peripheral mode, it still detects USB thub drive, when I plug it in. No matter when I use OTG cable or custom withou ID pin pulled to GND. The phy driver sais phy-1c19400.phy.1: Changing dr_mode to 1 (USB_DR_MODE_HOST). Does anybody have an idea how to fix that?
swiftgeek_ has quit [Quit: WeeChat 3.8]
<swiftgeek>
at the very least I don't need full install for testing fdt issue, just uboot, dt and overlays
<apritzel>
swiftgeek: anyway, it should be doable to enter FEL, in one or the other way, the SD card method is typically one of the more reliable ways
<swiftgeek>
would prefer least disruptive :D
<apritzel>
swiftgeek: keep trying. I have seen FEL not being entered after a reboot due to leaking voltage from UARTs and such. Try to reset as cleanly as you can (pull the plug, for instance)
<swiftgeek>
I have battery on a connector here, so that wasn't a problem :D
<apritzel>
koty0f: what board is this? And it does connect USB0 to a micro-USB socket, I assume?
<swiftgeek>
anyway whatever is on nand has combination of toggling pwrbtn with holding vol- so that works semi-reliably
<apritzel>
swiftgeek: sometimes the vendor firmware offers some OTG protocol, but that's different from FEL in the BROM
<apritzel>
koty0f: I think I tried OTG a few months ago, but not sure that was on an A64. Are you using some recent mainline kernel?
<apritzel>
swiftgeek: I see, this is then making sure that the CPU and the peripherals are in a BROM compatible state
<koty0f>
apritzel: Its custom board (driving 3d printer). It is almost the same as Lime A54 from Olimex. Yes. USB0 is connected to the micro USB connector. I'm using mainline kernel 5.16.11.
<apritzel>
swiftgeek: for instance the BROM most likely relies on the MMU being off
<apritzel>
koty0f: I think there were some OTG fixes after that, any chance you can try a later kernel? Something 6.x should be good enough
junari__ has joined #linux-sunxi
<koty0f>
apritzel: it would take a while since I have some patches on top of it (not regarding the usb). Are all the drivers nessecary for OTG mentioned on the wiki page? I might ovelooked something basic.
<apritzel>
if you could echo into configfs file, the drivers should be loaded and working
junari_ has quit [Ping timeout: 480 seconds]
<swiftgeek>
also, at least it "boots" with newer kernel (with axp20x_adc blacklisted) with unmodified DT, so that narrows down issue to fdt commands/memory
<swiftgeek>
ah but uboot doesn't use it that dt in any way, it just places it...
<swiftgeek>
still sorta proves it's not corrupted
<swiftgeek>
> Make sure you have enough space to grow the base tree without overlapping anything.
<swiftgeek>
maybe sun5i-a13-q8-tablet.dtb is big xd
JohnDoe_71Rus has joined #linux-sunxi
<apritzel>
swiftgeek: if you use the default load addresses, you should have enough space
apritzel_ has quit [Ping timeout: 480 seconds]
junari__ has quit [Remote host closed the connection]
junari__ has joined #linux-sunxi
<koty0f>
apritzel: well the system suprisingly booted up with unmodified 6.1.13, but still no luck. Same behaviour. ub0 interface created and visible in the system, but nothing after plugging it into the PC. lsusb on the PC also reports no new device.
<apritzel>
koty0f: have you tried: dr_mode = "otg"; and then wiring up the ID pin GPIO, as in the olinuxino.dts or the BananaPi M64?
<koty0f>
Yes. I used USB also in otg mode and I added internal pull up to ID pin in dtb usb0_id_det-gpios = <&pio 7 9 (GPIO_ACTIVE_HIGH | GPIO_PULL_UP)>; I hooked up the logical analyzer to ID pin, and verified, its HIGH when not pulled low by the OTG cable.
<koty0f>
The usb just behaves as the host no matter what. Thats probably the cause, why A64 does not start communication with PC.
warpme has quit []
<apritzel>
I remember some recent issues with peripheral mode on normally host configured ports, but thought that dr_mode=otg would be fine
warpme has joined #linux-sunxi
<koty0f>
Isn't VBUS supposed to be turned off when ID pin is high and nothing is connected? I imagine VBUSDET pin is used to detect that there is another host in the bus and actually start the USB in device mode.
junari__ has quit [Ping timeout: 480 seconds]
<koty0f>
The thing is, that VBUS is powered all the time in my case. So if I connect the second host, I thing there are two 5V supplies on the VCC pin.
<apritzel>
koty0f: yeah, that's not nice, but not uncommon, especially on Allwinner boards. If you have a "USB-charger" AXP, it should work according to the USB spec, but some vendor mess that up
<swiftgeek>
but without testpoint I feel like it's not worth it
<koty0f>
apritzel: also the question is if th AXP gets even notified that it should shut the power off:)
<apritzel>
swiftgeek: so doesn't it work when you just use the NAND firmware and that key combination?
<apritzel>
koty0f: it should: when the ID pin is pulled low, it should trigger a GPIO interrupt, that should let the USB PHY driver turn off the power supply specified via usb0_vbus-supply
<swiftgeek>
oh that works, just annoyed that it appears to be not hooked up like on reference schematics
<swiftgeek>
because there are indeed two resistors on Vol-
<swiftgeek>
one 0Ω and one something higher
<swiftgeek>
but 0Ω doesn't go to uboot xD
<apritzel>
it's for the KEYADC, I guess? And then they check it in their firmware, and do it early enough that just branching back to the BROM still works
<swiftgeek>
0Ω is for FEL, high Ω is for KEYADC
<apritzel>
well, I guess FEL mode is not the most commonly requested feature by the casual tablet user ;-)
<swiftgeek>
but more like, deleted trace coz it didn't fit on 4L board
<swiftgeek>
but left 0Ω
<swiftgeek>
xD
<apritzel>
I stopped wondering about those things when it comes to Allwinner boards. Seems like some Allwinner traits rub off to the board vendors ;-)
<swiftgeek>
I can understand when that happens, but leaving testpoints behind some wire can reliably stitch it when needed is a good practice
<swiftgeek>
nah
<swiftgeek>
allwinner reference is usually fine
<swiftgeek>
but this is equivalent of monkey patching packages
<swiftgeek>
and basically ignores DRC entirely
<apritzel>
I don't know about the ref boards, but I can clearly see that AW cuts corners whenever they can in their SoC designs
<swiftgeek>
I honestly don't mind that, but just exposing documentation directly would be nice
<swiftgeek>
ip-xact for every soc should be sitting somewhere, going from that to SystemRDL wouldn't be too much of an issue
<swiftgeek>
*every cortex soc lol
<swiftgeek>
i forgot allwinner is here since far longer time
<swiftgeek>
though H6 corner cutting was more like cutting time in design process -.-
<swiftgeek>
that phy is massive
<swiftgeek>
there is no excuse for it being plugged like that
warpme has quit []
warpme has joined #linux-sunxi
<swiftgeek>
lol
<swiftgeek>
new DTB is actually smaller
<swiftgeek>
(old) 24907 bytes vs 18197 (new)
warpme has quit []
hlauer has joined #linux-sunxi
diego71 has joined #linux-sunxi
warpme has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
koty0f has quit [Quit: Konversation terminated!]
apritzel_ has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
bauen1 has joined #linux-sunxi
bauen1_ has quit [Ping timeout: 480 seconds]
warpme has quit []
warpme has joined #linux-sunxi
WinDOS_6-22 has joined #linux-sunxi
WinDOS_6-22 has quit [Read error: Connection reset by peer]
PizDOS_6-22 has quit [Read error: Connection reset by peer]
PizDOS_6-22 has joined #linux-sunxi
WinDOS_6-22 has joined #linux-sunxi
JohnDoe_71Rus has quit []
PizDOS_6-22 has quit [Ping timeout: 480 seconds]
ftg has joined #linux-sunxi
apritzel_ has left #linux-sunxi [#linux-sunxi]
apritzel has joined #linux-sunxi
warpme has quit []
WinDOS_6-22 has quit [Read error: Connection reset by peer]