<naoki>
I cannot subscribe ML... confirmation mail? is not arrived
mmu_man has joined #u-boot
<mckoan>
in u-boot we have several commands to load/receive a file (tftp, fatload, loady, etc...) is there any command to send/transmit a file ro the couterpart connected via LAN/serial ?
<mckoan>
to the counterpart (target -> PC)
goliath has joined #u-boot
zibolo has joined #u-boot
BWhitten has joined #u-boot
mps has quit [Remote host closed the connection]
mps has joined #u-boot
jsmolic has joined #u-boot
stefanro has quit [Remote host closed the connection]
ikarso has quit [Quit: Connection closed for inactivity]
stefanro has joined #u-boot
alan_o has quit [Remote host closed the connection]
<hays>
marex: the command works, but I just dont know where to find full documentation
* marex
is intelectually inoperable, sorry
<marex>
hays: => help bootm
<marex>
hays: if something is missing , you can also write the docs and submit patches upstream , obv
<marex>
hays: got any specific question ?
<hays>
right now im loading the kernel image, device tree, and initrd into places in memory that are kind of magic numbers and I am trying to see if I can give bootm just a path to these things
<hays>
heh not sure I can write the docs if I myself don't know how it works. maybe I can find the help command in the source
<hays>
are they something that is board-specific and we take them from the various vendor boot processes?
<vagrantc>
some boards have various default addresses deffined ... it is somewhat board-specific
<hays>
ok so unlikely to change going from a vendor kernel to mainline for example or different u-boot versions
<vagrantc>
e.g. kernel_addr_r, ramdisk_addr_r, fdt_addr_r ...
<cambrian_invader>
fwiw, `bootm` with no arguments is equivalent to `bootm $loadaddr`
<cambrian_invader>
which is nice if you're typing things manually
<vagrantc>
a vendor u-boot might implement arbitrary values
<hays>
right now its bootm ${boot_loadaddr} ${initrd_loadaddr} ${dtb_loadaddr}
<hays>
vagrantc: kernel_addr_r, ramdisk_addr_r, etc... where are these?
<vagrantc>
doc/develop/distro.rst
<vagrantc>
although things are in transition from distro boot to standard boot or something
<vagrantc>
i think loadaddr and kernel_addr_r are often the same? but ... check on that.
<vagrantc>
bootm has been around longer than documentation has. :)
<vagrantc>
maybe documentation wasn't even invented yet
<hays>
heh
<hays>
ok so this is an odroid-n2-plus. the defconfig doesn't seem to have it.. there is no (obvious?) include/config/ (maybe meson_64.h?)..
<vagrantc>
hays: so, you're stepping into one of the issues with u-boot, and that is ... there are many ways to do more-or-less the same thing ... and depending on when your board was implemented ... there may be wildly different choices made
alan_o has quit [Remote host closed the connection]
<vagrantc>
hays: maineline or some u-boot fork?
alan_o has joined #u-boot
<hays>
sigh.. I thought it was mainline, but the more I think about it... I am not sure. I think it might be some version shipped with a vendorized petitboot
<vagrantc>
there are a couple odroid-n2 variants supported in mainline just looking at configs/odroid-n2*
<hays>
there is this file boot.ini that is basically u-boot commands.
<hays>
vagrantc: yeah so this device boots just fine on mainline. but if you want to configure boot order, this switch you flip loads petitboot, which apparently looks for a boot.ini file that has a list of uboot commands
<hays>
so its unclear to me what version of uboot.. but I was hoping mainline would at least have these addresses.. or I could confirm these magic numbers
<hays>
the defconfigs dont seem to have them
<vagrantc>
can you boot and get to a u-boot prompt?
<vagrantc>
then it's just a few "printenv x y z" away
<vagrantc>
include/configs/meson64.h
<vagrantc>
not *sure* of that ... but i think the n2 variants use that
<hays>
yeah i was thinking maybe.. ok im in the petitboot uboot (weird) and 2015.01 is the version
<hays>
im going to grab the env variables
<vagrantc>
2015.01 sounds suspiciously old :)
<vagrantc>
which is not uncommon for vendor forks...
<hays>
ok.. they are different. interesting.
<hays>
the old u-boot matches whats in this boot.ini file...
<hays>
so I guess the question is does it make sense to update these to the new value or keep the old
* vagrantc
shrugs
<hays>
does this matter once the device is booted?
<hays>
i assume the kernel stays where it is
<vagrantc>
people generally wash their hands of supporting vendor forks, as who knows what they've done to it so it is basically impossible to make any reasonable claims about it :/
<hays>
yeah, i can understand that.
<vagrantc>
some vendors might be more reasonable than others ... but ... it is really hard to support
<vagrantc>
ask the vendor :)
<vagrantc>
or ... try getting mainline working :)
<hays>
just trying to understand conceptually--this area in memory.. does the kernel stay there or is this something that doesn't really persist beyond boot
<hays>
mainline works, but this petitboot is in spi nor
<hays>
like.. it boots the way it is--im just wondering. the main OS "usually" boots with mainline, so I wonder if it makes sense to match up the memory addresses
<vagrantc>
i think the kernel is generally loaded to a particular address and then it extracts itself somewhere else ... and there are occasioanlly areas of ram that should be carved out for this-or-that ...
<vagrantc>
but anything more specific than that ... you start to have to be talking really specifically
<vagrantc>
the load addresses, as long as you are not clobbering something else that expects to be there ... kind of do not matter? e.g. if you are loading a kernel at one address, and the tail end of the kernel overwrites the beginning of the initramfs, obviously, you will have problems
<vagrantc>
but again, to each platform, their own madness
<vagrantc>
some platforms use some of the ram for the GPU, arm-trusted-firmware might be running in a particular slice, etc.
<vagrantc>
in general, generalizations are inaccurate
vagrantc has quit [Quit: leaving]
<hays>
well i think your analys confirms my hunch that the values come from meson64.h
<hays>
those are the values when mainline is used. So I think I'll ship this boot.ini with those values even though its an old U-boot.
<marex>
vigneshr: you gonna be at EOSS Prague ?
<marex>
and ... I wanted to ask Vagrant too, but oh well
<hays>
Prague is a cool city
vagrantc has joined #u-boot
<marex>
vagrantc: you gonna be at EOSS Prague ?
<marex>
hays: thank you
<vagrantc>
marex: i have not come out of a hermit phase yet
<marex>
vagrantc: is that the covid phase or build nucular shelter phase now ?
<vagrantc>
marex: redundancy!
<marex>
:)))
<vagrantc>
Redundant Array of Impending Doom? so far only up to RAID1
* vagrantc
gets back to the bioregionalism roots
<marex>
makes you wonder what's next in the pipeline, alien invasion or what ...
<marex>
och
apritzel_ has joined #u-boot
sakman has quit [Remote host closed the connection]
sakman has joined #u-boot
<hays>
ai takeover :)
naoki has joined #u-boot
Kevin` has quit [Ping timeout: 276 seconds]
ikarso has quit [Quit: Connection closed for inactivity]