<apritzel>
although TPR11 and TPR12 being 0 doesn't make much sense here, looking at the code, and considering bits TPR10_DX_BIT_DELAY1 and TPR10_DX_BIT_DELAY0 are set
ftg has quit [Read error: Connection reset by peer]
montjoie has joined #linux-sunxi
montjoie_ has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
user_ has joined #linux-sunxi
junari has quit [Remote host closed the connection]
warpme has joined #linux-sunxi
mripard has joined #linux-sunxi
<tokyovigilante>
ok have run a diff of u-boot.bin after a round-trip to the device, there's a pattern...sort of
<tokyovigilante>
also, d**m, ImHex is where it's at for hex editing
<tokyovigilante>
interestingly exact same 4 byte chunk out of that unknown relocation message, so clearly not random, but also some variable length insertions
<Jookia>
tokyovigilante: interesting comparison
<gamiee>
wingrime-ww : also GloomyGhost / Yuzuki seems to have good relationship with Allwinner, she was invited into their HQ once. Also as far as I understand, she works for company, which directly partners with Allwinner, so of course, she have access to internal stuff.
<Jookia>
fancy
<tokyovigilante>
So basically the first 4 bytes of every 64 are either replaced by 1-4 null bytes, mostly 4 but every so often 1, 2 or 3, so the written image ends up being a few hundred bytes shorter
<Jookia>
Did you try the values apritzel noted above?
<tokyovigilante>
yup, with the exception of TPR6, was already using them
<Jookia>
ah ok
<Jookia>
i wonder if you could sunxi-fel the bsp u-boot
<tokyovigilante>
have tried a few combinations but not very scientific at this point, just random combos on the internet/in other device configs
<tokyovigilante>
the u-boot proper or spl? The BSP uses a very old u-boot (I think pre-SPL, if that is a thing)
<mripard>
tokyovigilante: what are you writing it to?
<tokyovigilante>
the board over FEL
<tokyovigilante>
Anbernic RG35XXP, based on a H700
<tokyovigilante>
basically fails to run u-boot after successfully executing SPL, and it seems to be a subtle DRAM misconfig as manually writing u-boot.bin to 0x4a000000 and then reading it back again via FEL has lots of transcription errors
<tokyovigilante>
and the transcription errors are exactly the same time every time I try, with a repeating pattern as described. I would say hardware is bad but it runs the vendor BSP fine
<mripard>
sorry, I was asking what was the storage medium you were writing to on that board :)
<tokyovigilante>
oh sorry, I assume the H700's SRAM, then there is a single 1GiB LPDDR4
<tokyovigilante>
hold on, random fiddling with TPRs seems to have finally got me a matching readback
<tokyovigilante>
Core: 54 devices, 20 uclasses, devicetree: separate
<gamiee>
yay!
<gamiee>
gj
<tokyovigilante>
now I just need a devicetree, display driver, all of linux, etc.... just the easy stuff
<tokyovigilante>
thanks all, absolutely no idea what I'm doing but great help
apritzel has joined #linux-sunxi
<apritzel>
tokyovigilante: awesome! Can you somehow share the values that work for you? And that's with the alternative PHY init values, right?
<apritzel>
tokyovigilante: the devicetree shouldn't be a big problem, since you have some other H616 boards to copy from
<Jookia>
is there a u-boot memtester
<apritzel>
tokyovigilante: just start, and put it somewhere, so that we can have a look and make suggestions
<apritzel>
now you should be able to get a Linux on the UART with SD card and USB pretty quickly
<tokyovigilante>
apritzel: yup, thanks for the help
<apritzel>
Jookia: yes, there is CONFIG_CMD_MEMTEST, implemented in cmd/mem.c, "mtest" is the command
<tokyovigilante>
"Failed to set core voltage! Can't set CPU frequency" has made a comeback, which I'm not quite sure what to do with, but uboot seems to be running fine, gave it one of the H618 board dtbs, and it's getting all the way through to trying to find a linux kernel
<tokyovigilante>
Anyway, working timings here, and yes with the PHY init patch from jernej
<libv>
would it have made sense to have used sunxi-tools/meminfo?
<libv>
if it had support for h616 that is
<apritzel>
libv: I looked at that, but dismissed it for some reason
bauen1 has joined #linux-sunxi
<libv>
there is a wild array of different dram paras in this image, and the one from boot0 matches the dram_para.txt i posted for the values in uboot config
<libv>
tpr11/12 are 0
<libv>
which is how tokyovigilante got success apparently
<libv>
so it is worth to try to revert these values again to see if it truly was these values, or if it was something else
<apritzel>
it's just compile tested, and just contains the regulator parts for now, but that should unblock you for the DT and for getting to a prompt in general
JohnDoe_71Rus has joined #linux-sunxi
<libv>
apritzel: what reason made you dismiss meminfo?
linkmauve has left #linux-sunxi [Error from remote client]
linkmauve has joined #linux-sunxi
wasutton3 has joined #linux-sunxi
wasutton| has joined #linux-sunxi
wasutton- has quit [Ping timeout: 480 seconds]
wasutton3 has quit [Ping timeout: 480 seconds]
wasutton3 has joined #linux-sunxi
wasutton- has joined #linux-sunxi
wasutton| has quit [Ping timeout: 480 seconds]
wasutton3 has quit [Ping timeout: 480 seconds]
jason123onirc has quit [Ping timeout: 480 seconds]
jason123onirc has joined #linux-sunxi
szemzoa has quit [Remote host closed the connection]
<apritzel>
libv: there were multiple issues: for a start, just learning the SoC in use is tricky now, since the SRAM controller has moved in address space for later SoCs
<apritzel>
secondly, many distros now enable CONFIG_{,IO_}STRICT_DEVMEM, which prevents mmap-ing device memory for peripherals which the kernel uses
<apritzel>
for the A64 this also might affect the DRAM controller, but definitely the CCU and the SRAM controller
<libv>
oh, good point, /dev/mem is also an issue for flashprog
<apritzel>
also conceptually, for later SoCs, many DRAM values we need are actually not written "as is" to registers, but either drive decisions (TPR10) or spread over multiple registers (TPR11/12)
<libv>
the latter is solvable, the logic can be built in
<apritzel>
so it would be quite some work, also to refactor the existing code to deal with all of that
<apritzel>
in general this comes from a time when we speaking about *the* DRAM controller ;-)
<libv>
again, this would not have been an issue if it had been kept up over the last decade
<apritzel>
right, let me ask the original author ;-)
<libv>
for the anbernic, it would've made it easy to find out what the ubuntu based image had programmed
<libv>
:)
<apritzel>
well, tbh, the need for those exercises is pretty rare, and by just decoding the head of the boot0 image we mostly got what we wanted
<apritzel>
there was a handful of times this was done, mostly once for a new SoC. People just sent hexdumps of the registers to jernej and others, and he came up with the code
<libv>
but this should be a respin of h616
<libv>
the h700 that is
<libv>
just with lpddr4
<apritzel>
yes, and the H616 DRAM controller needs apparently more individual handholding *per board*
<libv>
which is an argument for meminfo
<apritzel>
for the other SoCs we typically had one set of parameters per DRAM type
<apritzel>
libv: sorry, my application for the 28h day is still pending ...
<apritzel>
libv: I am happy to review patches. It would probably be good to allow external dumps (from U-Boot) to be parsed, also to manually specify the SoC type
<apritzel>
or use the new fancy SoC ID sysfs interface
<apritzel>
so yes, somehow solvable problems, but a lot of work for limited benefit, at least for me
<libv>
or me, tokyovigilante having thrown some spaghetti at the wall until feels somewhat wrong
<libv>
for me even
<libv>
until it booted even
<libv>
pfff
<libv>
and i think he either ran into something else which made the values take hold properly (hence my feeling for a need to retest), or something is off in the handling of the tpr values he changed
<libv>
it requires some further investigation
<apritzel>
sure
<libv>
ddr4/lpddr4 boards seem rare though
<libv>
definitely for h616
<apritzel>
not sure how to measure "rare", the OrangePi Zero3 and Zero2W seem quite popular, and there are reports of other boards using LPDDR4
<libv>
ah, right, i dled the image for that but never unpacked it
<libv>
need to test my sunxi-fw changes against it still
bauen1 has joined #linux-sunxi
<libv>
for a523, odt_en seems to be renamed to para0
<libv>
a523 also adds a value tpr14
<libv>
right, after a lot of digging, i dug out an image for the teclast p26t tablet
<libv>
here the fex had odt_en renamed to para0
<apritzel>
libv: you can download an image for the P85T tablet from the official website, the device code is P3M2
<libv>
thanks, dling
warpme has quit []
<apritzel>
for the A523 we have no code yet for the DRAM controller init, so this is quite theoretical at this point
<libv>
hah, for the p85t tpr14 is populated, so it makes sense to use the a523 struct for it
<libv>
ah, it is a523
<libv>
idiot.
<libv>
so it matches the p26t structure fully
<apritzel>
the P26T is the 10inch version of the P85T, but I don't know how close they are otherwise
<libv>
quite severely, only few changes in the fex file
<libv>
and none seem to be related with actual board level changes
<jernej>
tokyovigilante: you most likely see "Failed to set core voltage! Can't set CPU frequency" due to missing PMIC driver in TF-A and only after reboot and you have PMIC on I2C bus, right?
<jernej>
Issue is that TF-A switches PMIC to RSB bus, but switches back to I2C only if everything goes right.
<jernej>
at least that's my working theory
<apritzel>
jernej: that was my first impulse, too, but I think he didn't include TF-A at all at this point, and there is no Linux (and DT) to boot yet
<apritzel>
but yeah, power cycling is probably better if booted into something else meanwhile, though it might be not as easy on a battery powered device
<apritzel>
we should probably print some diagnostics in sunxi_board_init(), to indicate if the bus init or something else failed
hallyn has quit [Quit: Lost terminal]
<tokyovigilante>
ah right, no I did plug the full TF-A/uboot image back in once I had the DRAM problem fixed (spaghetti-ed is definitely right)
<tokyovigilante>
I did see it trying RSB access
<tokyovigilante>
Just using one of the H618 TV board DTs was quite successful by the looks, matched quite a few devices and got all the way to looking for a PXE linux image, but no ethernet ;)
<tokyovigilante>
Yeah PMIC is on I2C
hallyn has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
<apritzel>
tokyovigilante: ah, I see, so jernej was right, that would explain the problem. We need to fix this in TF-A. Unfortunately so far every SoC came with one PMIC and used one bus, so this requires some refactoring.
<apritzel>
tokyovigilante: you should be able to load a kernel, or a extlinux.conf, or a boot.scr, or a bootaa64.efi from SD card
<apritzel>
alternatively you can preload a kernel via FEL (to 0x40080000), and launch the kernel directly, though this takes a while, because FEL is slow, especially on the H616
<tokyovigilante>
apritzel: neat, will work on the DT as I really need the display, GPU etc up and running to make this worthwhile over the vendor BSP, but would I need a specific linux build? Or would a random ARM64 build of Fedora or something be able to donate its kernel?
<apritzel>
well, you should be able to use a generic, though recent kernel, but you won't get very far with this
<apritzel>
for a start, there is no support for the AXP717 PMIC in the upstream kernel. Hence my WIP patches I posted earlier, to get this fixed, though it would be in v6.10 the earliest.
<apritzel>
And on top of this there is also mainline support for even the display engine, not to speak of any fancy display
<tokyovigilante>
I certainly don't mind building a kernel, am hoping to lean on macromorgan for some of the drivers seeing as he has done display work for some of the other Anbernic handhelds
<apritzel>
that's the downside: a custom kernel is, well, custom, so you might just miss out on things like USB device drivers or something
<apritzel>
tokyovigilante: you can use that branch directly, it's on yesterday's kernel
<tokyovigilante>
I assume an orangepi 3 kconfig is a good place to start?
<apritzel>
tokyovigilante: what is an orangepi 3 kconfig? There is no such thing in the arm64 kernel ....
<tokyovigilante>
annoying, i was hoping some of the vendors would have sensible configs published or in BSPs to crib from
<apritzel>
arm64 is a single image kernel like x86: just use "defconfig", and then maybe add what you need
<tokyovigilante>
I mean defconfig sorry
<Jookia>
there's been a big effort to move towards single architecture configurations/images where the dts is per-device
<apritzel>
exactly
<tokyovigilante>
oh right, sorry this is all wildly new to me compared to x86
<Jookia>
i haven't touched arm64 yet, i live in armv7 land
<apritzel>
those custom kernel configs, that were so common, are just not scaling anymore, especially if your device is not really embedded
<Jookia>
tokyovigilante: x86 has a single image with ACPI that specifies something like a device tree, so arm64 does the same
<apritzel>
Jookia: arm64 was designed to be a single image kernel from the very beginning
<Jookia>
oh cool!
<apritzel>
look in arch/arm64/configs ;-)
<tokyovigilante>
that was my exact problem trying to maintain one for my laptop and one for the desktop
<Jookia>
yeah usually distros have their own x86 configs or something that include basically everything you can build
<apritzel>
for x86 this is an even bigger problem: how you know which USB device or PCI device you will need tomorrow?
<apritzel>
and people rightfully expect to plug stuff in and it works
<Jookia>
embedded developers like to save space by removing features they don't need in the field, but with storage spaces getting bigger it's not so much a problem now
<Jookia>
unless you're trying to fit a system on 256mb of NAND like i am :(
<tokyovigilante>
It is nuts carrying round a handheld that cost $70 and has 64+256GB of SD storage
<apritzel>
so the solution is: you compile everything that you don't need for immediate booting as a module, the rest is "y"
<tokyovigilante>
ok, well that now makes complete sense, should be able to put it together this evening, and will give the PMIC driver a test
<Jookia>
fancy!
<apritzel>
tokyovigilante: the complete modules packages for a distro like Ubuntu is like 400 MB, IIRC. Which sounds massive for embedded people, but is only a very small part of even a 64GB SD card
<apritzel>
tokyovigilante: what's your host PC distro? gentoo?
<apritzel>
tokyovigilante: if you want to have that arousing feeling of seeing a shell prompt, just copy and *strip down* an existing DT. Remove everything regulator and AXP for the start, it's not needed for UART and SD card
<tokyovigilante>
no Fedora, has all the gcc cross-compilation support packaged up
<apritzel>
you can use any small arm64 rootfs, for instance the Debian installer, that's an easy find and download
<apritzel>
tokyovigilante: great, Fedora is even better
<tokyovigilante>
not sure I do, but will give that a go
<Jookia>
i still have to get around to learning yocto for a project :(
<apritzel>
and yeah, in major distros installing a cross-compiler is a bliss these days, typically a single line for the package manager
<apritzel>
for Debian based distros for instance it's a simple as: "apt-get install crossbuild-essential-arm64"
<apritzel>
tokyovigilante: since you compiled U-Boot and TF-A already, you probably can just type: "export CROSS_COMPILE=aarch64-linux-gnu-; make defconfig; make -j$(nproc) Image"
<apritzel>
tokyovigilante: you just have that "Plus" device, right? With one USB-C port? It looks like the "RG35XX H" has two USB ports?
<tokyovigilante>
cool, yeah have the cross-compiler set up already, looks like user-space is harder as it needs all the libs etc built as well, but I guess that's what buildroot is for
<tokyovigilante>
yup the plus, single USB, and mini-HDMI. I think the -H should be similar HW (all the community BSPs based on the vendor image can boot on both) but don't have one to confirm
<tokyovigilante>
The dream is to just use it as a portable game machine/music player, but then be able to plug in an ipad as a monitor and a bluetooth keyboard and pretend it's a ~RPi-3 equivalent desktop ;)
<tokyovigilante>
I should really just get one, looks like we'll definitely (eventually) get mainline and all the devices working
<tokyovigilante>
*one RG35XXH as well
<apritzel>
yes, I am pretty confident you will see a mainline Linux shell prompt this week, with USB and the SD cards working.
<apritzel>
do you know what the WiFi/BT chip is?
<tokyovigilante>
pretty sure its a Realtek RTL9921CS
<tokyovigilante>
which is already in kernel
<apritzel>
tokyovigilante: the good thing about userspace is that it's completely device agnostic: the same rootfs would run on *any* arm64 machine, from the tiniest board to big servers
<apritzel>
so yes, you can build something yourself, but it's not necessary and probably just easier to grab something from somewhere
<tokyovigilante>
great, will just try a debian one
<apritzel>
oh, very cool, that means that WiFi and BT are just around the corner, which gives you internet and thus so much more easy access to the system