libv 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
Mangy_Dog has quit [Remote host closed the connection]
apritzel has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
hlauer has joined #linux-sunxi
cmeerw has joined #linux-sunxi
cmeerw has quit [Ping timeout: 480 seconds]
sunshavi has quit [Remote host closed the connection]
tnovotny has joined #linux-sunxi
apritzel has joined #linux-sunxi
prefixcactus has joined #linux-sunxi
warpme_ has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
choozy has joined #linux-sunxi
jernej_ has joined #linux-sunxi
jernej has quit [Read error: Connection reset by peer]
choozy has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
sunshavi has joined #linux-sunxi
ftg has joined #linux-sunxi
sunshavi has quit [Remote host closed the connection]
milek7 has joined #linux-sunxi
cmeerw has joined #linux-sunxi
<milek7> roughly how much time it takes on H6 with LPDDR3 to start booting kernel?
<milek7> I'm looking for some replacement for raspberry pi as their firmware taking 5+ seconds to start booting is just too long...
sunshavi has joined #linux-sunxi
vagrantc has joined #linux-sunxi
<apritzel> milek7: depends on how many sacrifices you are willing to make, you can hack your firmware to boot very quickly
<apritzel> milek7: but out of the box we have for instance a ~1sec timeout per USB controller, so it spends ~4secs already there
jernej_ is now known as jernej
choozy has joined #linux-sunxi
tnovotny has quit [Remote host closed the connection]
tnovotny has joined #linux-sunxi
<milek7> I guess with minimal config it should be just dram init + whatever it takes to load kernel/initramfs from sd card, right?
<jernej> that's called falcon mode, but I'm not sure it's supported for all Allwinner SoCs
<jernej> however, you can still trim down config considerably and it's pretty fast (no figures at hand)
hlauer has quit [Ping timeout: 480 seconds]
<milek7> any ballbark number for SPL? 1s, more?
<apritzel> milek7: I think the SPL itself is much quicker than this, and even Trusted Firmware doesn't add that much
<apritzel> but you still have the actual loading time, in the H6 we get about 11MB/s from MMC
<mripard> milek7: the SPL itself takes around 100ms last time I checked (on an A33)
<apritzel> at least with the current code
<mripard> plus the time to load the kernel
<mripard> booting from the eMMC is kind of a bummer though for boot time, since the BootRom takes a bit more than 1s to even start looking at it
<apritzel> indeed, it's noticeable, not sure it's 1s, though
<mripard> apritzel: ATF takes around 300-400ms total on the A64
<mripard> apritzel: it's easy enough to measure, the bootrom outputs a character on the UART at powerup
<apritzel> mripard: thanks, didn't measure that, but it's "quick" - compared to the 3 minutes of my Cavium ThunderX2 boot ;-)
<apritzel> mripard: so did you silence the output of every component, and just give one character to get a timestamp?
<mripard> no, not really
<mripard> the output of the SPL and ATF is fairly low, so I kept it
<mripard> and then you just measure the difference between that first character and whatever log comes next
<milek7> thanks, i'll buy some board then
noocsharp has joined #linux-sunxi
tnovotny has quit []
<apritzel> mripard: so I reordered the H616 patches, so that the basic .dts ones come first, and the RTC and USB on top
<noocsharp> Hi, I'm trying to build crust meta and install it on an sd card for the pinephone. u-boot says "MMC Device 0 not found". I'm not sure how to interpret this. I know the card works, and the "eGON" magic is in the same place as a functional card. What else could be causing this?
<apritzel> noocsharp: which version of U-Boot is this using?
<noocsharp> i'm using crust meta repo, so it's the crust fork at https://github.com/crust-firmware/u-boot
<apritzel> which looks like 2021.07-rc1, which changed the MMC numbering. fixed about two weeks ago: https://source.denx.de/u-boot/u-boot/-/commit/6785434709b74
<noocsharp> awesome, thanks. i'll see if this fixes it
<noocsharp> it works :)
<apritzel> what's the point of having those recipes with fixed repo HEADs if they don't work?
<apritzel> they could as well just use "master", and find new bugs on the way
prefixcactus has quit [Ping timeout: 480 seconds]
<noocsharp> i think they just haven't merged upstream in 2 months, the meta repo pulls from the master of their fork
<noocsharp> but yeah, it might make more sense to use upstream u-boot
<MoeIcenowy> weird
<MoeIcenowy> when no -A is not specified
<MoeIcenowy> the arch value in mkimage is IH_ARCH_PPC
<MoeIcenowy> well is this dated back to when U-Boot is named PPCBoot?
hauke has joined #linux-sunxi
<hauke> Is ethernet working on the D1 with these patches already ? https://github.com/smaeul/linux/commits/riscv/d1-wip
<hauke> is the D1 similar to the other allwinner SoCs just with a RISC-V core instead of a ARM?
<hauke> I would like to add OpenWrt support for this D1 dev board and want to use upstream + some patches, but not the allwinner code
<hauke> I do not want to touch the wifi ;-)
<apritzel> hauke: yes, in fact it has two (disabled?) A7 cores on the die, and there is a sibling chip which uses exactly those two cores
<hauke> apritzel: lol, didn't know there are A7 cores in the chip
<hauke> Are the peripherals just an extension of some previous generation?
<apritzel> hauke: but as usual Allwinner changes random bits here and there, as they do with so every new "generation"
<MoeIcenowy> apritzel: hahahaha
<MoeIcenowy> what I am most afraid of now is DRAM controller
<apritzel> yes, the devices are very similar, yet still many of them require code changes to work
<hauke> apritzel: ok thanks
<MoeIcenowy> sent RFC patches to give mkimage -T sunxi_egon RV support
<apritzel> MoeIcenowy: aparts from some rebasing artefacts (s/Aflags/Aflag/) looks alrightt
<apritzel> thanks for keeping compatibility!
<apritzel> MoeIcenowy: and I see now what you meant with the weird immediate encoding ;-)
<MoeIcenowy> apritzel: I think there's rumors saying that this immediate encoding is friendly to silicon implementation
<gamiee> immediate encoding? :o
<MoeIcenowy> gamiee: we are discussing RISC-V
<vagrantc> so curious to see #linux-sunxi move on to supporting RISC-V
<apritzel> vagrantc: move? I hope it's copy
<vagrantc> hah
<vagrantc> it's just the community has been so associated in my mind with ARM
<MoeIcenowy> sunxi is so associated with ARM that my patch must consider ARM as a default fallback value
<MoeIcenowy> oops D1 BSP fails to build on my host with GCC 10
<MoeIcenowy> my uart0-helloworld-sdboot port for D1 suddenly stopped working...
<apritzel> MoeIcenowy: could that be problem due to the late (or early?) time over there at you? :-D
<MoeIcenowy> oooops
<MoeIcenowy> it's power issue
<MoeIcenowy> my PC Vbus seems to be not powerful enough
<apritzel> vagrantc: challenge of the day: find a "deflector" instruction encoding that is a branch in ARM32 and some NOP-like instruction in RISC-V (or the other way around)
<apritzel> vagrantc: so that you can have a single image that boots on Allwinner ARM and RISC-V chips
<vagrantc> hah!
<vagrantc> at least with the sifive boards they use some special partition header ... so it might work at arbitrary offsets
<apritzel> shouldn't be too hard, given that RV has the opcode in the low bits, and ARM in the high bits
<MoeIcenowy> I think Si5 boards can parse GPT
<apritzel> but AW chose the same BootROM payload format (magic and checksum)
<MoeIcenowy> which is just powerful
<apritzel> and actually we need both of them to be some kind of branch instructions
<apritzel> MoeIcenowy: sure, that's how you would design
<apritzel> but this is Allwinner, go figure!
<vagrantc> the love/hate relationship of sunxi and allwinner
<MoeIcenowy> apritzel: well I think parsing GPT is overkill
<apritzel> but elegant and future proof
<apritzel> RPi parses MBR only, IIRC
<apritzel> and just reading GPT is straight forward
<vagrantc> i vaguely recall allwinner offsets conflicting with default GPT partition tables
<MoeIcenowy> vagrantc: well to prevent this they provided a new possible offset for BL
<vagrantc> an excercise in going crazy with offsets
<apritzel> vagrantc: the default 8K is within the normal GPT allocation, although you can construct a GPT with less entries
<apritzel> or just use the 128KB offset, and be well behind the GPT
<vagrantc> for both allwinner and rockchip i'm starting to wonder if i shouldn't default to some non-default offsets :)
<jernej> MoeIcenowy: what kind of problems do you have with DRAM? is it similar to some DW controller we already know?
<MoeIcenowy> jernej: I cannot RE the file now
<MoeIcenowy> it uses T-Head extension
<MoeIcenowy> BTW, bad news, jumping to 0x20 to enter FEL seems to be not working on D1
<jernej> MoeIcenowy: are those instructions used all over the place or just here and there?
<MoeIcenowy> all over the place
<MoeIcenowy> the compiler seems to be made to utilize it
<jernej> it seems that AW makes DRAM RE process more challenging with every new SoC :)
jernej_ has joined #linux-sunxi
jernej has quit [Read error: Connection reset by peer]
<apritzel> MoeIcenowy: what do those custom instructions do?
jernej_ is now known as jernej
<MoeIcenowy> apritzel: various
BorgCuba has joined #linux-sunxi
<BorgCuba> so this is the official channel but freenode went to libera I read?
<MoeIcenowy> BorgCuba: freenode is still freenode, it's just no the original freenode
<MoeIcenowy> some people from freenode created libera
<MoeIcenowy> but it's the channel users' choice to switch to libera, oftc, etc
<BorgCuba> sure
<BorgCuba> how is the h616 port progressing?
<cyrozap> MoeIcenowy: When you say "T-Head extension", what do you mean, exactly? Does T-Head have a custom RISC-V extension? If it's documented somewhere, support could be added to Ghidra to disassemble/decompile it.
<BorgCuba> I will look it up on the site
<MoeIcenowy> cyrozap: it's documented, in Chinese
<apritzel> BorgCuba: I posted v7 on Tuesday, but it will most likely miss 5.14
<apritzel> BorgCuba: there might be a chance to get minimal support into (MMC, and GBit Ethernet, but no USB, no RTC), but I am not sure it's worth it
<apritzel> (and it's not my decision anyway)
<cyrozap> MoeIcenowy: Oh, heh. Well, if you have a link to it, I might try adding the processor variant to Ghidra.
<BorgCuba> apritzel, I tried your kernel last year in december (5.10) on my h313 device
<apritzel> BorgCuba: X96Q?
<BorgCuba> Yes, I think so
<BorgCuba> the dirty cheap one ;-)
<apritzel> that's the one ;-)
<apritzel> in eBay search for "Allwinner", sort by price ;-)
<BorgCuba> I think you or sb else mentioned that panfrost might work as well?
<apritzel> reportedly, somewhat
<apritzel> but you definitely need kernel patches for the display engine and HDMI
<BorgCuba> I see, so you have not tested it I guess
<apritzel> unless you are happy with pure to-memory 3D rendering, which is a bit like looking at the Matrix in its encoded way ;-)
<apritzel> I briefly tried some patches from jernej, but just got a black screen, although this is supposed to work (other people seem to be able to use it)
<BorgCuba> indeed, I think it was jernej. I have to consult the logs
<apritzel> but I haven't tried hard, and I prefer serial anyway ;-)
<BorgCuba> oh, thank you
<smaeul> hauke: ethernet is not working yet. The driver loads but I don't see any packets going across
<apritzel> jernej: does the 100 MBit PHY work in Linux, if you set it up in U-Boot and leave the clocks running?
<smaeul> MoeIcenowy: include this at the top of the DRAM source and you can compile it with a mainline toolchain: https://tpaste.us/PKk1
<hauke> smaeul: ok, when I get a board and it is not yet fixed I can also have a look at it
<jernej> apritzel: yes
<smaeul> cyrozap: https://occ.t-head.cn/vendor/cpu/download?id=3817197695983423488 but it's behind a login-wall
<apritzel> vagrantc: 0x0a00006f is "j +0xa0" in RISC-V, and "beq +0x1c4" in ARMv7
* vagrantc blindly concurs
<apritzel> not sure what the condition flags are when the BROM launches the eGON, but there is some flexibility there
<ats> I was just working the other way round - 0xea000067 is "b 0x67" on ARM32 and "jalr zero, 0xea0(zero)" on RV32
<apritzel> ats: that is probably even better, I just focused on jal in this first try
<apritzel> ats: does "0xea0(zero)" mean branch to x0(=0) + 0xea0? So it doesn't dereference x0?
<ats> If I'm understanding the manual correctly, yes
<ats> Oh - but it sign-extends the constant - so I don't think mine will work
<apritzel> ats: I was just wondering ...
<apritzel> the sign-extension in "jal" prevents the "always" encoding in ARM
<apritzel> ats: "content of x0 + 0xea0" is my reading of the manual as well
<apritzel> MoeIcenowy: something like this ^^^^ can be used for the truly versatile uart0-helloworld-sdboot ;-)
<apritzel> ats: nice job, anyway!
cmeerw has quit [Ping timeout: 480 seconds]
<swiftgeek> did somebody fetch that https://occ.t-head.cn/vendor/cpu/download?id=3817197695983423488 ? It appears to require +86 phone number :<
choozy has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
<apritzel> That free and open ISA is really having a good start ;-)
<swiftgeek> considering how little is available in that ecosystem, certainly
<swiftgeek> (as in IP cores and support for integration)
<apritzel> well, but this is about instruction encoding only
<swiftgeek> which cannot really do anything on its own, though at least trivial implementations are feasible for a single person
<swiftgeek> huh
<swiftgeek> so synopsys is not avoiding the topic :D
<swiftgeek> https://crvf2019.github.io/pdf/31.pdf (AIoT, that's a new one to me :D)
<swiftgeek> but i'm slightly worried that synopsys won't ever provide a core in a stupid decision to promote their previous purchase of ARC
jernej has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
jernej has joined #linux-sunxi
jernej has quit []
jernej has joined #linux-sunxi
BorgCuba has quit [Quit: Leaving]
jernej has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
jernej has joined #linux-sunxi
warpme_ has quit [Quit: Connection closed for inactivity]
jernej has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
jernej has joined #linux-sunxi