redbrain has quit [Read error: Connection reset by peer]
redbrain has joined #u-boot
flyback has quit [Read error: Connection reset by peer]
mncheck has quit [Ping timeout: 268 seconds]
flyback has joined #u-boot
<hays>
Is there any possibility u-boot might do something to an MMC interface to cause it to report as "busy" during kernel boot up?
<hays>
and is there any command that might reset the interface I could run
vagrantc has quit [Quit: leaving]
apritzel_ has quit [Ping timeout: 255 seconds]
mmu_man has quit [Ping timeout: 252 seconds]
<hanetzer>
hey, does u-boot support any form of serial-over-lan/netconsole for early bootup?
Leopold has quit [Quit: No Ping reply in 180 seconds.]
Leopold has joined #u-boot
Leopold_ has joined #u-boot
Leopold has quit [Ping timeout: 255 seconds]
thopiekar has quit [Ping timeout: 246 seconds]
thopiekar has joined #u-boot
naoki has quit [Ping timeout: 268 seconds]
darkapex_ has joined #u-boot
darkapex_ has quit [Client Quit]
<hays>
chatgpt says I can do this to release the mmc1 possibly mmc dev 1 && mmc rescan
<marex>
hays: eMMC or SD ?
<hays>
marex: SD
<marex>
latest upstream U-Boot should put eMMC into HS mode before starting Linux
<marex>
SD should be more resilient than eMMC
<marex>
check clock, pinmux, the usual
<hays>
sadly this is an old u-boot for a stupid vendor so don't spend too much time trying to fix--but just trying to find workarounds to what looks like a "busy" sd card during initramfs
<marex>
pull the card out and reinsert ?
<hays>
haha I actually did try that
<marex>
still dead ?
<marex>
check clock, pinmux, the usual
<hays>
it might be interesting to try to time it better
<marex>
on Linux side
<hays>
I have been trhough the dtb, the kernel... almost same kernel boots another image
<hays>
but they do have a different and probably more fancy init system (systemd) whereas I have just extlinux and initrd with ash script
<marex>
do you use 'rootwait' bootargs ?
<hays>
There are in the kcmdline...
<marex>
check the boot log , the kernel prints its kernel command line
<hays>
hmm i wonder how early. freaking earlycon isn't working let me look ive got the dmesg
<hanetzer>
marex: nice. I'll have to look into that, assuming I can't find a proper uart
<hays>
actually I think that's uboot printing the args
<hays>
i don't have the kernel captured because im getting it 7.62 seconds in
<hanetzer>
on that note. if anyone here can obtain a datasheet for the rtl8117, as present on the asus pro ws x570-ace or asus pro ws w480-ace, I'd appreciate it.
<hays>
marex: is there a way to get u-boot to spit out its 'default environment' to a file for a given board configuration?
<hays>
or any suggestions how one might inspect it
torez has joined #u-boot
<marex>
hanetzer: also look at Forty-Bot FOSDEM talk about semihosting
<hanetzer>
I think that's only good if you have jtag yeh?
<Forty-Bot>
yea
<hanetzer>
(btw, this is a mips-ish soc)
<hanetzer>
it functions as a sort-of bmc on the above mentioned x570 motherboard
<hanetzer>
anywho, I gotta do a thing, bbl
hanetzer has quit [Quit: WeeChat 3.8]
<Forty-Bot>
iirc mips has its own varient of semihosting which we don't support
<hays>
ugh. Any possibility anyone remembers how to give u-boot an environment at compile time for a 2017 uboot?
<hays>
can't seem to find documentation
<hays>
i tried putting an .env file in board/$vendor/$board/$board.env
<Forty-Bot>
that's new
<Forty-Bot>
I think
<hays>
picking through the default environment .h files is ... something
<Forty-Bot>
try editing the header in include/configs/
<marex>
yeah, that
<hays>
ok. found what its launching to boot... sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}extlinux/extlinux.conf
<hays>
unfortunately I think sysboot is back into the C source code so any workaround would be in there
<hays>
ups the difficulty level for me a bit :)
<hays>
cmd/pxe.c looks like
<marex>
so yeah, it sources extlinux for command line and kernel path
<hays>
it seems to return 0; after loading all that stuff
<marex>
hays: it likely goes back to the higher up script
<hays>
the higher up script expects it not to come back
<hays>
the next line is: echo SCRIPT FAILED: continuing...;
<hays>
oh wait. copy paste error
<hays>
oh no.. nevermind... yes. that's right
<hays>
hmm. I think this boots the system "handle_pxe_menu"
naoki has joined #u-boot
<marex>
oh, yeah ... should be EXTLINUX FAILED really, that's already fixed upstream
<marex>
so it failed to use extlinux.conf
<marex>
hays: are you using extlinux.conf ?
<hays>
marex: yes. Ive picked through the code and im at do_bootm
<hays>
trying to find.. and I probably won't succeed..where everything is loaded from the partition and I can insert something to reset the mmc controller
<hays>
this is all based on a theory that maybe u-boot has left the controller in a state where linux can't read from it.
<marex>
include/config_distro_bootcmd.h
<marex>
that should be the logic
<hays>
yep i started there
<hays>
that file leads you to sysboot and do_sysboot() in the source code
<hays>
then I think: handle_pxe_menu, boot_unattempted_labels (probably), label_boot, do_bootm
<hays>
all inside the .c source
<hays>
basically sysboot is going to boot if it can--if it exits it indicates that it failed
<hays>
essentially I can't reset the controller with a script command. I think I have to do it in the .c source somewhere
<hays>
getting late here thanks for the help I know its an unsupported version so I appreciate it
<hays>
I think I found something I might be able to do on the linux side.
prabhakarlad has quit [Ping timeout: 260 seconds]
advi[1] has quit [Ping timeout: 260 seconds]
ikarso has joined #u-boot
goliath has joined #u-boot
Michael23 has joined #u-boot
apritzel_ has joined #u-boot
apritzel_ has quit [Ping timeout: 255 seconds]
goliath has quit [Quit: SIGSEGV]
mncheckm has joined #u-boot
mmu_man has joined #u-boot
guillaume_g has joined #u-boot
ldevulder has quit [Remote host closed the connection]
<mwalle>
marex: do you have any idea why it should be the mtd subsystem for this fpga config thingy? it looks like he want a propert altera-passive-serial driver really (which uses the spi subsystem)
mmu_man has quit [Ping timeout: 255 seconds]
Leopold has quit [Remote host closed the connection]
torez has quit [Remote host closed the connection]
<apalos>
sjg1: no problem, I probably lost that apologies
torez has joined #u-boot
torez has quit [Client Quit]
torez has joined #u-boot
Michael23 has quit [Quit: Client closed]
<apalos>
sjg1: looking at this now,
<apalos>
this seems to be cr50 specific
<apalos>
I remember us discussing this in the past
<apalos>
why dont you just define this in the cr50 driver?
<apalos>
IIRC you dont even use it in u-boot right?
alpernebbi has quit [Ping timeout: 252 seconds]
<apalos>
I think you said some code you have internally does use it only
<apalos>
I'll reply on the patch
<sjg1>
OK. All of the calls to tpm_sendrecv_command() are in lib/tpm so it would be odd to try to work around that. Even though this is an extension, it is a tpm2 call
<sjg1>
In fact tpm_sendrecv_command() is not available to the driver (with good reason!)
zibolo_ is now known as zibolo
alpernebbi has joined #u-boot
<apalos>
I remember us having a discussion on solcing that as well, but I cant remember the details
<apalos>
I'll run some tests and send it if it passes
mmu_man has quit [Ping timeout: 255 seconds]
<mwalle>
marex: it looks like he should give the UCLASS_FPGA in u-boot a spring cleaing but its too much work.. so just shoving that into the mtd subsystem is easier/faster
<marex>
mwalle: easier/faster ... and poorly maintainable in the long run, and plain wrong because it is the wrong subsystem, so not happening
<marex>
mwalle: I agree UCLASS_FPGA needs a lot of work
monstr has quit [Remote host closed the connection]
ldevulder has quit [Remote host closed the connection]
ldevulder has joined #u-boot
GNUtoo__ has joined #u-boot
guillaume_g has quit [Quit: Konversation terminated!]
macromorgan_ has joined #u-boot
macromorgan is now known as Guest3373
Guest3373 has quit [Killed (tantalum.libera.chat (Nickname regained by services))]
macromorgan_ is now known as macromorgan
goliath has joined #u-boot
d-s-e has quit [Quit: Konversation terminated!]
vagrantc has joined #u-boot
Leopold_ has joined #u-boot
Leopold has quit [Ping timeout: 255 seconds]
apritzel has quit [Ping timeout: 255 seconds]
persmule has quit [Remote host closed the connection]
GNUtoo__ has quit [Remote host closed the connection]
persmule has joined #u-boot
GNUtoo___ has joined #u-boot
frieder has quit [Remote host closed the connection]
<sjg1>
apalos: LGTM
goliath has quit [Quit: SIGSEGV]
<apalos>
sjg1: tests did pass as well, so it's looks good
<apalos>
I have an internal CI that tests TPM changes with a qemu instance, once that passes i'll queue them up
goliath has joined #u-boot
ikarso has quit [Quit: Connection closed for inactivity]
Pali has joined #u-boot
<Pali>
Hello! I cannot send patches to ML, seems that denx has broken mail server.
<Pali>
Emails bounces back with error message: <u-boot@lists.denx.de>: Command died with status 254: "/usr/local/bin/spamfilter.sh". Command output: /usr/local/bin/spamfilter.sh: fork: retry: Resource temporarily unavailable
apritzel_ has joined #u-boot
Leopold has joined #u-boot
Leopold_ has quit [Ping timeout: 252 seconds]
<Pali>
Can somebody look at this issue?
ldevulder has quit [Quit: Leaving]
<Pali>
Mail server which sends bounces is phobos.denx.de.
<cambrian_invader>
Pali: try emailing Harald Seiler <hws@denx.de>
<Pali>
That mailbox is on the same mail server, right?
<cambrian_invader>
hm, I suppose
<cambrian_invader>
that's who trini forwarded my message to the last time I had mail trouble with the list
naoki has joined #u-boot
thopiekar has quit [Ping timeout: 255 seconds]
thopiekar has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
<Tartarus>
Pali: It happens on occasion when the server gets overloaded
<Tartarus>
Resend should be fine
torez has quit [Quit: torez]
ccf has quit [Quit: Leaving.]
<Pali>
Mail server returns Status 5.3.0
<Pali>
Cannot you change to return some status 4.x.x?
<Pali>
And resend would work automatically.
<Tartarus>
I have no control over the denx infrastructure, talk with Harald
<Tartarus>
I know from the last time someone noted that failure, it's transient