Tartarus changed the topic of #u-boot to: SOURCE MOVED TO https://source.denx.de/u-boot/u-boot.git / U-Boot v2022.07 is OUT / Merge Window is OPEN, -next is CLOSED / Release v2022.10 is scheduled for 3 October 2022 / http://www.denx.de/wiki/U-Boot / Channel archives at https://libera.irclog.whitequark.org/u-boot
mmu_man has quit [Ping timeout: 240 seconds]
rfs613- is now known as rfs613
xenador77 has joined #u-boot
thopiekar_ has joined #u-boot
thopiekar has quit [Ping timeout: 268 seconds]
GNUtoo_ has joined #u-boot
GNUtoo has quit [Ping timeout: 268 seconds]
LeSpocky has quit [Ping timeout: 245 seconds]
LeSpocky has joined #u-boot
Guest31 has joined #u-boot
Guest31 has quit [Quit: Client closed]
akaWolf has quit [Ping timeout: 240 seconds]
akaWolf has joined #u-boot
thopiekar_ has quit [Ping timeout: 240 seconds]
thopiekar has joined #u-boot
vagrantc has joined #u-boot
sigmaris has quit [Read error: Connection reset by peer]
sigmaris has joined #u-boot
vagrantc has quit [Quit: leaving]
guillaume_g has joined #u-boot
rvalue has quit [Remote host closed the connection]
rvalue has joined #u-boot
GNUtoo_ has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
mmu_man has joined #u-boot
gsz has joined #u-boot
mmu_man has quit [Ping timeout: 268 seconds]
mmu_man has joined #u-boot
jclsn has joined #u-boot
<jclsn> Is there a good documentation on how to write U-Boot drivers somewhere?
<jclsn> Looking at the driver model on https://u-boot.readthedocs.io/en/latest/api/dm.html
<jclsn> Looking for something more beginner-friendly though
matthias_bgg has quit [Ping timeout: 268 seconds]
mmu_man has quit [Ping timeout: 268 seconds]
xenador77 has quit [Remote host closed the connection]
xenador77 has joined #u-boot
xenador77 has quit [Remote host closed the connection]
xenador77 has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
mmu_man has joined #u-boot
prabhakarlad has joined #u-boot
<jclsn> Ah well guess I have to start small
<jclsn> Trying to build the sanboxed U-Boot, but I can't find a u-boot binary
<jclsn> hmm maybe because it is uboot-imx?
jclsn has quit [Quit: WeeChat 3.5]
<mps> it should be just named 'u-boot' binary
jclsn has joined #u-boot
xenador77 has quit [Remote host closed the connection]
<mps> hmm, what is difference between sandbox64_defconfig and sandbox_defconfig
<jclsn> mps: None really. Also no binary
<mps> hmm, make sandbox_defconfig ; make works always for me
<jclsn> Maybe because it is uboot-imx... I am actually trying to debug my driver, but also #define DEBUG doesn't work
<mps> jeeebz: ah, you don't use u-boot mainline tree?
<jclsn> No, the NXP version
<jclsn> It is lagging a bit behind
<jclsn> It shouldn't be different in that regard though
<mps> idk, but from experience downstream only cares for their part
<jclsn> Yeah the freescale version builds the binary
<jclsn> Great
<jclsn> As in not great
davlefou has quit [Ping timeout: 244 seconds]
<Tartarus> xypron: Does EFI_LOADER on armv7-m make sense?
davlefou has joined #u-boot
<jclsn> I am really starting to hate the proprietary BSPs
<jclsn> If at least NXP would fix their forum, but no
<jclsn> Okay woosah
<Tartarus> or armv7-r
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
torez has joined #u-boot
lucascastro has joined #u-boot
mmu_man has quit [Ping timeout: 252 seconds]
monstr has joined #u-boot
<LeSpocky> what do I have to tell buildman to fetch a toolchain for sandbox?
<LeSpocky> or what arch is sandbox? i could not find out from defconfig
<Tartarus> Well, sandbox can just be your regular host toolchain
<Tartarus> For CI we force it to use the x86 one, for consistency
<LeSpocky> makes sense, but buildman tells me it has no toolchain for sandbox
<LeSpocky> at least that's what's written in output dir current/sandbox/err
<Tartarus> That's odd
<Tartarus> What does tools/buildman/buildman --list-tool-chains say?
<Tartarus> For me I eventually see:
<Tartarus> sandbox : /usr/bin/gcc
<LeSpocky> (I'm on master)
<LeSpocky> in that list I have 5 entries for aarch64, arm, m68k, mips, and xtensa, but none for sandbox
<Tartarus> And, uh, you do have /usr/bin/gcc ? What's your host arch, and also what's your ~/.buldman look like?
<Tartarus> You may need:
<Tartarus> [toolchain]
<Tartarus> host = /usr
<Tartarus> up top, in ~/.buildman
<LeSpocky> /usr/bin/gcc is a symlink to gcc-8. this is Debian GNU/Linux 10 (buster) on amd64
<LeSpocky> adding that host entry leads to some more entries when calling buildman with --list-tool-chains
<LeSpocky> nice
mmu_man has joined #u-boot
<LeSpocky> Tartarus: okay, building something now, I can work with that, thank you
prabhakarlad has joined #u-boot
mmu_man has quit [Ping timeout: 268 seconds]
jclsn has quit [Ping timeout: 268 seconds]
jclsn has joined #u-boot
jclsn has quit [Client Quit]
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
mmu_man has joined #u-boot
vagrantc has joined #u-boot
Xeroine has joined #u-boot
dsmith-work has quit [Remote host closed the connection]
GNUtoo has quit [Ping timeout: 268 seconds]
GNUtoo has joined #u-boot
lucascastro has quit [Quit: Leaving]
GNUtoo has quit [Remote host closed the connection]
sam_sepi0l has joined #u-boot
GNUtoo has joined #u-boot
torez has quit [Quit: torez]
jsmolic has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
jsmolic has joined #u-boot
lvrp16 has quit [Quit: Updating details, brb]
lvrp16 has joined #u-boot
tchebb has quit [Ping timeout: 268 seconds]
<par[m]> Guys!
<par[m]> Now here's the deal: the NXP memory utility doesn't produce a correct output with ANY configuration. Does that mean a memory chip is bad? Using a single 16 Gbits chip instead of 2x8Gbits.
<par[m]> Say i have a custom iMX8MM board; don't know whether it works properly or not, uboot fails during ram initialization.
<par[m]> Thanks in advance!
<par[m]> * Guys!
<par[m]> Say i have a custom iMX8MM board; don't know whether it works properly or not, uboot fails during ram initialization.
<par[m]> Now here's the deal: the NXP memory utility doesn't produce a correct output or anything at all using ANY configuration. Does that mean a memory chip is bad? Using a single 16 Gbits chip instead of 2x8Gbits.
<par[m]> * Guys!
<par[m]> Say i have a custom iMX8MM board; don't know whether it works properly or not, uboot fails during ram initialization.
<par[m]> Now here's the deal: the NXP memory utility doesn't produce a correct output or anything at all using ANY configuration. Does that mean a memory chip is bad/dead? Using a single 16 Gbits chip instead of 2x8Gbits.
<Tartarus> Well, if you can't convince the memory configuration tool to give the correct output, yeah, u-boot isn't gonna work either
<Tartarus> Just how tricky that tool is to configure / use, I can't say, but yes, I would step back and verify the basics about the design
<Tartarus> and make sure the hardware matches the schematic, etc
Xeroine has quit [Ping timeout: 268 seconds]
monstr has quit [Remote host closed the connection]
lucascastro has joined #u-boot
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
<xypron> Tartarus: I don't know if there are armv7-m to run a full Linux distro.
lucas_ has joined #u-boot
lucascastro has quit [Ping timeout: 252 seconds]
bigendian has quit [Changing host]
bigendian has joined #u-boot
BWhitten has joined #u-boot
<Tartarus> xypron: What about r? That one also claims to be SYS_CPU = "armv7"
<xypron> Tartarus Where do you see a problem with current U-Boot?
mmu_man has quit [Ping timeout: 240 seconds]
<Tartarus> xypron: Well, the "problem" is that configs/*_r5_defconfig pulls in EFI_LOADER, which doesn't make any sense for the non-xilinx board, I don't know the xilinx one well enough to say if it could be used there
<Tartarus> Or if they aren't pulling it in today, they do once DM_ETH is enabled and so EFI_LOADER is unblocked there
guillaume_g has quit [Quit: Konversation terminated!]
mmu_man has joined #u-boot
Guest4494 has joined #u-boot
<xypron> Tartarus All ARMv7-R lack a mmu. So you cannot run a normal Linux distro on them. So EFI_LOADER can be disabled by default on them.
<Tartarus> xypron: OK, I _think_ we should change from checking SYS_CPU = foo to CPU_FOO being enabled, and not enable for CPU_V7R
lucas_ has quit [Quit: Leaving]
lucascastro has joined #u-boot
sbach has quit [Read error: Connection reset by peer]
sbach has joined #u-boot
xenador77 has joined #u-boot
gsz has quit [Quit: leaving]
GNUtoo has quit [Ping timeout: 268 seconds]
hanetzer has quit [Ping timeout: 252 seconds]
hanetzer has joined #u-boot
GNUtoo has joined #u-boot
xenador77 has quit [Remote host closed the connection]
Guest4494 has quit [Ping timeout: 252 seconds]
xenador77 has joined #u-boot
hanetzer has quit [Read error: Connection reset by peer]
BWhitten has quit [Remote host closed the connection]
DrPatater has quit [Ping timeout: 240 seconds]
hanetzer has joined #u-boot
ldevulder_ has joined #u-boot
ldevulder has quit [Ping timeout: 244 seconds]
xenador77 has quit [Ping timeout: 252 seconds]
Patater has joined #u-boot
DrPatater has joined #u-boot
Patater has quit [Ping timeout: 252 seconds]
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
<xypron> Tartarus: Is SPL_SYS_NO_VECTOR_TABLE on your agenda for conversion to CONFIG? Why do we have this symbol separate from ARMV8_SPL_EXCEPTION_VECTORS while both have the same meaning (except for inverse logic). I think there should be only one Kconfig symbol.
<Tartarus> Is already converted?
<xypron> Tartarus: Not really, you cannot edit it.
<xypron> And it is duplicate to the arm64 symbol
jybz has joined #u-boot
jeeebz has quit [Read error: Connection reset by peer]