ChanServ 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
<Jookia> pixman could work, it wouldn't use the GPU though would it?
<tokyovigilante> oh yeah, possibly not
<tokyovigilante> the X11 backend might still work
<Jookia> there's also framebuffer backend maybe? not sure
<macromorgan> would we be able to figure it out if we had the boot0 from BSP? The ram parameters I mean?
<macromorgan> I do have one floating around here
<macromorgan> (times like this a datasheet would be handy... looking at you Allwinner)
<apritzel> macromorgan: AFAIK the DRAM controller was *never* documented in a datasheet
<macromorgan> boo
<apritzel> and we already harvested the DRAM parameter from boot0
<macromorgan> okay, yeah I remember that now
<apritzel> given that tokyovigilante is running quite far with his experiments (via FEL), I'd say the DRAM *parameters* are not the problem
<apritzel> tokyovigilante: did you try "dd"ing u-boot-sunxi-with-spl.bin to an SD card and boot the system from there?
<macromorgan> make sure when you dd it you do it with bs=512 seek=16 (right?)?
<macromorgan> That gets it to read from SD card for me
<macromorgan> but again it craps out at the calloc() function
<tokyovigilante> apritzel: yup, didn't debug extensively but no boot and no serial output. macromorgan how are you managing to debug when booting from the SD? I don't get anything over serial
<macromorgan> I dunno... it's working for me
<tokyovigilante> hmm
<tokyovigilante> maybe my dd skills are sub-par
<macromorgan> by working I mean it's getting just to that part where calloc dies
<tokyovigilante> I just used bs=1k seek=128 (have a GPT partition table on the card)
<macromorgan> has to be at block 8k, you'll have to truncate your GPT table to 56 entries
<Jookia> you can also relocate your GPT table
<Jookia> i usually put mine after the SPL or somewhere
<macromorgan> too advanced for my blood... as long as I can have 2-3 partitions with GPT that's good enough.
<Jookia> whatever works
<macromorgan> but try doing it at bs=1k seek=8
<macromorgan> (unless the BROM can pick it up from multiple locations, in which case I learned something else new today)
<apritzel> macromorgan: yes, all SoCs since the H3 (I think) also check at 128k
<apritzel> probably to accommodate a full GPT
<apritzel> b/c while you *can* cut a GPT short, that's not what the standard says, and not what tools implement
<apritzel> we have extra support code in the SPL to cater for those two different locations
<macromorgan> let me check again that my ram parameters are correct
acmeplus has joined #linux-sunxi
<tokyovigilante> debug2: X11 forwarding request accepted on channel 0
<acmeplus> tokyovigilante: just use the orangepi zero3 ubuntu image, replace the kernel and modules. It already has X, all glx friends, etc.
<acmeplus> For sway you are going to need Wayland and friends, so it's going to be too many layers
<apritzel> acmeplus: btw, many thanks for the Wiki page and the pictures
<tokyovigilante> possibly true. I have installed i3 on my Fedora image, do I need to be running a client x11 session for it to work?
<acmeplus> no worries, I still need to add all the legacy image information and how to build a full image (without working display) for that. And I guess add the Astro City Mini and Egret II mini pages. I never went back to those but I wonder if mainline is doable there (R16)
<apritzel> acmeplus: don't invest too much time into those legacy images, that is mostly distraction from the mainline goal ;-)
<tokyovigilante> I am quite enjoying my voyage of discovery into the guts of this stuff, way better than LFS
KREYREN_oftc has joined #linux-sunxi
<Jookia> yes, it's quite fun
<Jookia> but LFS is more userspace i think
<tokyovigilante> true
<tokyovigilante> hmm, so I get a crash as soon as I try and start i3 over ssh
<Jookia> oh no
<tokyovigilante> X.Org X Server 1.20.14
<tokyovigilante> X Protocol Version 11, Revision 0
<tokyovigilante> Build Operating System: 6.6.9-100.fc38.aarch64
<tokyovigilante> Current Operating System: Linux fedora 6.8.0-rc7-00040-g8bba1f46eb2a #12 SMP PREEMPT Wed Mar 13 12:34:31 NZDT 2024 aarch64
<tokyovigilante> Kernel command line: console=tty0 console=ttyS0,115200 root=/dev/mmcblk0p3
<tokyovigilante> (and a few more generic X startup lines)
<tokyovigilante> nothing on the serial either, must be bad
<tokyovigilante> vulkaninfo also crashed, glxinfo just had a tanty about no display. I assume the GPU bringup is not quite there
acmeplus has quit [Remote host closed the connection]
<Jookia> interesting
apritzel has quit [Ping timeout: 480 seconds]
<tokyovigilante> I wonder if I need a gpu_opp_table in the DTS
acmeplus has joined #linux-sunxi
<Jookia> could be worth adding to see if it fixes anything
montjoie_ has joined #linux-sunxi
montjoie has quit [Ping timeout: 480 seconds]
<tokyovigilante> ok, have chucked in a whole bunch of stuff from the orangepi (HDMI, sound) just for fun
<tokyovigilante> did no harm, but did not help
<tokyovigilante> No sound either
<acmeplus> I tried sound yesterday and couldn't get anything. Did you add the codec and ahub_*?
acmeplus has quit [Quit: Page closed]
acmeplus has joined #linux-sunxi
<acmeplus> tokyovigilante: I just got the dw_hdmi and related modules to auto load after tinkering the DT with additional orangepizero3 changes. Still getting the deferred probe pending: panfrost: _opp_set_regulators: no regulator (mali) found
<acmeplus> Also added again all the codec information but there are no audio codecs detected
acmeplus has quit [Quit: This computer has gone to sleep]
Net147 has quit [Ping timeout: 480 seconds]
junari has joined #linux-sunxi
hexdump01 has joined #linux-sunxi
junari has quit [Ping timeout: 480 seconds]
hexdump0815 has quit [Ping timeout: 480 seconds]
Net147 has joined #linux-sunxi
vagrantc has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
macromorgan has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
chewitt has joined #linux-sunxi
junari has joined #linux-sunxi
cyrozap has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
chewitt has quit [Quit: Zzz..]
cyrozap has joined #linux-sunxi
tlwoerner has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
chewitt has joined #linux-sunxi
chewitt has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
warpme has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
warpme has quit []
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
KREYREN_oftc has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
KREYREN_oftc has joined #linux-sunxi
warpme has quit []
apritzel has joined #linux-sunxi
warpme has joined #linux-sunxi
paulk-bis has joined #linux-sunxi
paulk has quit [Ping timeout: 480 seconds]
junari has quit [Remote host closed the connection]
chewitt has joined #linux-sunxi
paulk-ter has joined #linux-sunxi
paulk-bis has quit [Ping timeout: 480 seconds]
DuClare has joined #linux-sunxi
DuClare__ has quit [Ping timeout: 480 seconds]
tolthoff has joined #linux-sunxi
dsimic is now known as Guest2617
dsimic has joined #linux-sunxi
Guest2617 has quit [Ping timeout: 480 seconds]
warpme has quit [Read error: Connection reset by peer]
warpme has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
warpme has quit []
acmeplus has joined #linux-sunxi
junari has joined #linux-sunxi
junari has quit []
acmeplus has quit []
bauen1 has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.1 Aria http://www.kvirc.net/]
bauen1_ has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
tolthoff has quit [Remote host closed the connection]
tlwoerner has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
macromorgan has joined #linux-sunxi
macromorgan has quit [Quit: Leaving]
vagrantc has joined #linux-sunxi
macromorgan has joined #linux-sunxi
<macromorgan> switched to Quassel... bye bye hexchat
<gamiee> macromorgan : yay! Quassel is much much better
<macromorgan> do you by chance know the address of the memory controller? I can try dumping the regs and see what differences there are (in case those matter).
<apritzel> for the registers in there, check arch/arm/mach-sunxi/dram_sun50i_h616.c and the data structures in arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
jason123santaonirc has joined #linux-sunxi
jason123onirc has quit [Ping timeout: 480 seconds]
gues83396 has joined #linux-sunxi
gues83396 has quit []
warpme has quit []
thecheofusi has joined #linux-sunxi
<macromorgan> and forgive my ignorance, but without an mmu how can I read the memory (aligned reads, read as a w or an l as readl or readw())?
<macromorgan> I'm going to try dumping the regs from the factory U-Boot first
<Jookia> macromorgan: i think readl/readw/readb should work, just aligned to those data widths
<macromorgan> cool, thanks
<Jookia> so bytes are always aligned, words are aligned to 4 bytes, longs to 8... if you're on a 64-bit platform i think
<Jookia> registers are already aligned i think so you don't need to worry too much
thecheofusi_ has joined #linux-sunxi
<jernej> tokyovigilante: for proper GPU operation you need to define regulator in gpu node and provide gpu opp table. I noticed that at least on one board defaults weren't good.
thecheofusi has left #linux-sunxi [#linux-sunxi]
thecheofusi_ has left #linux-sunxi [#linux-sunxi]
<jernej> and I didn't work on D1 support. Also D1 and H616 display related drivers are not directly reusable, except maybe TCON
<jernej> but I believe analog audio codec is quite similar
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
flyback has joined #linux-sunxi
<apritzel> macromorgan: for anything compiler generated you should be fine, as we use -mno-unaligned-access for the SPL
<macromorgan> okay
<apritzel> if you just want to play with the raw addresses, just use readl()
<apritzel> check mctl_mem_matches() for inspiration, we use that already for some simple aliasing tests
chewitt has quit [Quit: Zzz..]
apritzel has quit [Ping timeout: 480 seconds]
wasutton3 has joined #linux-sunxi
wasutton^ has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
bauen1_ has quit [Ping timeout: 480 seconds]
mripard has quit [Remote host closed the connection]
warpme has joined #linux-sunxi
warpme has quit [Read error: Connection reset by peer]
JohnDoe_71Rus has quit [Quit: KVIrc 5.2.0 Quasar http://www.kvirc.net/]
<macromorgan> dumps from the factory RAM init: https://gist.github.com/macromorgan/ac3fdaae62fe00f65e766ddc40436d8c
<macromorgan> just have to cobble something together to do that early after init for the mainline one now...
bauen1 has joined #linux-sunxi
wasutton- has joined #linux-sunxi
wasutton3 has quit [Ping timeout: 480 seconds]
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
<macromorgan> weird... on rare occasions my board detects it as 2048MB at bootup too (mainline): `DRAM: 2048 MiB`
hexdump01 has quit []
hexdump0815 has joined #linux-sunxi
<hexdump0815> tokyovigilante: acmeplus: apritzel: macromorgan: i think it is also possible to test if the gpu is working without working xorg or wayland via offline rendering - see: https://github.com/hexdump0815/mesa-etc-build/blob/master/old-info.txt#L130-L137
<macromorgan> kmscube?
<macromorgan> I'm not quite there yet, still need to get the device to actually boot :-)
<hexdump0815> oh not sure if it is maybe limited to lima driver only - at least xdarklight tested the gpu this way to be working on amlogic meson8 long before hdmi was working
ftg has joined #linux-sunxi
<macromorgan> Here are the mainline memory dumps for comparison: https://gist.github.com/macromorgan/8cd1c76c4c120043030b803f4dae7fcc
<macromorgan> going to set them up for diff and see what is different
<macromorgan> and here are the side by side register differences: https://gist.github.com/macromorgan/835e623fa27365be289ff73afa46eeb2
apritzel has joined #linux-sunxi
<macromorgan> so readl() works, at least doing readl(0x48000000). But calloc is still where it freezes
<apritzel> macromorgan: thanks for trying. So can you write some (computed) pattern over a larger range of memory (start with 64K, then 1MB, maybe), and then read that back and compare?
<macromorgan> I'll give it a shot
<apritzel> because tokyovigilante originally had this issue, where *some* words were stuck at 0, but the rest was fine
Schimsalabim has quit [Read error: Connection reset by peer]
<macromorgan> forgive my brain-dead-ness, but sanity check a long is 32 bits right?
<macromorgan> like writel/readl?
<Jookia> i think so
<Jookia> b = 8 bits, w = 16 bits, long = 32 bits, q = 64 bits
<macromorgan> because every single bit I wrote turned out wrong, and that tells me I did something wrong
<macromorgan> I did a while loop to write `writel(addr, 0xdead);` and then increment the address by 4 every single time
<apritzel> writel() has it the other way around: writel(value, addr);
<macromorgan> whoops
<macromorgan> also I'm wrong and dead is 16 bits right?
<macromorgan> so I should be doing 0xdeadbeef for a writel
<apritzel> and yes, those prefixes come from ancient times, when a long meant 32-bit, so writel/readl is 32-bits
<macromorgan> (sorry, no formal programmer education AT ALL)
<macromorgan> gotcha
<apritzel> yes, you would need 8 nibbles (4 bit hex characters) to cover 32 bits, so 0xdeadbeef is better
<macromorgan> still incrememnt by 4 each time too right?
<apritzel> yes
<macromorgan> okay I got this
<macromorgan> okay, just wrote deadbeef across a whole megabyte of memory and it read back just fine
<macromorgan> calloc still fails though
<macromorgan> shall I try a larger volume of RAM?
<apritzel> you can try back there where the malloc area is, which is 0x4ff80000
<macromorgan> I'm going to do a large volume (128MB of RAM) which includes that, let's see what it does
<apritzel> another thing to try is to write different patterns into each word, so just XOR your constant with the address value you write that to
<apritzel> this way you spot if cells alias each other, so whether different addresses point to the same storage
<macromorgan> okay
<macromorgan> I just wrote deadbeef again to 128MB of RAM and it worked
<macromorgan> took a while, but worked... still froze later
<macromorgan> okay, I'll do an XOR now
<macromorgan> that also worked. 128MB of writing (0xdeadbeef ^ addr) then checking each address and it being correct...
<macromorgan> what besides bad RAM would cause it to fail right at the calloc call when initing the mmc?
<macromorgan> I put printfs right before and after, it calls the before but never the after
<macromorgan> and to note this address range I'm writing to is between 0x48000000 and 0x50000000, so it should cover the malloc location
hentai has joined #linux-sunxi
<apritzel> macromorgan: can you run: scripts/config --set-val CONFIG_SPL_BSS_START_ADDR 0x30000 --set-val CONFIG_SPL_BSS_MAX_SIZE 0x8000
<apritzel> so the BSS (and malloc area, I believe) ends up in SRAM?
<apritzel> just as an extra data point ...
<apritzel> that would mean that the SPL doesn't touch DRAM for itself, except for the payloads it loads, of course
<macromorgan> it appears to die considerably sooner
<macromorgan> I'd have to troubleshoot to know exactly where
<macromorgan> but it never gets to the "Trying to boot from MMC1" message, so somewhere before there
<apritzel> tokyovigilante: when you boot via FEL, can you access the SD card from U-Boot proper? Like: "ls mmc 0", or "load mmc 0 $kernel_addr_r <some_file_from_the_SD_card>"
juri_ has quit [Ping timeout: 480 seconds]
<Jookia> is it frowned upon to submit a driver that doesn't implement all the features but only some? i mean it solves MY problem but...
<apritzel> Jookia: depends, but normally that's fine, if you can explain it and if it doesn't block future updates
<Jookia> ah that's good
<apritzel> (that's what I am doing with the AXP717 driver: just the regulators, battery charging and USB comes later)
<apritzel> actually you would do this anyway: build up the functionality in separate patches. You could see your approach then just as a split patch series
<Jookia> for this instance it's an audio codec but i've only implemented TDM mode and using clocking from the I2S bus
<apritzel> yeah, that's fine
<Jookia> and also some reverse engineering for undocumented stuff
<Jookia> i plan to dump notes as a TODO or something in the driver
<macromorgan> well that worked...I changed the CONFIG_SPL_STACK_R_ADDR and am now getting past that calloc failure (still failing, but now much further)
<macromorgan> what should that value be?
<macromorgan> it was getting set to something low (I don't remember setting it)
<macromorgan> like 0x50000 which wouldn't be in the RAM
<apritzel> 0x50000
<macromorgan> but that's not an address in the SDRAM, since those addresses start at 0x40000000 right?
<apritzel> macromorgan: that's the value I recommended to tokyovigilante the other day (and which I forgot to tell you now, sorry)
<macromorgan> 0x50000? if I set it to 0x50000000 I get past the calloc issue
<apritzel> the SPL runs fully from SRAM, but in a later stage uses some parts like the stack and the malloc buffer from DRAM, *after* that has been initialised
<apritzel> we did this because the earlier SoCs had only between 24KB and 32KB of SRAM
<macromorgan> okay, just offering that as a datapoint
<apritzel> the H616 has much more, so as an experiment we can put the late stack and the heap also into SRAM, to avoid touching DRAM at all
<apritzel> macromorgan: does it work if you change CONFIG_SPL_STACK_R_ADDR and CONFIG_SPL_BSS_START_ADDR to start with 0x5....?
<apritzel> so still DRAM, but higher up
<macromorgan> SRAM you mean? I'll check
<apritzel> no DRAM, so 0x5fe00000 and 0x5ff80000, respectively
<macromorgan> okay
<apritzel> since you said that moving the relocated stack to 0x50000000 made it go further
<macromorgan> check CONFIG_SPL_SYS_MALLOC_SIZE
<macromorgan> hmm
<apritzel> we don't use that, do we?
<apritzel> ("# CONFIG_SPL_SYS_MALLOC is not set", which blocks that SIZE variable)
<macromorgan> I increased CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN and got past it
<macromorgan> so I'm still stuck, but well past that error of calloc freezing at least
<macromorgan> it's at least getting past spl_load_image without giving an error now, which means it did all the pmic stuff successfully and did all the mmc init successfully too
<tokyovigilante> apritzel: yup I'm loading my kernel image from SD after loading u-boot (inc TF-A and DT in combined image) over FEL
<apritzel> right, thanks, so that means the MMC works in U-Boot
<tokyovigilante> load mmc 0:2 $kernel_addr_r Image is what I'm using (and adding 0x4... for the DT)
<tokyovigilante> Have the exact commands in a text file on my desktop at home, but they're based on the standard variables you posted a few days back
<KREYREN_oftc> Good News Everyone! I finally managed to brick my teres by loading a very broken u-boot onto it's eMMC
<tokyovigilante> (0:2 for 3rd partition)
<tokyovigilante> That is good news, Anbernic has a sale on in 3 days, and looks like the RG35XX- is about to be the ultimate cyberdeck...
<apritzel> KREYREN_oftc: what's wrong with putting a working U-Boot on an SD card and just boot from there?
<KREYREN_oftc> apritzel, yep that doesn't work :D
* KREYREN_oftc continues to read up on how to use FEL
<apritzel> why does that not work? if there is one good thing about Allwinner boards, it's that they are hard to brick
<apritzel> (if you have an SD card slot)
<KREYREN_oftc> i am just getting `Trying to boot from MMC2` and it won't progress further
<apritzel> that means it's booting from eMMC
<KREYREN_oftc> i flashed the unfinished u-boot build that doesn't have BL31 in it
<KREYREN_oftc> apritzel, and the eMMC is where is the broken u-boot :D
<apritzel> well, sure, but then just put a working U-Boot on an SD card?
<KREYREN_oftc> it doesn't want to load from sdcard
<KREYREN_oftc> though let me try to re-flash it
<apritzel> try a different SD card, sometimes they are funny
<apritzel> or indeed re-flash it, and make sure to type "sync" before removing the SD card from your host
<KREYREN_oftc> ooo it works now
<KREYREN_oftc> maaan i was so close to getting experience with FEL
<KREYREN_oftc> thanks apritzel <3
<KREYREN_oftc> hmm actually can i use FEL to flash u-boot in the eMMC or even SPI? that would be a great thing to add to the wiki
<KREYREN_oftc> bcs teres users keep complaining about not having the ability to write in the emmc directly
<apritzel> you can use sunxi-fel to write directly to SPI flash, but not to eMMC
<KREYREN_oftc> oo
<KREYREN_oftc> elaborate how?
<apritzel> that's theoretically possible, and would indeed be very useful, but is not implemented
<apritzel> does the Teres have a SPI flash?
<KREYREN_oftc> yep!
<apritzel> if yes: "sunxi-fel spiflash-info"
<KREYREN_oftc> ooo
<apritzel> for checking
* KREYREN_oftc goes for some kind of a pin to press the FEL button on the mainboard
<apritzel> then: sunxi-fel -v -p spiflash write 0 u-boot-sunxi-with-spl.bin
<KREYREN_oftc> through serial console or through USB-OTG?
<apritzel> sunxi-fel is the command to run on your host PC, that talks through USB with the SoC
<KREYREN_oftc> oke
* KREYREN_oftc goes to look for USB-A (M) to USB-A (M) Cable
<Jookia> KREYREN_oftc: be careful with those, you m ay need to cut/tape vbus
<KREYREN_oftc> Jookia, i am making one out of the cable i need for headphones atm
<KREYREN_oftc> sacrifices to the science must be made
<KREYREN_oftc> teres has USB-OTG wired on the IO board though so should be fine?
acmeplus has joined #linux-sunxi