<marex>
fltrz: loadaddr should be in DRAM somewhere, ideally aligned
macromorgan has joined #u-boot
macromorgan_ has quit [Ping timeout: 258 seconds]
macromorgan_ has joined #u-boot
<Forty-Bot>
it also needs to be somewhere U-Boot isn't, or you will have strange problems and scratch your head a lot
<Forty-Bot>
and you must be able to read/write a little before the load address too
macromorgan has quit [Ping timeout: 240 seconds]
thopiekar has quit [Ping timeout: 245 seconds]
thopiekar has joined #u-boot
flyback has quit [Ping timeout: 260 seconds]
mmu_man has quit [Ping timeout: 240 seconds]
flyback has joined #u-boot
flyback has quit [Ping timeout: 240 seconds]
jclsn has quit [Ping timeout: 240 seconds]
jclsn has joined #u-boot
flyback has joined #u-boot
flyback- has joined #u-boot
vagrantc has quit [Quit: leaving]
flyback has quit [Ping timeout: 260 seconds]
pbsds has quit [Ping timeout: 240 seconds]
flyback- has quit [Quit: Leaving]
pbsds has joined #u-boot
cyrozap has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
qqq has quit [Remote host closed the connection]
cyrozap has joined #u-boot
cyrozap has quit [Client Quit]
qqq has joined #u-boot
flyback has joined #u-boot
cyrozap has joined #u-boot
cyrozap has quit [Ping timeout: 264 seconds]
persmule has quit [Remote host closed the connection]
Clamor has joined #u-boot
macromorgan_ has quit [Quit: Leaving]
macromorgan has joined #u-boot
_whitelogger has joined #u-boot
cyrozap has joined #u-boot
cyrozap has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
cyrozap has joined #u-boot
cyrozap has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
cyrozap has joined #u-boot
ezulian has joined #u-boot
Xogium has joined #u-boot
<Xogium>
how does one target the boot areas of an eMMC with dfu_alt_info ?
<Xogium>
I tried something like setenv dfu_alt_info "mmc=fsbl1 part 1 1;fsbl2 part 1 2". It tells me it can't find partition #1 on mmc1 when I try to list the dfu alt info settings
<Xogium>
mmc dev 1 1 works
<Xogium>
just want to burn my bootloader in there :/
qqq has quit [Remote host closed the connection]
f_ has joined #u-boot
<f_>
hi
<f_>
sjg1: re binman for signing U-Boot binaries on Amlogic..I and Kwiboo recently got SPL to boot on gxbb!
stefanro has joined #u-boot
<f_>
We still have some rough edges but so far it works quite well.
<fltrz>
marex: I believe the install instructions or image tarball is faulty, either u-boot needs to be configured to support ext4 or the instructions need to be modified to use mkfs.ext2 instead of mkfs.ext4
sicelo has quit [Remote host closed the connection]
<Lightsword>
how do I the size of a mmc device in bytes in uboot?
<marex>
fltrz: oh ... 11 years old version ... hmmmmm
<marex>
fltrz: try mainline, the odroid xu3 is supported there, see doc/README.odroid
<marex>
fltrz: or try 2023.07.02
mmu_man has joined #u-boot
dsimic has quit [Ping timeout: 260 seconds]
dsimic has joined #u-boot
f_ has quit [Ping timeout: 245 seconds]
Clamor has quit [Ping timeout: 258 seconds]
Clamor has joined #u-boot
<fltrz>
marex: in what repository is doc/README.odroid ?
<fltrz>
marex: sorry, thats in uboot repo of course...
<fltrz>
marex: those instructions point to the 2012 u-boot again
<fltrz>
marex: with mailine I assume you only meant mainline u-boot support, or do you even mean mainline linux?
smoothdev has quit [Ping timeout: 258 seconds]
pbsds has quit [Ping timeout: 240 seconds]
smoothdev_ has joined #u-boot
slobodan has quit [Remote host closed the connection]
slobodan has joined #u-boot
slobodan has quit [Read error: Connection reset by peer]
slobodan has joined #u-boot
pbsds has joined #u-boot
persmule has joined #u-boot
slobodan has quit [Read error: Connection reset by peer]
slobodan has joined #u-boot
slobodan has quit [Remote host closed the connection]
mmu_man has quit [Ping timeout: 252 seconds]
<sjg1>
nehamalcomfranci: I got your message but cannot reply...can you please email instead?
<mps>
how can be asked for commit in next branch to be picked to next stable release
<Xogium>
does anyone knows how I can target the eMMC boot0/boot1 using dfu_alt_info ?
<marex>
fltrz: frankly, I would focus on both
<marex>
fltrz: the instructions talk about some preloader
dsimic has quit [Quit: Going offline for now]
dsimic has joined #u-boot
slobodan has joined #u-boot
f_ has joined #u-boot
Clamor has quit [Ping timeout: 255 seconds]
mmu_man has joined #u-boot
Clamor has joined #u-boot
Mis012 has joined #u-boot
GNUtoo has quit [Ping timeout: 252 seconds]
Mis012- has quit [Ping timeout: 252 seconds]
slobodan has quit [Read error: Connection reset by peer]
slobodan has joined #u-boot
GNUtoo has joined #u-boot
<Xogium>
well... I've looke for hours on end and can't find any doc on this nor seemingly anyone who's ever attempted to access the boot0/boot1 partitions over dfu
nehamalcomfranci has joined #u-boot
nehamalcomfranci has quit [Ping timeout: 245 seconds]
smoothdev_ has quit [Ping timeout: 255 seconds]
smoothdev has joined #u-boot
f_ has quit [Ping timeout: 260 seconds]
smoothdev has quit [Ping timeout: 258 seconds]
smoothdev has joined #u-boot
thopiekar has quit [Ping timeout: 264 seconds]
thopiekar has joined #u-boot
<Tartarus>
Xogium: The "part" syntax? Those are the HW partition, not SW partition table partitions, iirc
smoothdev has quit [Ping timeout: 258 seconds]
smoothdev has joined #u-boot
<Xogium>
Tartarus: yeah... So how do I access them ? And if so, why would mmc dev 1 1 give me the hw boot partition ?
<Xogium>
I expected dfu to do the same
<Tartarus>
Er, given:
<Tartarus>
* <name> part <dev> <part_id> [offset <byte>] raw access to partition
<Tartarus>
does somename part 1 1, not give you the same things "mmc dev 1 1" does ?
<Xogium>
don't thin so, no
<Tartarus>
I don't have an easy test at hand, sorry
<Xogium>
STM32MP> setenv dfu_alt_info "mmc=fsbl1 part 1 1;fsbl2 part 1 2"
<Xogium>
STM32MP> dfu 0 mmc 1 list
<Xogium>
Couldn't find part #1 on mmc device #1
<Tartarus>
I feel like I must have throw stuff on the eMMC, on the boot parts, on my beaglebone black via DFU forever-and-ever ago
<Tartarus>
So you might have to start tossing in some debug prints to see what's failing / why it's failing
<Xogium>
I reckon so... Thanks for at least pointing that I'm not quite insane yet ;)
slobodan has quit [Remote host closed the connection]
slobodan has joined #u-boot
Clamor has quit [Read error: Connection reset by peer]
rvalue has quit [Ping timeout: 244 seconds]
rvalue has joined #u-boot
slobodan has quit [Remote host closed the connection]
slobodan has joined #u-boot
goliath has joined #u-boot
smoothdev has quit [Ping timeout: 240 seconds]
smoothdev has joined #u-boot
smoothdev has quit [Ping timeout: 240 seconds]
smoothdev_ has joined #u-boot
gmcastil has joined #u-boot
<gmcastil>
I'm trying to recover an embedded system via a serial port and I wish to override bootargs that are provided in /boot/extlinux/extlinux.conf - i've tried setting bootargs from the u-boot prompt, but it seems the extlinux flavors override them. can i force my own to take precedence?
ezulian has quit [Ping timeout: 248 seconds]
Eschik has quit [Read error: Connection reset by peer]
<gmcastil>
i guess i'm asking if there is a way to override kernel boot arguments that are defined in /boot/extlinux/extlinux.conf from the U-boot console...perhapse there isnt any
slobodan has quit [Ping timeout: 244 seconds]
<Xogium>
I don't think so. I don't suppose you can easily edit that file and it's on some eMMC storage ?
<gmcastil>
its on an SD, so i can but its a bit of a pain
<gmcastil>
this is a development system, so i was hoping to be able to mess with kernel boot arguments to my hearts content from the uboot console
<Xogium>
I mean maybe there's a way, but I haven't found it either
<gmcastil>
is there an explanation somewhere of the priority of boot args?
<gmcastil>
i have control over my device tree chosen node and the extlinux.conf and the u-boot console, so i have all the keys to the store
<gmcastil>
i just dont know what the hierarchy is
<gmcastil>
and `setenv bootargs 'something silly that shouldnt work'` has no effect when i run the `boot` command
<Xogium>
I think what is actually happening is when u-boot loads extlinux in the boot process, it simply overrides your previously defined bootargs
goliath has quit [Quit: SIGSEGV]
<gmcastil>
Xogium, yeah that would make sense
<gmcastil>
so in principal, if i wanted to manually load my kernel and device tree and then boot the kernel, i could fix it that way
<gmcastil>
i'm in a much more practical mood, so i pulled the SD card, hacked the extlinux.conf file, and then rebooted the board and that got me unstuck