ALTracer has quit [Remote host closed the connection]
<Tartarus>
sjg1: I haven't had any time to look at it
ALTracer has joined #u-boot
<sjg1>
Tartarus: OK :-)
ALTracer has quit [Remote host closed the connection]
ALTracer has joined #u-boot
ALTracer has quit [Remote host closed the connection]
ALTracer has joined #u-boot
monstr has joined #u-boot
ALTracer has quit [Remote host closed the connection]
ALTracer has joined #u-boot
ALTracer has quit [Remote host closed the connection]
ALTracer has joined #u-boot
ALTracer has quit [Remote host closed the connection]
ALTracer has joined #u-boot
ALTracer has quit [Remote host closed the connection]
ALTracer has joined #u-boot
ALTracer has quit [Remote host closed the connection]
ALTracer has joined #u-boot
frieder has quit [Remote host closed the connection]
pbergin has joined #u-boot
<pbergin>
Hi, I have a i.mx8mm board where I enable watchdog in u-boot. When using fastboot to program the device it takes longer time that watchdog is triggered with and the board is reset. Is there some implementation kicking the watchdog during fastboot programming?
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
ALTracer has quit [Read error: Connection reset by peer]
ALTracer has joined #u-boot
ALTracer has quit [Remote host closed the connection]
ALTracer has joined #u-boot
ALTracer has quit [Remote host closed the connection]
ALTracer has joined #u-boot
totkeks has joined #u-boot
eballetbo has joined #u-boot
ALTracer has quit [Read error: Connection reset by peer]
ALTracer has joined #u-boot
totkeks has quit [Ping timeout: 246 seconds]
totkeks has joined #u-boot
ALTracer has quit [Remote host closed the connection]
ALTracer has joined #u-boot
ALTracer has quit [Read error: Connection reset by peer]
ALTracer has joined #u-boot
ALTracer has quit [Read error: Connection reset by peer]
ALTracer has joined #u-boot
mmu_man has quit [Ping timeout: 252 seconds]
ALTracer has quit [Remote host closed the connection]
monstr has quit [Remote host closed the connection]
<totkeks>
Hi! I was wondering if someone could give me feedback to my idea. Have a small uboot image as some kind of universal loader and recovery. with boot device selection via menu, recovery webserver, serial over udp and such. from what I have seen so far it seemed that people rather compile a very specific, preconfigured image for their sbc/router.
goliath has quit [*.net *.split]
Danct12 has quit [*.net *.split]
rfs613 has quit [*.net *.split]
mps has quit [*.net *.split]
ellyq has quit [*.net *.split]
narmstrong has quit [*.net *.split]
Epakai has quit [*.net *.split]
indy has quit [*.net *.split]
mkorpershoek has quit [*.net *.split]
aat596 has quit [*.net *.split]
marcan has quit [*.net *.split]
bern has quit [*.net *.split]
Danct12 has joined #u-boot
goliath has joined #u-boot
mps has joined #u-boot
narmstrong has joined #u-boot
rfs613 has joined #u-boot
Epakai has joined #u-boot
indy has joined #u-boot
mkorpershoek has joined #u-boot
aat596 has joined #u-boot
marcan has joined #u-boot
ellyq has joined #u-boot
bern has joined #u-boot
<calebccff>
totkeks: cool nick :P. im super interested in something along these lines (from a philosophical standpoint making boards more accessible, and from a coolness standpoint too). I work on porting U-Boot to Android phones in my free time with a similar goal
<rfs613>
hmm, let's rewind for a moment to the (good old) days when you might have u-boot as the first code executed when the CPU powers on.
<rfs613>
the problem here is it's virtually impossible to have a "universal" image at this point
<ellyq>
yeah that
<ellyq>
that's not... possible in many cases, because SoC vendors decided that BROM should only load what vendor deemed worthy
<totkeks>
more like universal image for device X. in my case a banana Pi R4
<rfs613>
if we are talking later on, when the CPU and RAM (and display and touchscreen and maybe wifi) are all operating... then to me it's not really a bootloader anymore... but rather some application that should just be part of the boot chain.
<calebccff>
which is exactly what EFI was made for
<rfs613>
well except now you need EFI everywhere, vendor must implement it correctly, etc.
<calebccff>
i think you're scope-creeping
<rfs613>
it's kind of the JAVA model, it runs anywhere as long as you have a JVM
<calebccff>
since mach-snapdragon is more or less a universal image (build one u-boot binary run it on almost any arm64 qcom board) the idea of building in all the necessary features to make the thing user-friendly is super sensible imo
<calebccff>
i also don't believe most vendors would do this
<ellyq>
most vendors suck at firmware
* ellyq
looks at dead Gigabyte mainboard in front of them
<rfs613>
indeed
<calebccff>
what im interested in is making sure that a) we can run our own bootloader in the first place, and b) getting solid support in upstream. Since the upstream community is much more motivated to developer QoL features this should tend towards a world where we can get a board with some vendor crap bootloader, flash the well-supported upstream and have a better UX
<calebccff>
the only benefit of the vendor BL in that case will be the tighter vertical integration
<calebccff>
i think that's a fine trade-off
<rfs613>
yeah just gettign a) is chalenging, and I suspect only get worse as more things get locked "for our protection" etc
<calebccff>
rfs613: yeahh, chainloading is at least viable
<calebccff>
if not ideal
<rfs613>
calebccff: I'd say it is viable when the vendor hasn't done something to prevent it (maybe intentional, maybe by accident due to "security architecture" mandated)
<rfs613>
anyhow to go back to the original point... I would just say be careful with the term "universal"...
<totkeks>
it would be amazing if that were possible, but yeah. bootrom, architectures and what not prohibit that. but at least on the other side towards the OS something like UEFI would be good, wouldn't it?
<totkeks>
calebccff, I like your thoughts. i am quite happy that the R4 isn't fully locked down. but so many people on the forum struggle with booting other linuxes and such. and I thought it would just be cool to have a smart and helpful uboot image. put in the sd card, get serial via udp or webserver without TTL adapter. install to flash. setup default boot option. like the R4 can't boot from nvme or usb, only SD/emmc/nand. It would just
<totkeks>
make devices more approachable
<rfs613>
building on standards like UEFI make sense... though it may limit what you can accomplish (lowest-common-denominator kind of thing)
<rfs613>
i havent used the R4 but the problems you just described sound familiar on almost every board i've ever dealt with
<rfs613>
there's always a learning curve.. and the only way to really make it simpler is to take away options/flexabillty.
<totkeks>
you mean a boot menu with a "select default boot device" option instead of editing the whole env manually in the cli?
<totkeks>
i think that is a fair trade for most people.
<rfs613>
"you will boot the device exactly like this"... but then us linux/floss people complain that our favourite distro/app doesn' work
<totkeks>
but it should work better because of that. because you don't have to adapt the image of the distro anymore.
<totkeks>
because that is handled by the smarty bootloader
<totkeks>
and it would allow less tech savvy people to play around with those boards without having to go through a full CS degree
<rfs613>
something like NOOBs for the PI seems to be reasonable approach
<rfs613>
(I dont know how it is architected... speaking just as a user)
<totkeks>
for the R4 there are people that try arch, debian, ubuntu. and the default option openwrt (which works fine, but has a custom uboot)
<totkeks>
oh, just saw, the imager supports different OSes
<totkeks>
(NOOBs is now called raspberry pi imager)
<rfs613>
yeah, which is actually a better name, considering what it actually does
<rfs613>
my Pi's are 5+ years old now so I'm out of touch with the current state
<totkeks>
i think I had a pi2 once. but now its this banana pi. and it has 4GB RAM, which is a lot for a router to play with.
<calebccff>
totkeks: yeah having accessible serial ootb is a really nice feature for a bootloader like that
<totkeks>
and i mean, once that is setup using config flags, env command and if necessary some extra C code, then it could work for all boards using their DTS and existing configs, right?