<jenneron[m]>
hello, i need some help with configuring u-boot, i want to force it to search for scripts (or extlinux) in the second partition of SD card
<jenneron[m]>
i tried to undef `CONFIG_BOOTCOMMAND` in `include/configs/snow.h` and define it with my commands which set devtype, devnum etc, but it seems that u-boot just ignores my `CONFIG_BOOTCOMMAND`
lucaceresoli_ has joined #u-boot
parabyte has joined #u-boot
<parabyte>
okay i admit iv only briefly looked over current version of u-boot from github
<parabyte>
i have a small question
<parabyte>
how do i disable pxe booting?
<parabyte>
i wish to have no network booting at all
<parabyte>
im using a board with no ethernet
<parabyte>
im building from source
sdfgsdfg has quit [Quit: ayo yoyo ayo yoyo hololo, hololo.]
marc1 has joined #u-boot
frieder has quit [Remote host closed the connection]
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
<parabyte>
i figured out i just commented out a bunch of stuff in the source!
Forty-Bot has quit [Ping timeout: 240 seconds]
Forty-Bot has joined #u-boot
fdanis is now known as fdanis_away
Forty-Bot has quit [Ping timeout: 256 seconds]
zibolo has quit [Ping timeout: 250 seconds]
guillaume_g has quit [Quit: Konversation terminated!]
redbrain has joined #u-boot
apritzel has joined #u-boot
matthias_bgg has quit [Quit: Leaving]
lucaceresoli_ has quit [Ping timeout: 240 seconds]
Amit_T has quit [Remote host closed the connection]
apritzel has joined #u-boot
lucaceresoli_ has joined #u-boot
vagrantc has joined #u-boot
monstr has quit [Remote host closed the connection]
lucaceresoli_ has quit [Ping timeout: 240 seconds]
___nick___ has quit [Ping timeout: 256 seconds]
redbrain has quit [Quit: leaving]
redbrain has joined #u-boot
<marex>
jenneron[m]: did you reset the env or at least run 'env default bootcmd ; saveenv' ?
<marex>
else you might've still been using the old env stored in some backing store
<marex>
parabyte: disable CONFIG_NET
<parabyte>
yeah i figured it out
<parabyte>
also found what i needed in the u-boot documentation, but its so vast!
sdfgsdfg has joined #u-boot
sdfgsdfg has quit [Ping timeout: 256 seconds]
redbrain has quit [Ping timeout: 240 seconds]
baltazar has joined #u-boot
<baltazar>
hi! I'm using u-boot on a nanopi neo, and for some reason the mac address appears to be random on every boot.
<baltazar>
Seemingly, systemd can set it based on /etc/machine-id, which is generated at first boot.
<baltazar>
but I wonder, is there some way to generate a mac address based on some hardware property?
<baltazar>
like, if I were to copy the same image from one device to another, I'd want their mac addresses to be different, but with this approach they will be the same.
<baltazar>
as a proof of concept, I wrote a small userspace c program that sets it based on the cpu's serial number
<baltazar>
is there a way to do something similar from within u-boot?
<apritzel>
baltazar: what U-Boot version are you using? Mainline or some vendor stuff?
<apritzel>
because we have MAC generation in U-Boot based on the SID serial number in mainline U-Boot for ages
<baltazar>
apritzel: I built v2021.10 using nanopi_neo_defconfig
<apritzel>
baltazar: this is an Allwinner H3, right?
<baltazar>
apritzel: yes
<apritzel>
do you see a MAC address in U-Boot? some env variable
<apritzel>
baltazar: so to be clear: U-Boot does what you suggest: we read the SID serial number from the efuses, hash them, generate a MAC address, and write this into the DT
<baltazar>
apritzel: huh, that would be pretty awesome if I could get it to work
<apritzel>
what puzzles me is that it should just work
<apritzel>
it could be a problem with the efuses, there are reports of chips reading all zeroes, but I doubt that those end up on NanoPis
<baltazar>
apritzel: the device is currently being used, so I can't reboot it for a while. I'll check the environment when I can
<apritzel>
another problem could be the DT update, but I wouldn't know of any problems with this either
<cambrian_invader>
baltazar: if you have a mac address you like, you can always run saveenv
<apritzel>
baltazar: ah wait
<cambrian_invader>
which will keep the same ethaddr across reboots
<apritzel>
baltazar: it seems the (mainline) DT is missing the eth0 alias in the /aliases node
<apritzel>
baltazar: which is required for U-Boot the generate the MAC address
<baltazar>
cambrian_invader: that just saves it to the SD doesn't it? I kinda want a "more robust" solution than that
<cambrian_invader>
depends on where env is stored on your platform
<cambrian_invader>
if you happen to have an eeprom you can implement nvmem-cells for U-Boot :)
<apritzel>
cambrian_invader: those poor Allwinner based board save pennies where they can ;-)
<cambrian_invader>
alas
<apritzel>
baltazar: edit arch/arm/dts/sun8i-h3-nanopi.dtsi, and add "ethernet0 = &emac;" after the serial0= line in the a
<apritzel>
... liases node
<apritzel>
then rebuild U-Boot and retry
<baltazar>
apritzel: nice, I'll try that. thanks for the quick help!
<apritzel>
baltazar: this is slightly hackish, but if that works, we can make a proper patch
<apritzel>
baltazar: this should then behave as you hope: it will generate a unique(*) MAC on each device, with the very same binary image, in U-Boot, and Linux (or any other kernel) will pick that up automatically
<apritzel>
(*) as unique as possible, because it contains a hash from something we hope is a unique serial number, so theoretically there is very slim chance of a collision
<baltazar>
also, is there some "proper" way to boot? I basically hacked together something based on how a raspberry pi image works, so I just have a boot.cmd script: http://ix.io/3NIT
<apritzel>
baltazar: what is your rootfs? some distro or something special?
<baltazar>
apritzel: it's archlinuxarm
<baltazar>
but I'm just now realizing, looking at the config, that u-boot supports ext4, so I could just have it all on the same partition, right?
<baltazar>
(currently I have a separate boot partition)
<apritzel>
baltazar: I don't know what Arch suggests here, other distros tend to generate a boot.scr for you and put that in a place where U-Boot will pick it up
<apritzel>
baltazar: or you use UEFI, but I don't know how well this works with 32-bit ARM
<apritzel>
then U-Boot loads and execute grub, and the distro takes it from there
sakman has quit [Remote host closed the connection]
<baltazar>
apritzel: all right, if boot.scr is "the way" then I'll stick with it, I just wondered if there's a more direct way to just tell u-boot to load my kernel
<apritzel>
baltazar: as I said: UEFI solves this pretty nicely, U-Boot will scan all storage to find \EFI\boot\bootarm.efi, which is typically grub installed by the distro
vagrantc has quit [Quit: leaving]
<apritzel>
baltazar: and the distro then maintains the grub.cfg, as it does on x86, with menuentries for all installed kernels and auto boot
<baltazar>
apritzel: I see. well I don't really need grub, I'll only ever have this single kernel (I hope), and this seems to be the way arch does stuff, it's just that there's no `uboot-nanopi-neo` package (lots of other boards have packages, like `uboot-raspberrypi`, that contain the boot.scr files)
<apritzel>
baltazar: as you figured, the boot.scr files are actually pretty generic, and we use all the same standard variable names in U-Boot to cover the individual boards
<apritzel>
baltazar: so if it's just about the boot.scr file, you could probably use any other Allwinner board, unless it writes the actual U-Boot to the SD card
<apritzel>
I *think* Debian's flash-kernel implements something along those lines ...
<baltazar>
apritzel: well, arch packages can't really do that, and I assume that's the reason why I don't see any uboot-* packages fro allwinner boards
sakman has quit [Remote host closed the connection]
<apritzel>
that's for an A20, but if you leave out the actual u-boot-sunxi-with-spl.bin file, the rest should apply, especially the generic boot.scr from here: os.archlinuxarm.org/os/sunxi/boot/pcduino3/boot.scr
sakman has joined #u-boot
sakman has quit [Remote host closed the connection]
<baltazar>
apritzel: I guess this is basically the same as what I have, except it has some ifs
<apritzel>
indeed
<baltazar>
anyway, arch not having a uboot-nanopi-neo package is their fault and not u-boot's, so I'll bug them with it instead
<apritzel>
but it seems like arch doesn't try too hard to wrap this
<apritzel>
baltazar: well, technically a distro shouldn't need to care about the actual firmware, just arrange everything on the interface, which could be a generic boot.scr or UEFI
<apritzel>
and I'd say this particular boot.scr works on almost every half-way sane U-Boot supported platform
<baltazar>
apritzel: hm, not sure why they don't have a uboot-generic or something like that instead then
<apritzel>
baltazar: I think because they also try to ship the actual U-Boot image, which is board specific
<baltazar>
apritzel: yeah, well that could be included in a separate package, but there isn't much need for having the same boot.scr in all these packages
<apritzel>
baltazar: I would say, so if you have the energy and motivation, try to persuade them
<apritzel>
baltazar: I think most distros try to avoid the maintenance burden of such an approach, because it might not work *everywhere*, and then people keep complaining
<baltazar>
apritzel: I guess they could have most `uboot-whatever` packages depend on `uboot-generic`, and where generic doesn't work, have `uboot-whatever` include those files instead, and don't depend on the generic package
<baltazar>
but it's not like I know much about maintaining a distro, so...
<baltazar>
also, funny how the install guide tells me to install that package "In order to receive updates to the U-Boot bootloader", but the latest package is from 2017
<apritzel>
baltazar: I know, the whole situation is a bit sad