levitating has quit [Read error: Connection reset by peer]
levitating has joined #u-boot
levitating1 has joined #u-boot
levitating has quit [Client Quit]
levitating1 is now known as levitating
KREYREN__ has quit [Remote host closed the connection]
KREYREN__ has joined #u-boot
levitating1 has joined #u-boot
levitating has quit [Ping timeout: 248 seconds]
levitating1 is now known as levitating
sbach has joined #u-boot
clamor has joined #u-boot
_whitelogger has joined #u-boot
sbach has quit [Ping timeout: 276 seconds]
vardhan has joined #u-boot
monstr has joined #u-boot
goliath has joined #u-boot
monstr has quit [Ping timeout: 252 seconds]
frieder has joined #u-boot
haritz has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
gsz has joined #u-boot
sbach has joined #u-boot
sbach has quit [Ping timeout: 260 seconds]
ldevulder has joined #u-boot
alperak has joined #u-boot
goliath has quit [Ping timeout: 252 seconds]
<RoganDawes>
marex: I'm trying to modify the mx6ull evk config to suit, as suggested. I'm stuck on actually building what I have come up with, because it dies trying to build `arch/arm/cpu/armv7/lowlevel_init.S:32`, with `Error: syntax error -- `ldr sp,=(CFG_SYS_INIT_RAM_ADDR+CFG_SYS_INIT_RAM_SIZE-224)'`. From what I can make out, these two variables are
<RoganDawes>
defined in the include file (previously `include/configs/mx6ullevk.h`, now should be `include/configs/cb140.h`), but I cannot for the life of me find where this include file is referenced.
goliath has joined #u-boot
prabhakalad has quit [Quit: Konversation terminated!]
clamor has quit [Read error: Connection reset by peer]
clamor has joined #u-boot
<RoganDawes>
Ah, I figured it out. I had not updated `arch/arm/mach-imx/mx6/Kconfig` to refer to my new configuration file
<RoganDawes>
The problem I now sit with is that the imx6ullevk has 512MB RAM, and MYZR CB140 only has 256MB. It seems that either the plugin.S or the imxcfg file (or both) are setting up the DRAM controller incorrectly, and u-boot thinks that there should be 512MB. I suspect that this is also the reason that the NAND DMA is failing, but will dig into that once
<RoganDawes>
I can get the DRAM configured correctly
prabhakalad has joined #u-boot
Poltawer has joined #u-boot
Poltawer has quit [Ping timeout: 252 seconds]
Poltawer has joined #u-boot
<RoganDawes>
hmm, fixing the DRAM size didn't fix the NAND flash access :-(
Poltawer has quit [Ping timeout: 260 seconds]
Poltawer has joined #u-boot
sbach has joined #u-boot
naoki has quit [Quit: naoki]
Poltawer has quit [Ping timeout: 252 seconds]
Poltawer has joined #u-boot
<RoganDawes>
I'm guessing I need to construct a devicetree, since the vendor dump doesn't include one
<RoganDawes>
I spent some time trying to minimize the diff, and confirm the branching off point, but it appears to be based on a Freescale BSP, so there are a lot more changes in there than just the necessary
sbach has joined #u-boot
sbach has quit [Ping timeout: 244 seconds]
RoganDawes has quit [Quit: Client closed]
sbach has joined #u-boot
RoganDawes has joined #u-boot
RoganDawes has quit [Client Quit]
sbach has quit [Ping timeout: 245 seconds]
<Tartarus>
Community meeting in about an hour, btw all
<ja_02>
@RoganDawes if what you are asking is to convert that into a dt entry it should loop something like src/arm/nxp/imx/imx6-logicpd-som.dtsi:220
<ja_02>
i meant /dts/upstreamsrc/arm/nxp/imx/imx6-logicpd-som.dtsi
<RoganDawes>
ja_02: Thanks, i will check that out
sbach has joined #u-boot
<ja_02>
i guess sense its MX6UL grep for MX6UL_PAD_NAND_ in /dts/upstream/src/
<RoganDawes>
I think what I don't understand (not being familiar with device tree syntax), is what the hex number next to the pad name represents?
<ja_02>
that's not a device tree specific thing it is an array of numbers that is read by the driver so the macro is this `src/arm/nxp/imx/imx6ul-pinfunc.h:#define MX6UL_PAD_NAND_CE1_B__ECSPI3_MOSI 0x01b0 0x043c 0x055c 3 1` but the driver needs one more entry. iirc its the speed and slew rate for the pin. but you would need to look in the driver with the compatible you are using
gsz has joined #u-boot
<RoganDawes>
ah, I see! Thanks for the explanation.
<ja_02>
so in pinctrl/nxp/pinctrl-imx6.c, pinctrl/nxp/pinctrl-imx.c and pinctrl/nxp/pinctrl-imx-mmio.c
<ja_02>
also side note arch/arm/dts/myzr-cb140.dtsi should include #include "imx6ull.dtsi" not the dts. the device tree includes are like a tree structure
<RoganDawes>
ok, thanks forthe hint. I just copied the imx6ullevk.dts[i] as was suggested, and that is how it is done there
<RoganDawes>
tbh, I'm mostly a cargo cult programmer, when it comes to C. Monkey see, monkey do, hopefully benefits rain from the sky :-D
<ja_02>
oh oh ok the documentation for the compatible is in the linux source tree
<ja_02>
so here devicetree/bindings/pinctrl/fsl,imx35-pinctrl.yaml
<ja_02>
lol rust. My work is having me learn rust. IMO it kinda sucks for embedded stuff. but cool language
<ja_02>
also the uboot community meeting is about to start soon if you want to join
<marex>
ja_02: so yes, I only have SoCkit (I think the DE10 was derived from it or some such) and the DE0-Nano-SoC , also CV, but trimmed down
<marex>
the DE1, I think, I dont have that one, it has been a while since I used the SoCFPGA last (2022 apparently)
<marex>
do you have an actual compiler error(s) ?
<ja_02>
no
<marex>
one thing which also came to mind ... the SPL is size constrained and I was hitting size limits every once in a while, maybe that is what you ran into
<ja_02>
from what i remember it also was broken on the DE1-soc
<ja_02>
ah i can check
Poltawer has joined #u-boot
<ja_02>
i do have a built image thats broken
<marex>
there was something about stack corrupting text in the SPL, because stack was at the end of SRAM and it was growing into text sometimes
<marex>
if the SPL is like 56k+ , that might be it
<marex>
the 2022.10-ish commit I pasted worked on the DE0-Nano-SoC, I think that booted from SD card (?) , maybe you can try that and see if that works ... if it does, then use git bisect from that reference point and maybe bloat-o-meter or readelf -s to find out what grew and caused this failure in the SPL
<marex>
try git bisect to narrow it down then ? Such two reference points are nicely close by
vigneshr has quit [Quit: Connection closed for inactivity]
<ja_02>
yes the problem is I cant recreate the issue. only my professor and another student.
<ja_02>
also yes DE1-SoC has the same issue
<marex>
ja_02: can you ask them for /etc/os-release or similar from their box and recreate it in a virtual machine ?
<marex>
basically install their distro as of that state, and run the build in a VM, and see if the problem occurs ?
frieder has quit [Remote host closed the connection]
<marex>
"mkosi" tool might help with creating a container quickly
<ja_02>
kk
<ja_02>
i gtg but will update you on the issue
<marex>
good luck
<Tartarus>
Oh, marex's question about image size seems like a good possible answer and I see the various MAX_SIZE / SIZE_LIMIT options are still confusing and possibly confused in their configuration for socfpga
<Tartarus>
If the SPL text/data limit is ~56k then CONFIG_SPL_MAX_SIZE should be set to about that, and not zero (which means do not do this check)
<Tartarus>
And if you build in different paths for working vs non-working, there are some string literals that include the path
<Tartarus>
So another test with the can-fail compiler would be to move the sources to "/tmp/a" and build everything in-tree, in /tmp/a and see if it now works
<marex>
the string literal goo which pulled in __file__ should be fixed for a long time
ldevulder has quit [Ping timeout: 252 seconds]
<Tartarus>
Ah yes, true. Could just be different optimizations tripping up the second size limit
levitating has quit [Remote host closed the connection]
<Tartarus>
marex: Ugh, syncing with v6.15-dts blows up on r8a779g0_whitehawk_defconfig
<Tartarus>
I think because we end up with ./include/dt-bindings/media/video-interfaces.h and not ./dts/upstream/include/dt-bindings/media/video-interfaces.h
<Tartarus>
And so don't have MEDIA_BUS_CSI2_CPHY_LINE_ORDER_ABC etc defined
<Tartarus>
but oh good, we don't hvae any non-OF_UPSTREAM users
<Tartarus>
so I can nuke that binding and I'm just debugging this in chat ;)
<RoganDawes>
Unfortunately, it still doesn't recognise the NAND :-(
mmu_man has quit [Ping timeout: 252 seconds]
urja has quit [Quit: WeeChat 4.2.2]
urja has joined #u-boot
sbach has quit [Ping timeout: 252 seconds]
clamor has quit [Ping timeout: 276 seconds]
clamor has joined #u-boot
monstr has quit [Remote host closed the connection]
clamor has quit [Read error: Connection reset by peer]
zkrx has quit [Killed (NickServ (GHOST command used by zkrx_))]
zkrx has joined #u-boot
mmu_man has joined #u-boot
RoganDawes has quit [Ping timeout: 240 seconds]
vagrantc has joined #u-boot
mmu_man has quit [Ping timeout: 276 seconds]
sbach has joined #u-boot
jfsimon has quit [Quit: Leaving]
jfsimon has joined #u-boot
sbach has quit [Ping timeout: 265 seconds]
alperak has quit [Quit: Connection closed for inactivity]
gsz has joined #u-boot
gsz has quit [Ping timeout: 245 seconds]
ldevulder has joined #u-boot
mmu_man has joined #u-boot
goliath has joined #u-boot
mmu_man has quit [Ping timeout: 260 seconds]
mmu_man has joined #u-boot
Poltawer has quit [Quit: WeeChat 4.6.3]
sbach has joined #u-boot
<marex>
hum
goliath has quit [Quit: SIGSEGV]
naoki has joined #u-boot
sbach has quit [Ping timeout: 252 seconds]
ldevulder has quit [Quit: Leaving]
<Tartarus>
OK, so I can take us from 280 headers under include/dt-bindings down to 132 headers with just a little effort (done, posted the first half, testing the second half now)
<Tartarus>
Of that 132 there's 87 that's at least some effort to see if we can just drop our changes, or trivially adapt or what
<Tartarus>
The remainder are harder as they aren't upstreamed in their current state, and the first clock one I spot-checked is upstream only as of January of this year, and in a new header name and I didn't check if define names matched up
<Tartarus>
And that needs to be done in its own patch and cc'ing custodians
<Tartarus>
(Because now? Now there's dts files using those values and I need to spot check the dts files between us and kernel as I bet it's just a latent bug)
sbach has joined #u-boot
<marex>
Tartarus: if there is anything renesas that is dangling there, let me know