<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
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>
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
<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
<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 :)