<tuxd3v>
robmur01, no, was based on the datasheets from nanopir2s and also from rk3328
<Ashleee>
sorry my cat ran over the keyboard
<tuxd3v>
I am now checking the rk805 datasheet :)
<tuxd3v>
Ashleee, you need to cut the claws to your cat, if not it would be a dangerous lion :D
<robmur01>
the R2S schematic indirectly shows it too, via the table labelled "VCC_DDR" on page 3
<tuxd3v>
(BUCK3) Input supply voltage range VCC3 [ 2.7 - 5.5V ]
<tuxd3v>
but it hasa catch
<tuxd3v>
VBUCK3OUT=VFB3 * (1+Rfbup/Rfbdn)；please refer to the typical application
<tuxd3v>
what I don't know is the memory type that comes with nanopi r2s, I have a problem with my eyes, not being able to read tinny letters in the chips :S
<robmur01>
right, it's adjustable, but it's not *programmable*
<robmur01>
the DDR voltage will be set appropriately for whatever chips they are - AFAICS the only reason you'd have any need to ever mess with it is if you were overclocking the RAM and wanted to increase it above nominal
<tuxd3v>
you rifht it doesn't have the typical 6 bit programmable
<robmur01>
but in this case that would involve breaking out the soldering station and SMD resistor kit
<tuxd3v>
yeah indeed :)
<robmur01>
DVFS of the memory controller itself is by scaling VDD_LOGIC, IIRC
<tuxd3v>
rifht -> right
<robmur01>
Ashleee: it does appear to be rather broken - happens for an FVP build for AArch32 as well
<robmur01>
probably these are configs that nobody actually tests
<robmur01>
not sure what the issue reporting system is since it all moved off Github...
<Ashleee>
hmm :)
<Ashleee>
I tried v2.2 and v2.3 and they both share the problem
<Ashleee>
v2.1 doesn't have rk3288
<Ashleee>
hmm do I need ATF to boot aarch32 kernel actually?
<Ashleee>
I know I need to with arm64 but 32?
<robmur01>
nope, RK3288 systems usually just run without any TrustZone stack at all
<Ashleee>
ahh
<Ashleee>
so I can skip that, nice :)
<Ashleee>
thanks
<Ashleee>
I come from sunxi platform so I am used to atf being required :)
<robmur01>
yeah,. if you just want to make a thing work, build U-boot and Linux and you're good to go
<Ashleee>
I was donated a bunch of older/newer SBCs so I am plugging them all into BOINC to fight the pandemic
<Ashleee>
ok thanks :) if it works without atf one less problem for me :D
<robmur01>
for 32-bit Rockchips, all the horrible bodges for not having proper firmware are built in to Linux
kevery has quit [Ping timeout: 256 seconds]
<Ashleee>
rk3399 works fine :D
kevery1 has joined #linux-rockchip
<Ashleee>
with arm64 current kernel
<Ashleee>
and uboot
<Ashleee>
and atf :D
kevery1 is now known as kevery
<Ashleee>
hmm rk3288 defconfig doesn't fit into mkimage?
<Ashleee>
root@c0d5170d4910:/sources2/u-boot-tinkerboard# tools/mkimage -n rk3288 -T rksd -d spl/u-boot-spl-dtb.bin out
<Ashleee>
Error: SPL image is too large (size 0xb800 than 0x8000)
<Ashleee>
that's u-boot 2020.10
<vagrantc>
probably need to use the TPL
<vagrantc>
which loads the SPL, which loads u-boot
<Ashleee>
it is enabled
<Ashleee>
damn why cannot it produce final u-boot.bin that I can flash directly? :) or at least it looks like so
<Ashleee>
wait it does
<Ashleee>
but does it work is the other question
<vagrantc>
maybe your instructions are out of date?
<Ashleee>
yeah they were for 2018.x and it worked, trying to use 2020.10
<vagrantc>
the transition from SPL to TPL+SPL required a change of process
<Ashleee>
I remember doing the idbloader.img etc magic with rk3399