<logicalerzor>
calebccff yeah it's armv7. i've never built uboot before and only used it as towboot in the ppp. what would u recommend i look into to get started on this? i know there are various guides online, but i figured u'd probably know best on what actually needs to happen
<logicalerzor>
f_ oh that's awesome. i wonder if someone has created a matrix bot that can scrape said website and just send messages whenever needed...
<logicalerzor>
i assume the bridges are setup by the admin here, but it'll be more work for them
<Tartarus>
I found the bridge stuff too unreliable a few years ago and just came back to IRC + irccloud
<marex>
Tartarus: it did not improve since
mps has quit [Ping timeout: 268 seconds]
LeSpocky has quit [Ping timeout: 260 seconds]
LeSpocky has joined #u-boot
ikarso has quit [Quit: Connection closed for inactivity]
alpernebbi has quit [Ping timeout: 264 seconds]
alpernebbi has joined #u-boot
naoki has quit [Quit: naoki]
mmu_man has quit [Ping timeout: 268 seconds]
flyback has quit [Remote host closed the connection]
joeskb7 has quit [Ping timeout: 240 seconds]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
joeskb7 has joined #u-boot
<logicalerzor>
my understanding of getting u-boot to run on an old android device is the following:
<logicalerzor>
- set a UART address
<logicalerzor>
- set an address in memory where u-boot will boot from
<logicalerzor>
- only need to create a defconfig (there doesn't seem to be any armv7 defconfigs?)
<logicalerzor>
the stock bootloader will take care of the nitty gritty details and u-boot already pulls in dts's from linux, so we can just run u-boot as if it were just another program that just kexec's into linux
<logicalerzor>
my main question is, is there anything im missing? just having a generic armv7 defconfig (with fillable UART and booting address) be enough right? im not sure what to base my defconfig off of since qcom_defconfig seems to be off of armv8, but im guessing this would be the closest thing to a generic config (need to figure out how to get it to armv7). any help is much appreciated (even how i should read the uboot code to help
<logicalerzor>
myself)
srk has joined #u-boot
redbrain has quit [Read error: Connection reset by peer]
sally has quit [Quit: sally]
sally has joined #u-boot
redbrain has joined #u-boot
sally has quit [Client Quit]
sally has joined #u-boot
sally has quit [Remote host closed the connection]
Sout has quit [Excess Flood]
Sout_ has joined #u-boot
sally has joined #u-boot
Clamor has joined #u-boot
dhruvag2000 has joined #u-boot
mps has joined #u-boot
naoki has joined #u-boot
Clamor has quit [Ping timeout: 260 seconds]
Clamor has joined #u-boot
goliath has joined #u-boot
monstr has joined #u-boot
<LetoThe2nd>
what is the connection between u-boot and raspis cmdline.txt? is it loaded behind the scenes? or is that just some cargo cult (which I suspect), because I can't find any trace of it when looking at the flow once u-boot itself has ben reached, e.g. it seems to be just bootargs in effect.
ldevulder has joined #u-boot
frieder has joined #u-boot
eballetbo has joined #u-boot
enok has joined #u-boot
<mkorpershoek>
logicalerzor: Android having a special boot image format (it's not FIT), you also need to enable some additional defconfig options, such as CONFIG_CMD_ABOOTIMG. configs/khadas-vim3_android_defconfig should give some help with what is needed
naoki has quit [Remote host closed the connection]
naoki has joined #u-boot
frieder has quit [Ping timeout: 240 seconds]
<mkorpershoek>
As custodian, I'm not sure how things work to announce vacation, so I'll just write it here: I'll be out of office for the next 2 weeks until 4th of July. I won't have any computer access. So thank you for your patience while I'm away!
mckoan|away is now known as mckoan
Lightsword has quit [Quit: ZNC]
Lightsword has joined #u-boot
frieder has joined #u-boot
enok has quit [Ping timeout: 256 seconds]
schroes has quit [Ping timeout: 268 seconds]
tnovotny has joined #u-boot
schroes has joined #u-boot
enok has joined #u-boot
sally_ has joined #u-boot
sally has quit [Ping timeout: 268 seconds]
sally_ is now known as sally
prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #u-boot
sszy has joined #u-boot
enok has quit [Ping timeout: 255 seconds]
logicalerzor has quit [Quit: Connection closed for inactivity]
Clamor has quit [Read error: Connection reset by peer]
Clamor has joined #u-boot
warpme has joined #u-boot
slobodan has joined #u-boot
enok has joined #u-boot
<calebccff>
narmstrong: ahh, I didn't know you already sent that patch
stefanro has joined #u-boot
<narmstrong>
calebccff: yeah sorry I forget to add you in xx
<narmstrong>
*cc
<calebccff>
logicalerzor: I'm not sure how I'd integrate armv7, but we should add v7 support to mach-snapdragon. I'd start by removing "select ARM64" from ARCH_SNAPDRAGON in arch/arm/Kconfig. See doc/board/qualcomm/debugging.rst for the UART config stuff, I guess the MSM UART should work for you. I suspect some things in mach-snapdragon might implicitly assume ARM64 and need adjusting, but it shouldn't be too
<calebccff>
bad to make it build
m5zs7k has quit [Ping timeout: 268 seconds]
m5zs7k has joined #u-boot
slobodan has quit [Ping timeout: 264 seconds]
wooosaiiii1 has joined #u-boot
wooosaiiii has quit [Remote host closed the connection]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
davlefou has quit [*.net *.split]
qschulz has quit [*.net *.split]
manawyrm has quit [*.net *.split]
Danct12 has quit [*.net *.split]
stgl has quit [*.net *.split]
wkennington_ has quit [*.net *.split]
khilman has quit [*.net *.split]
bradfa has quit [*.net *.split]
jkridner has quit [*.net *.split]
pbrobinson has quit [*.net *.split]
mithro has quit [*.net *.split]
georgem has quit [*.net *.split]
Manouchehri has quit [*.net *.split]
qschulz has joined #u-boot
manawyrm has joined #u-boot
davlefou has joined #u-boot
stgl has joined #u-boot
Danct12 has joined #u-boot
khilman has joined #u-boot
wkennington_ has joined #u-boot
mithro has joined #u-boot
jkridner has joined #u-boot
pbrobinson has joined #u-boot
bradfa has joined #u-boot
georgem has joined #u-boot
Manouchehri has joined #u-boot
<sjg1>
Tartarus: Re patchwork integrations, I actually cannot find anything after some effort. I wonder who else we could ask? I suppose I could write something, but...
frieder has quit [Remote host closed the connection]
<xypron>
sjg1: Should we need print a link to FIT documentation at all in SPL? We always very tight on SPL size.
flyback has joined #u-boot
frieder has joined #u-boot
<sjg1>
xypron: I don't think so
Jones42_ has joined #u-boot
Jones42 has quit [Ping timeout: 256 seconds]
cbmuser has quit [Ping timeout: 268 seconds]
mmu_man has quit [Ping timeout: 268 seconds]
cbmuser has joined #u-boot
rvalue- has joined #u-boot
rvalue has quit [Ping timeout: 268 seconds]
<kabel>
Tartarus, xypron: next commit 97da9aea78ab ("arm: separate .data and .text sections of EFI binaries") breaks building turris_omnia_defconfig
rvalue- is now known as rvalue
<xypron>
kabel: We are building that defconfig in CI without problems?
<kabel>
let me try with toolchain from developer.arm.com
<xypron>
kabel: What error did you see?
<kabel>
sigh
<xypron>
kabel: on Ubuntu Oracular: u-boot-with-spl.kwb exceeds file size limit:
<kabel>
it seems to work with toolchain from developer.arm.com
<xypron>
kabel: did you see the same 'exceeds file size limit' before or what other error?
<kabel>
with my gentoo crossdev arm-none-eabi toolchain, I get
<kabel>
arm-none-eabi-ld.bfd: lib/efi_loader/efi_crt0.o: warning: relocation against `_data_size' in read-only section `.text.head'
<kabel>
arm-none-eabi-ld.bfd: read-only segment has dynamic relocations
<kabel>
xypron: what version of gcc does Ubuntu Oracular have?
<kabel>
xypron: maybe the gnueabihf adds some stuff from libgcc that grows the binary to trigger 'exceeds file size limit'
<kabel>
xypron: but no, I actually was able to add some more code into turris_omnia and still not trigger size limit
<kabel>
xypron: with arm-none-eabi
<kabel>
xypron: but maybe gcc-14.1 is causing the 'read-only segment has dynamic relocations'
<kabel>
ok, I shall use the toolchain from developer.arm.com for now
enok has joined #u-boot
<kabel>
fck, the new patches do trigger the limit :(
mmu_man has joined #u-boot
enok has quit [Ping timeout: 255 seconds]
<Tartarus>
sjg1: I know they exist, but they just aren't on the ozlabs one, iirc the kernel graphics people have some stuff hooked up and have done talks about it
<Tartarus>
But I'm not sure that's the first "bot" I'd aim for having hooked up either
Clamor has quit [Ping timeout: 268 seconds]
Clamor has joined #u-boot
Stat_headcrabed has joined #u-boot
enok has joined #u-boot
<sjg1>
So would the first one just be something that checks -next ?
warpme has joined #u-boot
enok has quit [Ping timeout: 264 seconds]
Jones42_ has quit [Ping timeout: 255 seconds]
goliath has quit [Quit: SIGSEGV]
Stat_headcrabed has quit [Quit: Stat_headcrabed]
<marex>
calebccff: can you rebase+resend please ? Then I'll pick it up
<marex>
mkorpershoek: have fun
<mkorpershoek>
thank you, will do!
<mkorpershoek>
marex: I will pick up all the gadget rework you've done when coming back. that seems to give enough review time for others to chime in as well
ukky_ has quit [Ping timeout: 264 seconds]
ukky has quit [Ping timeout: 264 seconds]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sjg1>
Tartarus: oops, forgot tag. So would the first one just be something that checks -next ?
ukky has joined #u-boot
ukky_ has joined #u-boot
<Tartarus>
sjg1: I'm honestly not sure because world build test on patches isn't at the top of my wish list
<Tartarus>
I just kicked azure again to be building everything, and it's about 4 hours, wall-clock
<sjg1>
I believe we can speed up gitlab by running the world builds only on fast machines. But I'm not sure about Azure...does it support providing your own runners / machines?
<sjg1>
Tartarus: Anyway, here I am talking about running things on my lab
<Tartarus>
Not being on the free tier
<Tartarus>
But for your lab, yes, running on every push to master and next would be a starting point
apalos- is now known as apalos
warpme has joined #u-boot
<marex>
mkorpershoek: exactly, that, and in the meantime you should forget about all this and relax
tnovotny has quit [Remote host closed the connection]
mckoan is now known as mckoan|away
yann-kaelig has joined #u-boot
Stat_headcrabed has joined #u-boot
mmu_man has joined #u-boot
<sjg1>
Tartarus: OK, so I should drop the boards which don't work and resend the patches? Do you want to take a look at the others in the series?
<sjg1>
Tartarus: Also need to check I haven't broken the existing hooks, as so far that is only tested in CI / qemu
<Tartarus>
Have you made progress on the labgrid project side of things?
<Tartarus>
That's partly why I was saying you should talk with khilman, I mentioned this to him yesterday on another call and, well, trying to not put too many words in his mouth, but positive reaction? And since new kernelci labs are lava on top of labgrid, yes, someday maybe we can get more external labs to run u-boot tests from time to time if they're already setup for kernelci
<Tartarus>
And yes, it'd probably be good to split your series up a bit, and did you end up figuring out how to integrate the beagleplay ?
<Tartarus>
Something like that is another case where I'm worried it will be tricky to do the build side of things the way you have them so far
Stat_headcrabed has quit [Quit: Stat_headcrabed]
monstr has quit [Remote host closed the connection]
yann-kaelig has quit []
ukky has quit [Quit: Restarting irssi]
ukky has joined #u-boot
Stat_headcrabed has joined #u-boot
<khilman>
sjg1: I'm involved with KernelCI and have slowly switched my KernelCI lab over from custom scripts to labgrid, so very interested in what you're doing with u-boot. Right now, I'm not doing much with the pytest side of things, but have only setup a labgrid "place" for all of my ~70 boards, pretty much all of them running u-boot (but lots of old & vendor u-boots as well since I'm mostly focused on kernel testing.)
ldevulder has quit [Quit: Leaving]
<khilman>
I have a LAVA instance sitting on top of labgrid for KernelCI integration (e.g. LAVA just calls `labgrid-client power cycle` and `labgrid-client console` to control barods)
<khilman>
however, I'm interested in your u-boot work for labgrid, because we rely heavily on u-boot for KernelCI. e.g. KernelCI jobs 1) break into u-boot 2) setup u-boot env 3) DHCP 4) TFTP kernel, DTB, ramdisk into memory 5) boot into freshly downloaded kernel (e.g. booti). LAVA does this currently, but I'd really like to see this "netboot" feature part of the UBootStrategy in labgrid.
<khilman>
It appears labgrid already has the notiion of a TFTP provider etc, but I haven't got to trying that out yet. So if you have, I would love to see how to make that work directly in labgrid for booting custom, locally built kernel/DTB/ramdisk.
frieder has quit [Remote host closed the connection]
<broonie>
FWIW I've got it on my list to move my lab in a similar direction to that.
<sjg1>
khilman: Thanks for the info. I have expanded the UBootStrategy to support writing U-Boot to flash, or sending it over USB, using a recovery and reset buttons as needed. But I have not done anything with networking yet. I suspect it could be added though
Stat_headcrabed has quit [Quit: Stat_headcrabed]
<khilman>
sjg1: I have not had time for lab(grid) stuff for awhile, if you get to it before I do 🤞, I'll be happy to do some testing.
<conchuod>
I am a user of labgrid w/ U-Boot too, for kernel testing with a similar sort of process to Kevin. I don't know much about the labgrid stuff (I was involved with writing something in python, we hired a guy and he replaced it with some custom labgrid strats) but having a more off the shelf strategy seems helpful and I'd try to test things too.
naoki has quit [Quit: naoki]
schroes has quit [Ping timeout: 246 seconds]
schroes has joined #u-boot
mmu_man has quit [Ping timeout: 246 seconds]
<sjg1>
conchuod: khilman: I would like a capable strategy implementation, something which can do whatever is needed, under control of configuration/environment of course. We can build up something that is useful for most use cases and gets a lot of testing
mmu_man has joined #u-boot
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Clamor has quit [Read error: Connection reset by peer]