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
WoC has quit [Remote host closed the connection]
mthall has quit [Ping timeout: 252 seconds]
mthall has joined #u-boot
mthall has quit [Ping timeout: 268 seconds]
mthall has joined #u-boot
minimal has quit [Quit: Leaving]
thopiekar has quit [Ping timeout: 264 seconds]
thopiekar has joined #u-boot
Gravis has quit [Ping timeout: 252 seconds]
Gravis has joined #u-boot
mmu_man has quit [Ping timeout: 268 seconds]
matthias_bgg has quit [Ping timeout: 246 seconds]
alan_o has quit [Remote host closed the connection]
vagrantc has joined #u-boot
matthias_bgg has joined #u-boot
LeSpocky has quit [Ping timeout: 264 seconds]
LeSpocky has joined #u-boot
vagrantc has quit [Quit: leaving]
rabbi[11] has quit [Ping timeout: 252 seconds]
matthias_bgg has quit [Ping timeout: 252 seconds]
redbrain has quit [Read error: Connection reset by peer]
redbrain has joined #u-boot
matthias_bgg has joined #u-boot
gsz has joined #u-boot
guillaume_g has joined #u-boot
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
mncheck has joined #u-boot
mckoan|away is now known as mckoan
rvalue has quit [Ping timeout: 246 seconds]
hanetzer has quit [Quit: WeeChat 3.6]
m5zs7k has quit [Ping timeout: 268 seconds]
m5zs7k has joined #u-boot
sszy has joined #u-boot
ldevulder has joined #u-boot
matthias_bgg has quit [Ping timeout: 268 seconds]
apritzel_ has joined #u-boot
monstr has joined #u-boot
jagan has quit [Ping timeout: 268 seconds]
rvalue has joined #u-boot
matthias_bgg has joined #u-boot
sbach has quit [Read error: Connection reset by peer]
sbach has joined #u-boot
mmu_man has joined #u-boot
mckoan is now known as mckoan|away
tnovotny has joined #u-boot
jagan has joined #u-boot
torez has joined #u-boot
thopiekar has quit [Quit: Likely restarting quassel...]
mmu_man has quit [Ping timeout: 252 seconds]
thopiekar has joined #u-boot
gsz has quit [Quit: leaving]
xroumegue has quit [Ping timeout: 246 seconds]
xroumegue has joined #u-boot
WoC has joined #u-boot
tnovotny has quit [Quit: Leaving]
<sjg1> Tartarus: Hi Tom, I'd like to pull this into -next - WDYT? https://patchwork.ozlabs.org/project/uboot/list/?series=317187
<sjg1> Tartarus: It is a dm series but I see it is assigned to you in patchwork
mmu_man has joined #u-boot
hanetzer has joined #u-boot
<Tartarus> sjg1: Yeah, OK, lemme re-check it real quick
<Tartarus> I'll pick it up for next later today
<Tartarus> It's a big enough thing I want to put it in a branch, pull, and then put most of the cover letter in the merge commit message
mmu_man has quit [Ping timeout: 250 seconds]
<MWelchUK> sjg1: Was v3 of the MSC SM2S iMX8MP support series more acceptable (switched to DM)?
vitali64 has joined #u-boot
<LeSpocky> fyi: building sandbox_defconfig on i386 host fails with CONFIG_CLK_K210
guillaume_g has quit [Quit: Konversation terminated!]
<cambrian_invader> LeSpocky: what's the error
<cambrian_invader> and maybe that should be gated behind a 64-bit config
vagrantc has joined #u-boot
<LeSpocky> cambrian_invader: the console log is 200k because of over and over repeated errors in some macros, I have to find some place to put it, give me a minute
sszy has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
<cambrian_invader> yeah, that definitely should be gated behind PHYS_64BIT
rburkholder has quit [Remote host closed the connection]
<vitali64> clever: o/
<clever> gd: 07fff9e0, gd->bd: ffb65fb0
<vitali64> ^ This explains why we're here.
<clever> gd is just below 128mb, gd->bd is just past 4091mb into ram
<vitali64> But we only have 64MB of ram available.
<clever> but gd->ram_size declares that there is only 64mb starting at 0
<vitali64> Hence, write fails and u-boot thinks we have 0 bytes.
<clever> yep, when dram_init_banksize() tries to write the memory banks, its writing to an unmapped physical address
<vitali64> Yep.
<clever> so when it reads it back later, garbage!
<clever> anybody have a clue as to why gd->bd isnt initialized, and why gd is so high up in ram?
<vitali64> We're using a Pi2 w/ a custom firmware, if that helps.
<cambrian_invader> gd is placed above the stack, so it depends on whatever your default stack placement is
<clever> cambrian_invader: what about gd->bd ?
<clever> and i gotta run, groceries and stuff
<cambrian_invader> idk
vitali64[m] has joined #u-boot
<vitali64> vitali64[m] is here for chat logs.
<clever> cambrian_invader: i see a spl_set_bd and dram_init_banksize, within board_init_r
<clever> but dram_init_banksize is also within init_sequence_f
<clever> f is before r?
<clever> so gd->bd hasnt been set yet?
<clever> i cant see how this ever worked
<vitali64> If so, why is dram_init_banksize trying to write to those?
<vitali64> Something is really really wrong.
<sjg1> Tartarus: sounds good. Yes it fixes a long-standing with ofnode - I expect some comments once people see it
<vitali64> Because u-boot also continuously prints strings with no meaning.
<vitali64> Like those:
<vitali64> led. **
<vitali64> splled. **
<vitali64> spl
<sjg1> MWelchUK: I don't remember the problem. Was I asking for the address to be in the device tree?
<cambrian_invader> yes, f is before r
mmu_man has joined #u-boot
jagan has quit [Ping timeout: 268 seconds]
apritzel_ has quit [Ping timeout: 265 seconds]
<ric342[m]> does c201 veyron-speedy work on any bsd yet?
<MWelchUK> sjg1: Originally I'd tried to add legacy support for the rn5t567: https://lore.kernel.org/u-boot/CAPnjgZ0VZesnBtqJJ6HQLzM1cz8Q=yJ6WP3G_TXdFB11wGMSjQ@mail.gmail.com/
<sjg1> MWelchUK: Oh I see. Yes that is fine. Sometime we need to add a deadline and warning about PMIC migration. It should be a one-line change - see Makefile around line 1167 if you are able to do a patch
thopiekar has quit [Ping timeout: 268 seconds]
thopiekar has joined #u-boot
monstr has quit [Remote host closed the connection]
thopiekar has quit [Ping timeout: 264 seconds]
mmu_man has quit [Ping timeout: 252 seconds]
thopiekar has joined #u-boot
<clever> common/board_f.c: gd->bd = (struct bd_info *)map_sysmem(gd->start_addr_sp,
<clever> common/spl/spl.c: gd->bd = &bdata;
<clever> cambrian_invader: aha, bd is setup in 2 places
<clever> reserve_board() creates it, if it hasnt been set yet
WoC has quit [Remote host closed the connection]
WoC has joined #u-boot
<clever> cambrian_invader: is gd zero'd before use? where exactly is the code to allocate it?
rabbi[11] has joined #u-boot
ladis has joined #u-boot
vitali64 has quit [Quit: Lost terminal]
macromorgan has quit [Remote host closed the connection]
macromorgan has joined #u-boot
macromorgan has quit [Remote host closed the connection]
macromorgan has joined #u-boot
<cambrian_invader> clever: should be in start.S for your arch
* clever reads arch/arm/cpu/armv7/start.S
<clever> that grabs either CONFIG_SPL_STACK or SYS_INIT_SP_ADDR for the sp, but i dont see a clear gd answer
<clever> and then runs _main from crt0.S
rburkholder has joined #u-boot
mmu_man has joined #u-boot
<clever> crt0.S does say it has to allocate gd
<cambrian_invader> board_init_f_init_reserve
<clever> yep, that zeros it out
<clever> so i would assume gd->bd was null
<clever> reserve_board() then allocates gd->bd with map_sysmem(), only if it was null
<clever> and a later printf, said that bd was ffb65fb0
<clever> and with only a 30bit addr space, thats definitely invalid
<clever> i'm surprised it isnt faulting out, we are able to write to gd->bd->bi_dram[0].size and then read it back
<clever> but reads dont return the data written
alan_o has joined #u-boot
matthias_bgg has quit [Ping timeout: 268 seconds]
mncheck has quit [Ping timeout: 264 seconds]
<sjg1> Hi, I sent a schema update for the U-Boot driver model tags: https://patchwork.ozlabs.org/project/uboot/patch/20220929195804.2773808-1-sjg@chromium.org/
macromorgan has quit [Remote host closed the connection]
macromorgan has joined #u-boot
matthias_bgg has joined #u-boot
<LeSpocky> so running sandbox u-boot on i386 (built on the same host) segfaults *grml*
<LeSpocky> (currently working on an old Samsung NC10 laptop with Intel Atom N270 CPU)
<LeSpocky> running with gdb gives this:
<LeSpocky> 0x0053b2e8 in strcmp (cs=0x65a395 "test_drv", ct=0x1 <error: Cannot access memory at address 0x1>) at /home/alex/src/u-boot/lib/string.c:214
<LeSpocky> but I won't investigate this today anymore
<LeSpocky> good night everyone
macromorgan has quit [Read error: Connection reset by peer]
Net147_ has quit [Quit: Quit]
Net147 has joined #u-boot
Net147 has joined #u-boot
Net147 has quit [Changing host]
macromorgan has joined #u-boot
matthias_bgg has quit [Quit: Leaving]
ladis has quit [Quit: Leaving]
torez has quit [Quit: torez]
vagrantc has quit [Quit: leaving]
tlwoerner has quit [Read error: Connection reset by peer]
tlwoerner has joined #u-boot
<sjg1> LeSpocky: perhaps get a stack trace?