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]
<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
<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
<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