ikarso has quit [Quit: Connection closed for inactivity]
baltazar has quit [Ping timeout: 252 seconds]
baltazar has joined #u-boot
jclsn has quit [Ping timeout: 272 seconds]
jclsn has joined #u-boot
frytaped has joined #u-boot
mmu_man has quit [Ping timeout: 272 seconds]
flyback has quit [Quit: Leaving]
flyback has joined #u-boot
<shadow>
so... I sent e-mail to Jerome about the logic errors in LwIP stack and await a reply
<shadow>
anyone else that wants to assist I would like to be proactive about this before the next release candidate
goliath has joined #u-boot
johnfergus has joined #u-boot
vardhan has joined #u-boot
vardhan_ has joined #u-boot
vardhan has quit [Remote host closed the connection]
vardhan has joined #u-boot
monstr has joined #u-boot
gsz has joined #u-boot
johnfergus has quit [Remote host closed the connection]
gsz has quit [Ping timeout: 265 seconds]
ldevulder has joined #u-boot
ladis has joined #u-boot
ikarso has joined #u-boot
frieder has joined #u-boot
vardhan has quit [Ping timeout: 252 seconds]
vardhan_ has quit [Ping timeout: 246 seconds]
dsimic has quit [Ping timeout: 244 seconds]
ldevulder has quit [Quit: Leaving]
dsimic has joined #u-boot
sszy has joined #u-boot
ldevulder has joined #u-boot
tlwoerner has quit [Quit: Leaving]
tlwoerner has joined #u-boot
naoki has quit [Ping timeout: 272 seconds]
naoki has joined #u-boot
naoki has quit [Ping timeout: 244 seconds]
naoki has joined #u-boot
naoki has quit [Read error: Connection reset by peer]
naoki has joined #u-boot
mckoan|away is now known as mckoan
SlimeyX_ has joined #u-boot
SlimeyX has quit [Ping timeout: 252 seconds]
SlimeyX_ is now known as SlimeyX
ldevulder has quit [Quit: Leaving]
ldevulder has joined #u-boot
<Hammdist>
Image 'simple-bin' has faked external blobs and is non-functional: rk3588_ddr_lp4_2112MHz_lp5_2400MHz_v1.18.bin <-- how to fix this error? I am trying to build orangepi-5-rk3588s
<Hammdist>
https://pastebin.com/raw/TENYa656 <-- why does this Dockerfile attempting to build u-boot not work? it builds OK but after flashing no u-boot on serial output
<Hammdist>
also I'm not clear on how to choose between the two available ddrbins for opi5
<Hammdist>
now I'm compiling u-boot with stdout-path = "serial2:115200n8"; but output is garbed even though I put screen on 115200 baud
<Hammdist>
judging by the volume of output it seems to be booting into u-boot now though. just not sure about the baud rate. is that actually even configurable
<Hammdist>
partition 1 contains a boot.scr thing. am I supposed to load and run that? how would I do that?
joeskb7 has joined #u-boot
monstr has quit [Remote host closed the connection]
redbrain has joined #u-boot
<Tartarus>
Anyone here planning to send me a last-minute PR for -rc1?
<shadow>
Tartarus: I was hopeful to resolve the LwIP dual network issue but that will have to be in future, I'm not skilled enough to figure it out myself
<apalos>
Tartarus: I just got some tpm patches that are in a good shape
<apalos>
But can I do it in -rc2? IO'd like to leave them in the ML for a week or so
<shadow>
also, without rushing things, I have my eye on the JH7110 USB series from Minda which is largely waiting on marek who had the only unresolved suggestion from the previous round which I think is now resolved
<shadow>
marex: if you had a moment and did you see that Minda sent a new version of the series?
<Tartarus>
apalos: Yes
<Tartarus>
shadow: Yeah, I hoped Jerome would have fixed it by now
<marex>
Maybe another good option would be to modify the console_init_r()
<marex>
function to simply leave "usbkbd" in the environment variables when
<marex>
USB_KEYBOARD is selected, so the "usb start" executed later can
<marex>
actually make USB keyboards work?
<marex>
this ... yes
<marex>
that is the best one as far as I can tell
<marex>
Delesect overwrite when USB keyboard support is selected ... no ... that's awful
<dsimic>
yes, leaving "usbkbd" makes the things work, while making it least possible for some regressions to occur
<dsimic>
yup, I also don't like deselecting
<marex>
retaining usbkbd is also the least obscure/confusing behavior
<dsimic>
indeed
<marex>
that said ... why is the env being rewritten and not extended in the first place ?
chili-b has quit []
<dsimic>
I'm not 100% sure about that, perhaps SYS_CONSOLE_ENV_OVERWRITE exists to make the environment represet the runtime state
<dsimic>
instead of the environment representing the desired state
<marex>
290 config SYS_CONSOLE_ENV_OVERWRITE
<marex>
the help text explains that
<marex>
except when user has usb keyboard plugged in ... that is not determined up front, that is determined because user thinks that's what they will have ... and that I think yes, should be retained in that env variable
<marex>
the help text should be updated a bit to reflect this special case
<marex>
i.e. in case the env contains usbkbd, the env is overwritten, but usbkbd is retained
<dsimic>
yup, common/Kconfig pretty much confirms what I wrote above about the purpose of SYS_CONSOLE_ENV_OVERWRITE
naoki1 has joined #u-boot
<dsimic>
sure, common/Kconfig needs updating to describe the "usbkbd" scenario
<marex>
:)
<marex>
thanks
<dsimic>
maybe you could just briefly sum that up on the ML, or I can copy&paste a few lines from our discussion?
<chili-b>
hello, I am currently having a problem where a USB storage device is failing to mount properly if it's plugged in when my computer powers on and stays plugged in while the OS boots, but if I un-plug the device and only plug it in once the OS has started booting, everything works fine
<chili-b>
the computer is a RockPro64, and the storage device is some seagate usb ssd
<marex>
kernel does not power cycle the USB port properly ?
<chili-b>
possibly, but i'm in this channel because i only started having this issue since updating u-boot
<chili-b>
i was previously on a build from 2020, now i'm on whatever the latest tag upstream is
<chili-b>
downgrading is not an option, i had worse issues with the old version
<chili-b>
i really don't have the time to bisect the issue, so i'm hoping someone has heard of this before
<marex>
nope ... try 'usb stop' before booting , or 'usb reset' , it might do something
<marex>
Kwiboo: maybe ?
<chili-b>
> kernel does not power cycle the USB port properly
<chili-b>
I have some more context on this: when i power on the computer, the LED power indicator on the SSD comes on. After the OS starts booting (around the time the font changes), the LED power indicator turns off and then the SSD doesn't mount properly
prabhakalad has quit [Ping timeout: 252 seconds]
prabhakalad has joined #u-boot
<marex>
is that purely port powered device ?
<marex>
does the power supply enough current ?
chili-b_ has joined #u-boot
chili-b has quit [Ping timeout: 260 seconds]
ladis has quit [Ping timeout: 248 seconds]
<dsimic>
chili-b_: could you, please, send the entire output of "dmesg" from your RockPro64 when your USB storage device fails to be initialized by the kernel?
<dsimic>
assuming that you run Linux, that is
prabhakalad has quit [Ping timeout: 276 seconds]
prabhakalad has joined #u-boot
<chili-b_>
dsimic: where do you want me to upload that?
<marex>
paste.debian.net is nice
<dsimic>
or termbin.com
<dsimic>
termbin is very handy from the command line