Tartarus changed the topic of #u-boot to: SOURCE MOVED TO https://source.denx.de/u-boot/u-boot.git / U-Boot v2021.10 is OUT / Merge Window is OPEN until 25 October 2021 / Release v2022.01 is scheduled for 10 January 2022 / http://www.denx.de/wiki/U-Boot / Channel archives at https://libera.irclog.whitequark.org/u-boot
mmu_man has quit [Ping timeout: 240 seconds]
vagrantc has quit [Quit: leaving]
apritzel has quit [Ping timeout: 240 seconds]
sdfgsdfg has quit [Quit: your partner prefers dildos]
samekh has quit [Ping timeout: 240 seconds]
samekh has joined #u-boot
thopiekar has quit [Ping timeout: 240 seconds]
thopiekar has joined #u-boot
<sjg1> marex: Yes we should add that. It would solve a lot of troubles
vagrantc has joined #u-boot
sdfgsdfg has joined #u-boot
vagrantc has quit [Quit: leaving]
sbach has quit [Read error: Connection reset by peer]
sbach has joined #u-boot
mmu_man has joined #u-boot
yetoo has joined #u-boot
<yetoo> do kpart files have elf header or without
guillaume_g has joined #u-boot
fdanis_away is now known as fdanis
sdfgsdfg has quit [Quit: your partner prefers dildos]
frieder has joined #u-boot
mckoan|away is now known as mckoan
coldspark29 has joined #u-boot
sdfgsdfg has joined #u-boot
apritzel has joined #u-boot
apritzel has quit [Ping timeout: 256 seconds]
samekh has quit [Ping timeout: 240 seconds]
zibolo has joined #u-boot
samekh has joined #u-boot
sszy has joined #u-boot
lucaceresoli has joined #u-boot
mmu_man has quit [Ping timeout: 240 seconds]
matthias_bgg has joined #u-boot
apritzel_ has joined #u-boot
mmu_man has joined #u-boot
lucaceresoli_ has joined #u-boot
lucaceresoli has quit [Ping timeout: 256 seconds]
Net147 has quit [Quit: Quit]
lucaceresoli_ has quit [Ping timeout: 256 seconds]
Net147 has joined #u-boot
Net147 has joined #u-boot
Net147 has quit [Changing host]
monstr has joined #u-boot
Luker has quit [Quit: ZNC - http://znc.in]
Luker has joined #u-boot
mckoan is now known as mckoan|away
jenneron[m] has joined #u-boot
<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 joined #u-boot
apritzel_ has quit [Ping timeout: 256 seconds]
redbrain has quit [Ping timeout: 240 seconds]
apritzel has quit [Ping timeout: 250 seconds]
redbrain has joined #u-boot
sszy has quit [Ping timeout: 252 seconds]
___nick___ has joined #u-boot
___nick___ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
___nick___ has joined #u-boot
___nick___ has quit [Client Quit]
___nick___ has joined #u-boot
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
<baltazar> s/fro/for/
sakman has joined #u-boot
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