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: 268 seconds]
vagrantc has quit [Quit: leaving]
umbramalison_alt has quit [Quit: %So long and thanks for all the fish%]
umbramalison has joined #u-boot
<samueldr> hi, I screwed-up sending a patch, hadn't caught my mail client wrapped lines (ugh), and I can't find the patch submitting guidelines on the U-Boot website, were they removed?
<samueldr> so uh, I'm unsure what the correct way to resend the same patch, but fixing the sending methods so it isn't broken anymore
<samueldr> the kernel guidelines seem to imply RESEND is about resending an existing correct patch unchanged
<samueldr> the patch is "morally" unchanged, being the same set of changes, so increasing `vX` feels unneeded
cyrozap has quit [Remote host closed the connection]
aggi has quit [Ping timeout: 256 seconds]
jclsn has quit [Ping timeout: 248 seconds]
aggi has joined #u-boot
jclsn has joined #u-boot
<samueldr> sent as v3, not that I think it really matters that much to U-Boot people here
<tpw_rules> fwiw i did that once and sent it as v<N+1> but a mailing list member specifically pointed out it got mangled
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
Gravis has quit [Ping timeout: 252 seconds]
BenW_ has joined #u-boot
LeSpocky has quit [Ping timeout: 256 seconds]
LeSpocky has joined #u-boot
BWhitten has quit [Ping timeout: 268 seconds]
akaWolf has quit [Ping timeout: 256 seconds]
hanetzer has quit [Ping timeout: 248 seconds]
akaWolf has joined #u-boot
hanetzer has joined #u-boot
xroumegue has quit [Ping timeout: 268 seconds]
xroumegue has joined #u-boot
mrnuke has quit [Read error: Connection reset by peer]
GNUtoo has quit [Ping timeout: 268 seconds]
persmule has quit [Ping timeout: 268 seconds]
GNUtoo has joined #u-boot
persmule has joined #u-boot
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
Xeroine has joined #u-boot
MWelchUK2 has joined #u-boot
qsx has quit [Ping timeout: 256 seconds]
MWelchUK has quit [Ping timeout: 256 seconds]
MWelchUK2 is now known as MWelchUK
qsx has joined #u-boot
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
gsz has quit [Quit: leaving]
frieder has joined #u-boot
gsz has joined #u-boot
redbrain has quit [Read error: Connection reset by peer]
redbrain has joined #u-boot
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
camus1 has joined #u-boot
camus has quit [Ping timeout: 248 seconds]
camus1 is now known as camus
camus has quit [Remote host closed the connection]
camus has joined #u-boot
camus has quit [Ping timeout: 248 seconds]
camus has joined #u-boot
indy has quit [Ping timeout: 252 seconds]
camus has quit [Remote host closed the connection]
camus has joined #u-boot
indy has joined #u-boot
camus1 has joined #u-boot
camus has quit [Ping timeout: 248 seconds]
camus1 is now known as camus
apritzel__ has joined #u-boot
camus has quit [Remote host closed the connection]
camus has joined #u-boot
Gravis has joined #u-boot
Gravis has quit [Ping timeout: 256 seconds]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
prabhakarlad has joined #u-boot
stefanct has quit [Ping timeout: 252 seconds]
stefanct has joined #u-boot
BenW__ has joined #u-boot
BenW_ has quit [Ping timeout: 252 seconds]
persmule has quit [Remote host closed the connection]
<marex> Peng_Fan: I have an imx8mp board here which no longer boots since the imx93 DDR controller driver addition, is that known ?
persmule has joined #u-boot
<marex> sjg1: I think I have partly working flash.bin generation for imx8m, TBD
BenW_ has joined #u-boot
BenW__ has quit [Ping timeout: 268 seconds]
Gravis has joined #u-boot
persmule has quit [Quit: Leaving]
persmule has joined #u-boot
GNUtoo has quit [Remote host closed the connection]
indy has quit [Quit: ZNC 1.8.2 - https://znc.in]
<milkylainen> OT. Anyone here good at C openssl key handling questions? Tried #openssl. But that channel is completely dead. Question related to stm32 image signing.
GNUtoo has joined #u-boot
indy has joined #u-boot
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
camus has quit [Read error: Connection reset by peer]
camus has joined #u-boot
<hramrach> milkylainen: they have a mailinglist which is not completely dead
<milkylainen> hramrach: I think I've solved it. But thanks anyway. I had some issues understanding ec curve similarities and names.
<hramrach> when I tried to do signing I tried to massage the openssl tool to do it, and then found a perl reimplementation of Linux sign-file, and bent that slightly to do the requested format
<hramrach> because the openssl code iss worse than perl
<milkylainen> hramrach: I'm done with my stm32mp1-sign.c. I've tried it on hw.
<milkylainen> hramrach: Well. Everything beats closed source stm tools (cubeprogrammer)
<hramrach> good for you then
<milkylainen> :)
prabhakarlad has quit [Quit: Client closed]
apritzel__ is now known as apritzel
jagan has joined #u-boot
<marex> milkylainen: I'm quite sure closed source nxp tools (cst) are worse
torez has joined #u-boot
<milkylainen> marex: Maybe. But that's like having a torture preference. :P
___nick___ has joined #u-boot
prabhakarlad has joined #u-boot
jagan has quit [Quit: Connection closed]
Xeroine has quit [Quit: Leaving]
Gravis has quit [Ping timeout: 248 seconds]
Gravis has joined #u-boot
<sjg1> marex: Ah OK good. I haven't got back to your binman spl problem yet. Hopefully tomorrow or the weekend
Gravis has quit [Ping timeout: 248 seconds]
Gravis has joined #u-boot
vagrantc has joined #u-boot
jagan has joined #u-boot
frieder has quit [Remote host closed the connection]
adip has joined #u-boot
akaWolf has quit [Ping timeout: 248 seconds]
___nick___ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
___nick___ has joined #u-boot
apritzel has quit [Ping timeout: 248 seconds]
vagrantc has quit [Quit: leaving]
akaWolf has joined #u-boot
___nick___ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
___nick___ has joined #u-boot
aggi has quit [Quit: bbl]
jagan has quit [Ping timeout: 256 seconds]
vagrantc has joined #u-boot
thopiekar has joined #u-boot
GNUtoo has quit [Remote host closed the connection]
persmule has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
persmule has joined #u-boot
aggi has joined #u-boot
<vagrantc> hrm. both 2022.07 and 2022.10-rc2 seem to load a kernel just fine, but no nvme or mmc block devices show up once linux is booted. same exact configuration with 2022.04 seems to work.
<vagrantc> it may also have a different arm-trusted-firmware version...
<vagrantc> what sort of things cause those sorts of issues?
* vagrantc has a growing list of boards that do not work with u-boot 2022.04+ :/
<vagrantc> hmmm... also major toolchain differences between versions ...
mrnuke has joined #u-boot
___nick___ has quit [Ping timeout: 268 seconds]
mrnuke has quit [Quit: ZNC 1.8.2 - https://znc.in]
<marex> vagrantc: on which SoC ?
_whitelogger has joined #u-boot
mrnuke has joined #u-boot
<vagrantc> marex: pinebook-pro-rk3399 ... rockchip rk3399
<vagrantc> but another rk3288 as well ...
* vagrantc has been struggling to keep up
<hramrach> 3300 is sort of broken
<hramrach> 3399
<vagrantc> it's been working so well for so long :/
<hramrach> but for me mmc works in Linux but fails half of the time in u-boot
<hramrach> no nvme so can't say anything about that
<hramrach> yes, and expecially mmc fails in u-boot once Linux initializes it
<hramrach> missing it breaks i2c which breaks pmic which breaks Linux
<hramrach> and like the i2c does not come back even in Linux, have to reet the board
lucascastro has joined #u-boot
<vagrantc> "reet" ?
<vagrantc> reset?
aggi has quit [Quit: connection closed.]
lucascastro has quit [Ping timeout: 252 seconds]
torez has quit [Quit: torez]
adip has quit [Ping timeout: 252 seconds]
<hanetzer> so, in theory. if I have full proper jtag and serial for a device, the 'ideal' mechanism would be loading spl into sram and executing it to init dram (doing whatever dev is needed to make that work) and loading u-boot proper into dram after that?
<marex> yes
<hanetzer> as my serial adapter is kaput (shitty header broke off the cable, waiting on some non-shit replacements to arrive tomorrow) I'm mostly flying blind atm
<marex> hanetzer: time to buy soldering iron and start fixing all the broken hardware ? :)
<hanetzer> I already own one :P
<marex> it might take less time and save money ;-)
<hanetzer> its just a tiny ass picoblade connector
<hanetzer> that said, re: the openocd/jtag proc, is there any 'official' guide on that so I'm not fumbling too hard?
* vagrantc is tempted to just solder all the boards together indiscriminently and be done with all the things :)
* vagrantc just found an old board that has been running for years doing nothing
<marex> vagrantc: toss them into a can of molten tin no less ?
<marex> like the end scene of terminator 2 ... heh
<marex> hanetzer: official guide, well ... $ openocd -s tcl -f tcl/interface/ftdi/flyswatter2.cfg -f tcl/target/something.cfg -c "adapter speed 10000" -c "reset_config trst_and_srst" -c "jtag_ntrst_delay 20"
<marex> and then telnet into it
<cambrian_invader> hanetzer: try semihosted serial
<cambrian_invader> if you have jtag
<cambrian_invader> it's slow but better than nothing
<marex> cambrian_invader: is that the arm dcc ?
<cambrian_invader> not sure what dcc is
<marex> drivers/serial/arm_dcc.c
<cambrian_invader> no
<cambrian_invader> similar idea
<cambrian_invader> marex: drivers/serial/serial_semihosting.c and arch/arm/lib/semihosting.c
<hanetzer> cambrian_invader: exactly what is semihosted serial? what I'm getting out of it is that it can do uart over jtag in a sense?
<cambrian_invader> the idea is that you trigger a special debug breakpoint
<cambrian_invader> and then the debugger examines the registers and performs some action on your behalf
<marex> yikes
<marex> I see
<marex> is that like SMP-safe version of DCC ?
<cambrian_invader> marex: the yikes part is that common debuggers (openocd in particular) let you read/write any file you want
<cambrian_invader> which is both very convenient, and concerning as well
<cambrian_invader> idk if it's SMP safe
<cambrian_invader> I suppose that depends on your debugger
<marex> DCC sure is not, since the DCC coprocessor register is per-core, which sucks
<marex> at least in Linux, in U-Boot its fine
<marex> the semihosting is interesting
<marex> cambrian_invader: so how do you actually attach to such semihosted serial with openocd ?
<cambrian_invader> marex: doc/usage/semihosting.rst and for a specific example doc/board/nxp/ls1046ardb.rst
* hanetzer notes notes notes
<marex> cambrian_invader: that is real nice
<hanetzer> hrm. food?
<cambrian_invader> thanks
<hanetzer> now if I could just get the gdb+svd file integration to work that'd be great
vagrantc has quit [Quit: leaving]
<marex> sjg1: does binman section not support any sort of padding/alignment/anything ?
<marex> sjg1: it's like ... I have this u-boot-spl { align-end = <1024>; }; and it pastes the next item right at the end, at unaligned address no less
<marex> no alignment to 1024 bytes, ignored
mmu_man has joined #u-boot
vagrantc has joined #u-boot
<sjg1> Marex: can you check the tests? Find the align-end one and see what it does. I am afk until tomorrow