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
apritzel has quit [Ping timeout: 480 seconds]
vagrantc has quit [Quit: leaving]
moteen has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
rajkosto has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
moteen has joined #linux-sunxi
bauen1 has joined #linux-sunxi
aggi_ has joined #linux-sunxi
aggi has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
cnxsoft has quit []
cnxsoft has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
cnxsoft has quit [Ping timeout: 480 seconds]
evgeny_boger has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
bauen1_ has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
bauen1_ has quit [Ping timeout: 480 seconds]
cnxsoft has joined #linux-sunxi
cnxsoft has quit []
cnxsoft has joined #linux-sunxi
apritzel has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 480 seconds]
hramrach has joined #linux-sunxi
* hramrach researching options for entering FEL from u-boot
<hramrach> apritzel
moteen has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
<apritzel> hramrach: ah, hi
<apritzel> hramrach: so what SoC is this about?
<hramrach> I think Orange Pi Zero has H2 or H3
<hramrach> but I am more interested in the general design and if this can be samely generalized across SoC vendors
<hramrach> yes, H2
<hramrach> but if the example code is for other chip maybe I can find a board with another chip as well
<hramrach> especially if it's an old one
aggi_ has quit []
aggi has joined #linux-sunxi
moteen has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
<apritzel> hramrach: as I mentioned in the Github issue, it's tricky, and each SoC generation requires a different trick
<apritzel> hramrach: for instance on the H3 (older 32-bit SoCs) you might get somewhere with just "go 0xffff0020"
<apritzel> the clean solution would be to bring the system into a clean state before, so resetting the clocks and devices, as much as possible
<apritzel> but since U-Boot runs from DRAM, this is limited. One could put some code into SRAM, and then clean up from there
rajkosto has quit [Read error: Connection reset by peer]
hentai has quit [Remote host closed the connection]
hentai has joined #linux-sunxi
<hramrach> building a peice of code to run in sram and reset the peripherials is feasible but sounds quite complex
libv_ is now known as libv
<hramrach> I hoped to find an example of what was suggested in the github issue: write into a register that's preserver over reset, and check it in SPL on next boot
<apritzel> hramrach: I think this "preserved over reset" is the problem
<apritzel> hramrach: there are some spare registers in the RTC, but I don't remember from the top of my head if the H3 watchdog reset clears them as well
<apritzel> hramrach: you can try it: write something to 0x1f00100 (there should be 8 32-bit registers, according to the manual), then reset the board from the U-Boot prompt, and check whether the values survived
<hramrach> yes, that's why havinga reference implementation would simplify things a lot
<apritzel> I am not sure an Allwinner reference implementation is really useful, they tend to solve things the hacky way
<hramrach> but it would show you the correct register
<hramrach> if that's what they use, anyway. I did not find an u-boot source that implements the efex command
cnxsoft has quit []
evgeny_boger has quit [Ping timeout: 480 seconds]
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
aggi_ has joined #linux-sunxi
aggi_ has quit []
aggi has quit [Ping timeout: 480 seconds]
aggi has joined #linux-sunxi
<hramrach> apritzel: seems to work https://paste.opensuse.org/67450497
<apritzel> hramrach: that's great, thanks for testing!
<hramrach> Still it would be nice to know what register is used by downstream if any
<apritzel> care to take the next step, and prototype a "felreset" command (I don't think we should name it "efex")
<apritzel> hramrach: do you have a binary/installed U-Boot version implementing that? Then we could reverse engineer that
<apritzel> and keep in mind that this is only one way of doing a FEL reset, since it relies on matching SPL code
<hramrach> no, I only read that downstream u-boot implements efex but I never used it
<apritzel> and it's not a clean FEL entry, since the BROM reads some other boot source before that (but that is the same with that "magic" SD card)
<hramrach> heh, SPL code. Never even looked at it
<hramrach> but it should not be too difficult to patch in one register test
<apritzel> yes, indeed
<apritzel> arch/arm/mach-sunxi/board.c:init_board_f() is probably still early enough to go back to FEL (for 32-bit SoCs)
<hramrach> yes, it looks like the place where low level stuff gets initialized
vagrantc has joined #linux-sunxi
hentai has quit [Quit: Leaving]
<apritzel> well, that's the earliest platform hook in C, I think. We could do it much earlier, in assembly, though, but there is probably no need
<hramrach> hm, there is no driver for this timer on sun8i, only sun7i
<apritzel> hramrach: timer? you mean the RTC?
<hramrach> yes, the offset is defined in DT for sun7i but not sun8i
<apritzel> hramrach: I'd consider this some platform specific hack, so you just have a custom U-Boot command, and use SUNXI_RTC_BASE
<apritzel> or you explicitly scan the DT for the compatible string
<apritzel> there should be no "driver" involved
<hramrach> which does not seem defined for sun8i
moteen has joined #linux-sunxi
<hramrach> there is assumption that watchdog and rtc is one block, and it's stuffed into one structure but it really isn't, and it's totally wrong for sun8i https://paste.opensuse.org/48864793
<hramrach> to make this upstreamable the u-boot timer code needs some restructuring
<apritzel> no, I am afraid you took a wrong turn somewhere ;-)
<hramrach> sunxi_timer_reg defines what's supposed to be at SUNXI_RTC_BASE
<hramrach> yes, I do not need to use the structure, and the defines, and I don't need to take anything from the existing timer headers for a PoC
<hramrach> but it definitely is broken
evgeny_boger has joined #linux-sunxi
<apritzel> yes, this is a decade old code, but nothing worth to touch
<apritzel> I don't even know if we need that
<apritzel> since we have the arch timer (at least on anything sun7i and later)
<apritzel> hramrach: so in a first version I would just use SUNXI_RTC_BASE, and add 0x100 ;-)
<apritzel> in a more advanced version use fdt_node_offset_by_compatible() or of_find_compatible_node(NULL, NULL, ...
<apritzel> or you extend drivers/clk/sunxi/clk_sun6i_rtc.c
bauen1 has joined #linux-sunxi
<hramrach> PoC https://github.com/hramrach/u-boot/tree/v2022.07-rc5 (it at least builds)
<apritzel> hramrach: probably don't even need to do that, you can just search for a DM device with that name, and then use devfdt_get_addr()
<apritzel> hramrach: for the actual RTC register to use: you should have a Kconfig symbol, that also would allow to enable/disable that feature, and you could guard the code by that symbol
<hramrach> that's problematic because 0 is valid register
<apritzel> but -1 certainly isn't
<smaeul> btw there is precedent for the register/value used to trigger switching to FEL: https://megous.com/git/p-boot/tree/src/start32.c
moteen has quit [Remote host closed the connection]
diego71_ has joined #linux-sunxi
<hramrach> that uses GPR1 for some reason
moteen has joined #linux-sunxi
<hramrach> hm, managed to get the built image to the bardand it shows in FEL mode
moteen has quit [Ping timeout: 480 seconds]
<hramrach> WTF is this? sun4i_spi spi@1c68000: Invalid chip select 0:0 (err=-19)
<hramrach> it probed the flash once but most of the time it gives this error
<hramrach> and because Linux upstream is obtuse the flash is not in the DT so it cannot be accessed from Linux either
<hramrach> whatever, I can access it from FEL now
<apritzel> hramrach: just use $fdtcontroladdr. We synced the DTs from Linux v5.18 lately
<apritzel> hramrach: or even better: send a DT patch to Linux ;-)
<apritzel> hramrach: also there are some SPI patches in sunxi/next, plus MoeIcenowy sent one SPI patch lately
moteen has joined #linux-sunxi
<hramrach> apritzel: I did send a DT patch but because variant of Orange Pi Zero without the flashe memory exsists, and adding the flash memory into DT would cause an error to be displayed when bootin on a voard without flash memory the patch was rejected
<hramrach> neverminsd that drivers that load firmware try several firmware locations and report an error for each location that does not have the firmware
<apritzel> hramrach: well, that happens
<apritzel> smaeul: do you have any plans regarding the RTC registers? IIRC using them for something came up before?
paulk-bis has quit [Ping timeout: 480 seconds]
<hramrach> thanks for help
<hramrach> looks like the FEL option on H3 even somewhat works
<hramrach> sunxi-fel only sometimes finds the device but when it does find it it can talk to it
JohnDoe_71Rus has quit []
<apritzel> entering FEL can be tricky sometimes, depending on the board design
<gamiee> little bit offtopic question. What is the best way to make update mechanism in u-boot, where if u-boot detects .img file within USB, it will just direct DD it to eMMC?
<apritzel> if there is any voltage leaking, for instance from the UART, or via USB-OTG, I find it mostly not working
<apritzel> gamiee: a U-Boot script, I guess?
<gamiee> apritzel: hmm, for some reason, I wanted to do it hard way, implementing it within the u-boot itself ... :D
<gamiee> but I mean, are there enough of commands to do this within u-boot script?
<apritzel> gamiee: or you put some UEFI app in efi/boot/bootaa64.efi, U-Boot would pick that up automatically
<apritzel> gamiee: yes, you would be surprised
<gamiee> then I will go for u-boot script. Nice, thanks! :)
<apritzel> or you check out what include/config_distro_bootcmd.h already offers, and try to hook in there
<apritzel> gamiee: you can definitely check for certain files on various media, this is what the distro_boot already does
<gamiee> yeah, also good idea, will take look, thank you apritzel
<apritzel> gamiee: if test -e usb 0:1 update.img; then fatload usb 0:1 $kernel_addr_r update.img; mmc dev 1; mmc write $kernel_addr_r 0 <size>; fi
<apritzel> (or something like this ...)
<smaeul> apritzel: yes, my plan is to add nvmem-reboot-mode using the ABI from p-boot
<smaeul> gamiee: I think U-Boot supports EFI capsule updates
<apritzel> smaeul: yeah, capsule updates would be the best, but they are not easy to setup, last time I tried
<apritzel> smaeul: by p-boot ABI you mean to put a magic number in RTC+0x104?
<smaeul> yes
<hramrach> smaeul: that's what the patch above does
<gamiee> smaeul: I guess that EFI Capsule updates will be not much documented.. Or ?
<hramrach> there should be some generic EFI documentation for them - thet's what vendors push for PC updates
evgeny_boger has quit [Ping timeout: 480 seconds]
moteen has quit [Remote host closed the connection]
pmp-p is now known as Guest4105
Guest4105 has quit [Read error: Connection reset by peer]
pmp-p has joined #linux-sunxi
pmp-p has quit []
pmp-p has joined #linux-sunxi
ndufresne has joined #linux-sunxi
ndufresne is now known as Guest4107
obbardc9 has joined #linux-sunxi
evgeny_boger has joined #linux-sunxi
hentai has joined #linux-sunxi
Guest4107 is now known as ndufresne
evgeny_boger1 has joined #linux-sunxi
evgeny_boger has quit [Ping timeout: 480 seconds]