<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>
(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]
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]
<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
<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