rellla changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi - *only registered users can talk*
sunshavi has quit [Remote host closed the connection]
sunshavi has joined #linux-sunxi
dev1990 has quit [Quit: Konversation terminated!]
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
kaspter has quit [Ping timeout: 264 seconds]
kaspter has joined #linux-sunxi
ChriChri_ has joined #linux-sunxi
camus1 has joined #linux-sunxi
ChriChri has quit [Ping timeout: 260 seconds]
ChriChri_ is now known as ChriChri
kaspter has quit [Ping timeout: 260 seconds]
camus1 is now known as kaspter
PPAChao has joined #linux-sunxi
PPA has quit [Ping timeout: 268 seconds]
psydread has left #linux-sunxi [#linux-sunxi]
kaspter has quit [Read error: Connection reset by peer]
kaspter has joined #linux-sunxi
psydread has joined #linux-sunxi
psydread has left #linux-sunxi [#linux-sunxi]
camus1 has joined #linux-sunxi
kaspter has quit [Remote host closed the connection]
camus1 is now known as kaspter
sunshavi has quit [Ping timeout: 240 seconds]
Mangy_Dog has quit [Ping timeout: 260 seconds]
KotCzarny has quit [Ping timeout: 240 seconds]
jstein has quit [Ping timeout: 260 seconds]
psydread has joined #linux-sunxi
juri_ has quit [Ping timeout: 264 seconds]
camus1 has joined #linux-sunxi
kaspter has quit [Ping timeout: 260 seconds]
camus1 is now known as kaspter
gaston1980 has quit [Quit: Konversation terminated!]
sunshavi has joined #linux-sunxi
cnxsoft1 has quit [Ping timeout: 240 seconds]
cnxsoft has joined #linux-sunxi
victhor has quit [Ping timeout: 240 seconds]
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
KotCzarny has joined #linux-sunxi
faruk_ has joined #linux-sunxi
gendevbot has quit [Ping timeout: 260 seconds]
faruk has quit [Ping timeout: 260 seconds]
gendevbot has joined #linux-sunxi
lurchi_ is now known as lurchi__
KotCzarny has quit [Ping timeout: 268 seconds]
KotCzarny has joined #linux-sunxi
gediz0x539 has joined #linux-sunxi
AneoX has quit [Ping timeout: 246 seconds]
AneoX has joined #linux-sunxi
AneoX has quit [Ping timeout: 260 seconds]
psydread has left #linux-sunxi [#linux-sunxi]
AneoX has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 240 seconds]
s_frit has quit [Remote host closed the connection]
s_frit has joined #linux-sunxi
AneoX has quit [Ping timeout: 264 seconds]
AneoX has joined #linux-sunxi
reinforce has joined #linux-sunxi
daregap has joined #linux-sunxi
camus1 has joined #linux-sunxi
kaspter has quit [Ping timeout: 256 seconds]
camus1 is now known as kaspter
juri_ has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Quit: Ex-Chat]
ldevulder has joined #linux-sunxi
cmeerw has joined #linux-sunxi
userx_ has joined #linux-sunxi
camus1 has joined #linux-sunxi
kaspter has quit [Ping timeout: 256 seconds]
camus1 is now known as kaspter
damex has quit [Ping timeout: 256 seconds]
[OffCool] is now known as [powerAutism]
hlauer has joined #linux-sunxi
damex has joined #linux-sunxi
dev1990 has joined #linux-sunxi
florian_kc has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
rex_victor has quit [Read error: Connection reset by peer]
rex_victor has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 264 seconds]
kaspter has quit [Ping timeout: 272 seconds]
kaspter has joined #linux-sunxi
jernej_ has joined #linux-sunxi
jbrown has joined #linux-sunxi
jernej has quit [Ping timeout: 260 seconds]
jernej_ is now known as jernej
jbrown has quit [Ping timeout: 240 seconds]
jbrown has joined #linux-sunxi
[powerAutism] is now known as [WayOfLife]
indy has quit [Read error: No route to host]
indy has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
victhor has joined #linux-sunxi
lkcl has quit [Ping timeout: 258 seconds]
lkcl has joined #linux-sunxi
jstein has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
kaspter has quit [Ping timeout: 272 seconds]
kaspter has joined #linux-sunxi
kaspter has quit [Remote host closed the connection]
damex has quit [Read error: Connection reset by peer]
damex has joined #linux-sunxi
lurchi_ has quit [Quit: Konversation terminated!]
lurchi__ has joined #linux-sunxi
kaspter has joined #linux-sunxi
victhor has quit [Quit: Leaving]
<gediz0x539> do DRAM chips have a manufacturer/device ID as in SPI flash ICs?
<karlp> iirc the chips don't, but DIMMs in mobos do,
<karlp> or, can.
<karlp> that's it, yeha
<hlauer> the 3V line on my banana pi is dead - should come from the SY8008B-AAC on U6. Input voltages there look normal - where to get?
<gediz0x539> i did not know this. thanks. so it does not look possible to get any vendor specific data on a regular SBC because there's no EEPROM containing SPD data, I assume.
<gediz0x539> I'm looking for a way to detect different DRAM models on SPL phase and set tpr, emr parameters according to the model.
<gediz0x539> hlauer: where to get, the regulator?
<hlauer> yes, or an replacement type
<hlauer> datasheet is from 2012 and couldn't find it on standard sources reachable from germany
<gediz0x539> i got some 8009s laying around, supplied from China
<gediz0x539> and apparently it's possible to source some from a local supplier: https://ozdisan.com/Product/Detail/406692/SY8008CAAC
<gediz0x539> I can send you some of them if you want
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.1 Aria http://www.kvirc.net/]
wens has joined #linux-sunxi
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-sunxi
gaston1980 has joined #linux-sunxi
daregap has quit [Quit: daregap]
<mnemoc> q
<mnemoc> err
<mnemoc> gediz0x539: unfortunatelly detection is based on trial-and-error :-/
<mnemoc> dimm modules, as do monitors, have an standardised i2c eeprom with the details. but not for those using the ICs directly
matthias_bgg has quit [Ping timeout: 272 seconds]
<gediz0x539> mnemoc: oh, ok then. i was thinking about modifying dramc_init_helper function as a last resort. thanks a lot.
matthias_bgg has joined #linux-sunxi
apritzel_ has joined #linux-sunxi
<mnemoc> gediz0x539: usually you can do an "educated guess" and narrow down your options based on failed initialisations
<apritzel_> Hey gediz0x539, I have some working code which detects LPDDR3 vs. DDR3 on A64 and H5, so I have one SPL to boot on (presumably) all A64 and H5 boards
<apritzel_> very handy for FEL booting
<apritzel_> it works by enhancing the DRAM driver to make more runtime decisions, then trying LPDDR3 first
<apritzel_> if that fails, it will change the parameters to DDR3, and tries again
<gediz0x539> mnemoc: neat idea. i got some lima-memtester logs for two kind of devices. they fail on some specific area. maybe i can generalize using them.
lurchi__ is now known as lurchi_
<mnemoc> gediz0x539: I wouldn't call "trial and error" neat but... well... it can be lived with :p
<gediz0x539> apritzel_: wow that would be great for a unified image
<apritzel_> gediz0x539: yes, I have a prototype (unified SPL + U-Boot proper) for that one as well, for a limited set of boards
<gediz0x539> apritzel_: but how do you "enhance" the driver?
<apritzel_> changing #ifdef's into if (), for instance, and turning other compile time decisions into runtime decisions
<apritzel_> for instance I read the actual SoC ID from the SID, and derive H5 vs. A64 from that
<gediz0x539> mnemoc: i'm sure it'd be better compared to my current so called solution. SID lookup table check to fetch different params for different devices...
<apritzel_> that blows up the code quite a bit, but it works for a 32-bit SPL
<apritzel_> I was about to clean up the code and post it, but it's somewhat intrusive, so not sure it's any good for mainline U-Boot
<gediz0x539> apritzel_: actually it sounds pretty reasonable to make runtime decisions. i will use this idea :)
<gediz0x539> i'd like to see it if you post it somewhere.
<mnemoc> always prefer if (is_this()) over #ifdef, as it checks if all the code still compiles, even if #define is_this() 0
<mnemoc> dead code elimination will remove the excluded code when needed
<gediz0x539> main reason of #ifdefs over if's size optimization right? are there any other benefits?
<mnemoc> if (0) { ..... } produces the same code as #if 0 #endif when optimised
<gediz0x539> oh okay
<mnemoc> but the first 1) (test)compiles the disabled code, 2) allows you to have the option of making dynamic decisions when wanted
<mnemoc> while the second approach is just a bad habit of some people
<gediz0x539> it's some kind of tradition I guess
<mnemoc> not all traditions are good ¯\_(ツ)_/¯
<gediz0x539> agree. i'm also for dynamic decisions. reading the same codebase over and over developed some cargo cult for me.
JohnDoe_71Rus has joined #linux-sunxi
<gediz0x539> especially when you're a newbie, all the code you see in big projects like linux and u-boot seems like the one and the only solution
<apritzel_> yeah, this toolchain garbage collection is really neat, you see that when you actually make those values runtime changeable, as the code suddenly blows up
apritzel_ is now known as apritzel
<apritzel> gediz0x539: so I pushed this here: https://github.com/apritzel/u-boot/commits/sunxi-unified-WIP
<mnemoc> static inline int is_foo(void) { return 0; } kills all `if (is_foo()) { .... }` even on -O1 for me
<apritzel> as the name implies, it's a bit raw still
faruk_ has quit [Quit: Leaving]
<mnemoc> :)
<apritzel> mnemoc: yeah, I use that here: https://github.com/apritzel/u-boot/commit/ca083f7d719
<gediz0x539> apritzel: thank you so much
<gediz0x539> it actually looks in pretty good shape
reinforce has quit [Quit: Leaving.]
<mnemoc> apritzel: for mental sanity, move the #ifdef outside the function
<apritzel> yeah, there are multiple ways to do this, I was also thinking about putting the actual SOCID value into Kconfig, for instance
<mnemoc> yes, if not given, detect
<mnemoc> even if you make Kconfig actually set the CONFIG_SUNXI_SOCID automatically
<apritzel> and it's a static inline in a header file, so wherever you use sunxi_get_socid() you get this optimisation you mentioned above
<apritzel> so it should be equivalent to #ifdef CONFIG_MACH_SUNxi_yyy if only one SoC is selected (as it is today)
<mnemoc> correct, BUT, you won't notice typos unless you compile all combinations
<mnemoc> because the preprocessor will hide them from the compiler
<apritzel> sure, that's left on purpose to reward reviewers ;-)
<mnemoc> :D
gediz has joined #linux-sunxi
teteros has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 256 seconds]
kaspter has quit [Ping timeout: 240 seconds]
Shirasaka-Hazumi has quit [Quit: ZNC - https://znc.in]
kaspter has joined #linux-sunxi
<hlauer> gediz0x539,karlp: will have a look, thanks a lot!
<karlp> hlauer: it's a"standard" sot23-5 pinout iirc, you should be able to use pretty much anything you like....
<karlp> (if you're really sure it's just the reg that's blown)
huawei has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
<hlauer> pins IN,GND and EN of the SY8008B-AAC show nominal voltages - LX shows 0.33V instead of 3.3V. So it looks like
gediz has quit [Quit: Quit]
vagrantc has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.1 Aria http://www.kvirc.net/]
arete74 has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
camus1 has joined #linux-sunxi
kaspter has quit [Ping timeout: 272 seconds]
camus1 is now known as kaspter
florian_kc has quit [Quit: Leaving]
lurchi_ is now known as lurchi__
c10ud^ has joined #linux-sunxi
hexdump0815 has joined #linux-sunxi
<hexdump0815> looks like there should be some bsp style (i.e. low quality) code around soon for the h616 - better than nothing: https://www.cnx-software.com/2020/11/02/orange-pi-zero2-allwinner-h616-sbc-runs-android-10-or-linux/
JohnDoe_71Rus has joined #linux-sunxi
<apritzel> hexdump0815: do you know how close the H616 is to the A63? I have a tablet with that one, and have some foot in the door (FEL boot, UART via SD card), but I found the H6 DRAM driver not being compatible out of the box
<vagrantc> apritzel: hi! i just revisited your fosdem talk and noticed https://github.com/apritzel/simage hadn't recieved any updates ... had experimented with making a single image that boots both pinebook (a64) and pinebook-pro (rk3399) and almost had it working
<vagrantc> without any patching, just using the alternate offsets ... and u-boot seemed to load fine, but would only successfully boot linux on the pinebook, the pinebook pro would hang ... presumably some memory area was overwritten?
<apritzel> vagrantc: yeah, I should update this page ...
<apritzel> so for Rockchip you need to tweak the U-Boot proper load offset in the Kconfig, IIRC
<vagrantc> apritzel: really liked your talk :)
<apritzel> to move it out of the way
<jernej> apritzel: I'm working on H616 DRAM driver - controller is basically the same as in H6 but PHY is completely different
<vagrantc> the kernel load address? or u-boot?
<apritzel> the U-Boot proper raw SD offset, just a sec ....
<jernej> fun fact - H616 has no SRAM A2
<apritzel> jernej: ah, cool, I started digging into this, but didn't have much time yet
<jernej> any known new sources for DRAM PHY?
<apritzel> none at all? does it have an ARISC? The A63 has some Cortex-M, if I can trust the diagrams ;-)
<jernej> as far as I can tell, none
<jernej> where does ATF usually reside?
<jernej> not sure about coprocessor
<jernej> anyway, I have very early stages of SPL support - it boots until DRAM init code
<apritzel> jernej: exactly in SRAM A2, because that's deemed to be the secure SRAM (which it really isn't, but that's another story)
<apritzel> jernej: yeah, I got to the same stage on the A63
<jernej> and only PHY config is missing, controller init goes through
<jernej> I hope I'll find motivation for finishing it in following days
<apritzel> jernej: cool, I need to check how for mine actually came
<jernej> do you have any SDK for A63?
<apritzel> vagrantc: try CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR. That is the sector offset on the SD card where the SPL loads the rest of U-Boot (the FIT image)
<vagrantc> apritzel: it needs to match one of the altnate offsets? i think i used the defaults for sunxi, and used one of the alternate rockchip offsets
msimpson has joined #linux-sunxi
msimpson has quit [Client Quit]
<apritzel> vagrantc: there are two offsets: the first is the SPL one, dictated by the BROM: 8k and 128k for Allwinner, and 32K, 544K, 1056K... for Rockchip
<vagrantc> right
<apritzel> vagrantc: the second one is where to find the rest of U-Boot, which is a Kconfig variable in U-Boot
[WayOfLife] is now known as [KAZAN]
<apritzel> there are some default values (typically right behind the SPL, for instance), but you can tweak them
<vagrantc> i *thought* the u-boot.itb parts were non-conflicting if i used 8k allwinner SPL and ... forget if it was 544k or 1056k for rockchip SPL ... the u-boot.itb was then installable in the default location, and loaded on both machines
<apritzel> for that case you would need to put the Rockchip SPL at 1056K, and keep the RK .itb at 4MB
<vagrantc> right
<apritzel> then you can use the Allwinner SPL at 8K, and the .itb at the default 40K
<apritzel> just make sure you have no FAT partition at 1MB
<vagrantc> exactly ... but for some reason the kernel wouldn't boot when i did ...
<apritzel> so you got into U-Boot in both cases?
<vagrantc> yes
<vagrantc> was very exciting! :)
<apritzel> ah, OK, then this part is indeed fine
<apritzel> so what was the exact problem with the kernel loading
<vagrantc> i'd get starting kernel... and that was it
<vagrantc> no serial console output
<vagrantc> if i remember correctly, it booted fine on the pinebook (a64), just not the pinebook pro (rk3399)
<apritzel> did you try this with a normal (single board) mainline U-Boot on the Pro?
<vagrantc> yes
<apritzel> which DTB did you use? did you load one or used $fdtcontroladdr?
<vagrantc> used distro_bootcmd and extlinux
<vagrantc> which i think loads to $fdt_addr_r
<apritzel> mmh, I see, that should be fine then
AneoX has quit [Ping timeout: 272 seconds]
AneoX has joined #linux-sunxi
teteros has left #linux-sunxi ["WeeChat 2.9"]
victhor has joined #linux-sunxi
<apritzel> jernej: I don't have any source, but there is the manual, which is quite complete, and similar to the H6
<apritzel> jernej: and I found a firmware update image, from which I could extract some boot0 bits (and started to put this through a disassembler and emulator to track DRAM register accesses)
<jernej> yeah, I did the same for H616
<jernej> oh, how do you emulate?
<jernej> qemu?
<apritzel> that would be the natural choice, but there are some legal problems with that, so I heavily hacked kvmtool
<jernej> what legal problems?
<jernej> anyway, how do you emulate DRAM? or is it just memory device?
<apritzel> the actual DRAM array is just the normal KVM memslot
<apritzel> for the DRAM *controller* I trap and log
<apritzel> and started to connect FEL into that
<apritzel> so that every write trap would be forwarded as a FEL MMIO write to the actual chip
<apritzel> similar with reads
<jernej> uh, that's advanced reverse engineering :)
<jernej> I only dump registers and compare them to disassembled code :)
<apritzel> I tried that before, but that doesn't cover everything, so I wanted to try this new approach
<apritzel> so that I get a *sequence* of registers to write
<jernej> sure, but that you should also get in disassembled code, albeit it's much more tedious work
<apritzel> yeah, I agree, but whenever I try the full disassembly route I get frustrated after a while, because progress is so slow
<apritzel> and also the typical code quality usually hurts my eyes ;-)
<apritzel> I was hoping to find just the few differences between the H6 and A63 code ...
<jernej> is there a lot of differences?
AneoX has quit [Ping timeout: 264 seconds]
<apritzel> I don't know yet, but the manual looked rather close to the H6 (generation wise: clocks, SRAM), and with some A64 similarities (because: tablet chip)
AneoX has joined #linux-sunxi
<jernej> H616 also looks very similar to H6, except for few obvious differences
camus1 has joined #linux-sunxi
kaspter has quit [Ping timeout: 240 seconds]
camus1 is now known as kaspter
sunshavi has quit [Ping timeout: 240 seconds]
<jernej> apritzel: do you know if there is any way to run H6 BSP kernel on mainline U-Boot?
<jernej> I would like debug some things which are not so apparent
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.1 Aria http://www.kvirc.net/]
c10ud^ has quit [Ping timeout: 260 seconds]
matthias_bgg has quit [Quit: Leaving]
lurchi__ is now known as lurchi_
apritzel has quit [Ping timeout: 264 seconds]
apritzel has joined #linux-sunxi
gediz0x5391 has joined #linux-sunxi
gediz0x5391 has quit [Client Quit]
<apritzel> jernej: that's hard for the arm64 kernels, if it's just for an experiment, you can surely hack away the BSP kernel to not use Allwinner SMC calls (if they still do this)
<jernej> yeah, just for experiment
<jernej> so smc calls are only issue?
cmeerw has quit [Ping timeout: 268 seconds]
<apritzel> jernej: the showstopper one that springs to mind, plus their totally different and non-standard DTB, but tbh I decided a long time ago to not care, so don't know for sure if there is more
<apritzel> I am not into that kind of retro-computing (Linux 3.10?), you know ;-)
<jernej> :)
<megi> xunlong finally raised prices :)
hlauer has quit [Ping timeout: 260 seconds]
jstein has quit [Ping timeout: 258 seconds]
<hexdump0815> btw. i dumped the boot blocks from a h616 box and put it onto an sd card and tried to boot a h313 box from it and i got as far as on the h616 box - same vice versa
<hexdump0815> so looks like h616 and h313 are quite similar maybe too, i.e. as soon as h616 is running there is maybe a good chance to be close to a running h313 too :)
<hexdump0815> looks simlar to the rockchip rk3328 and rk3318 which seem to be very similar too
leio has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
leio has joined #linux-sunxi
hexdump0815 has quit [Remote host closed the connection]
AneoX has quit [Ping timeout: 260 seconds]
AneoX has joined #linux-sunxi
AneoX has quit [Ping timeout: 260 seconds]
AneoX has joined #linux-sunxi
AneoX has quit [Ping timeout: 256 seconds]
AneoX has joined #linux-sunxi
luke-jr has quit [Quit: ZNC - http://znc.sourceforge.net]
luke-jr has joined #linux-sunxi
sunshavi has joined #linux-sunxi