<mps>
to me this sounds better, if nvme can't boot (messed FS) then insert rescue mmc card and boot it to fix nvme
<mps>
ofc, breaking u-boot and issue proper 'run bootcmd_$dev' can be used
<mps>
xypron: I don't insist on any order, just thinking aloud what would be best for end users
mmu_man has joined #u-boot
ikarso has joined #u-boot
Clamor has quit [Ping timeout: 255 seconds]
Clamor has joined #u-boot
dsimic has quit [Quit: Going offline for now]
dsimic has joined #u-boot
prabhakarlad has joined #u-boot
dsimic has quit [Quit: Going offline for now]
dsimic has joined #u-boot
dsimic has quit [Client Quit]
dsimic has joined #u-boot
slobodan has joined #u-boot
dsimic has quit [Quit: Going offline for now]
dsimic has joined #u-boot
goliath has joined #u-boot
Guest1119 has quit [Quit: Quit]
Net147 has joined #u-boot
Net147 has quit [Changing host]
Net147 has joined #u-boot
dsimic has quit [Quit: Going offline for now]
dsimic has joined #u-boot
naoki has joined #u-boot
Clamor has quit [Read error: Connection reset by peer]
naoki has quit [Client Quit]
Clamor has joined #u-boot
mmu_man has quit [Ping timeout: 255 seconds]
mckoan is now known as mckoan|away
mmu_man has joined #u-boot
mmu_man has quit [Ping timeout: 255 seconds]
mmu_man has joined #u-boot
dsimic has quit [Ping timeout: 255 seconds]
dsimic has joined #u-boot
davlefou has quit [Ping timeout: 252 seconds]
<gsz>
Hi! I've tried enabling USB_GADGET_DWC2_OTG on an STM32MP13-based board, but in drivers/usb/gadget/dwc2_udc_otg_phy.c there's an undefined variable used: s5p_cpu_id; S5P seems to be a Samsung SoC line. Is it possible to have a U-Boot USB gadget on non-Samsung boards?
<Xogium>
gsz: mainline u-boot I'm guessing ? Cause for me on the st port it is working fine, that is, the otg serves as usb mass storage in u-boot
<Xogium>
maybe you could check how it is done on the st port and try to replicate in mainline ? Random thought
<gsz>
Thanks for confirming that it should work, I'll try to dig deeper
<Xogium>
that seems like mainline to me but... I don't know ? Admitely I never saw that custodian thing before
<Xogium>
the u-boot I use is the one st has on their github, stmicroelectronics/u-boot
<Xogium>
v2022.10
<Xogium>
also, this a custom board or the st dev kit ?
<gsz>
Odyssey-STM32MP135D
<Xogium>
omg
<Xogium>
I've literally, just literally finished porting the odyssey to the st softwares (straight from st not seeed)
<gsz>
I've noticed somewhere on IRC that you were working on it ;)
<gsz>
Is it just U-Boot, or Linux works too?
<Xogium>
I've not attempted mailine at all because I don't need it for my use case, but holy damn was the seeed software a mess
<Xogium>
I ported to the whole boot chain including linux
<Xogium>
even had some nice help to make the eeprom behave as it should, including being able to store mac addresses in there and retrieving via nvmem framework, both in linux and u-boot
<Xogium>
you can also make u-boot store its env in there if you so wish
<gsz>
Nice. Regarding mainlining, are you going to send patches to the relevant projects?
<Xogium>
I don't know, given it's just st softwares atm. Like I said, I didn't attempt mainline, because it wasn't needed for my use case. I plan on using the full power management capabilities of the hardware and iirc this isn't yet possible in upstream
davlefou has joined #u-boot
<Xogium>
I also spoted a few nasty things seeed did when they copied over the dt from the mp135f, including not fixing the vref of the adc. You end up with a vref of 3.3v when the manual clearly indicates it should be 1.8v when using an external vref
<Xogium>
and also, unless I'm completely hallucinated that one, the eMMC in linux was even wrongly configured for 200 mhz frequency. At 3.3v
<gsz>
That's why I'm writing the DT from scratch, though neither way is perfect
<Xogium>
gsz: pm'ed you :)
gmcastil_ has joined #u-boot
mmu_man has quit [Ping timeout: 264 seconds]
gmcastil_at_work has quit [Ping timeout: 272 seconds]
Clamor has quit [Ping timeout: 255 seconds]
mmu_man has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
mmu_man has quit [Ping timeout: 255 seconds]
ikarso has quit [Quit: Connection closed for inactivity]
sakman has joined #u-boot
stefanro has quit [Quit: Leaving.]
ikarso has joined #u-boot
dsimic has quit [Quit: Going offline for now]
dsimic has joined #u-boot
persmule has joined #u-boot
dsimic has quit [Quit: Going offline for now]
dsimic has joined #u-boot
gmcastil_ has quit [Quit: Leaving]
prabhakarlad has joined #u-boot
<Sout_>
so u-boot / linux interaction question. my device says "OF: fdt: Ignoring memory range 0x0 - 0x10000000" using a fit image. with a Load Address: 0x10000000 & Entry Point: 0x10000000. is that just a coincidence? or is that an effect of that load address?
monstr_ has quit [Remote host closed the connection]
dsimic has joined #u-boot
Stat_headcrabed has joined #u-boot
flyback has quit [Quit: Leaving]
flyback- has joined #u-boot
flyback- has quit [Client Quit]
flyback has joined #u-boot
<macromorgan>
is there a way to update a devicetree value to have multiple properties? For example I have a compatible string that I want to set as `"anbernic,rg353v-panel", "newvision,nv3051d"`. Today I'm just setting it as the last value using do_fixup_by_path_string().
<macromorgan>
otherwise I'll have to fix a Linux driver and U-Boot board file at the same time and there could be some version compatibility issues.
slobodan has quit [Read error: Connection reset by peer]
mmu_man has joined #u-boot
slobodan has joined #u-boot
vagrantc has joined #u-boot
justache has quit [Ping timeout: 258 seconds]
justache has joined #u-boot
manchaw has quit [Ping timeout: 252 seconds]
manchaw has joined #u-boot
slobodan has quit [Quit: Leaving]
BobBeck has quit [Read error: Connection reset by peer]
BobBeck3 has joined #u-boot
ezulian has quit [Ping timeout: 240 seconds]
NishanthMenon has quit [Ping timeout: 252 seconds]
NishanthMenon has joined #u-boot
Stat_headcrabed has quit [Quit: Stat_headcrabed]
sukrutb has joined #u-boot
sukrutb_ has joined #u-boot
vagrantc has quit [Quit: leaving]
vagrantc has joined #u-boot
ikarso has quit [Quit: Connection closed for inactivity]
goliath has quit [Quit: SIGSEGV]
sukrutb has quit [Ping timeout: 255 seconds]
sukrutb_ has quit [Ping timeout: 258 seconds]
flom84 has joined #u-boot
sukrutb_ has joined #u-boot
sukrutb has joined #u-boot
sukrutb_ has quit [Ping timeout: 255 seconds]
sukrutb has quit [Ping timeout: 255 seconds]
mripard has quit [Quit: mripard]
ikarso has joined #u-boot
goliath has joined #u-boot
mmu_man has quit [Ping timeout: 255 seconds]
rockosov has quit [Quit: WeeChat 3.4-dev]
Mis012 has joined #u-boot
Mis012- has quit [Ping timeout: 252 seconds]
mmu_man has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
vagrantc has quit [Ping timeout: 258 seconds]
flom84 has quit [Ping timeout: 255 seconds]
vagrantc has joined #u-boot
<silurian_invader>
has anyone else been getting crashes in lists_driver_lookup_name("root_driver")?
<silurian_invader>
it happened to me with qemu_x86_64 and sandbox_spl
<silurian_invader>
after some modifications, so I'm not sure if it's just something misconfigured