ikarso has quit [Quit: Connection closed for inactivity]
goliath has quit [Quit: SIGSEGV]
dentalppl has quit [Ping timeout: 245 seconds]
Mis012 has quit [Remote host closed the connection]
Mis012 has joined #u-boot
Mis012- has joined #u-boot
Mis012 has quit [Ping timeout: 240 seconds]
dentalppl has joined #u-boot
thopiekar_ has quit [Ping timeout: 276 seconds]
thopiekar has joined #u-boot
Forty-Laptop has joined #u-boot
naoki has quit [Quit: naoki]
Forty-Laptop has quit [Ping timeout: 255 seconds]
GNUtoo has quit [Ping timeout: 240 seconds]
GNUtoo has joined #u-boot
mmu_man has quit [Ping timeout: 256 seconds]
dentalppl has quit [Quit: Ping timeout: 2 seconds]
GNUtoo has quit [Ping timeout: 240 seconds]
GNUtoo has joined #u-boot
jclsn has quit [Ping timeout: 256 seconds]
jclsn has joined #u-boot
LeSpocky has quit [Ping timeout: 256 seconds]
LeSpocky has joined #u-boot
redbrain has quit [Read error: Connection reset by peer]
redbrain has joined #u-boot
davlefou has quit [Ping timeout: 256 seconds]
davlefou has joined #u-boot
Mis012- has quit [Remote host closed the connection]
Mis012 has joined #u-boot
jaganteki has joined #u-boot
ikarso has joined #u-boot
sukrutb has quit [Ping timeout: 268 seconds]
sukrutb has joined #u-boot
Mis012 has quit [Remote host closed the connection]
Mis012 has joined #u-boot
monstr has quit [Ping timeout: 252 seconds]
sukrutb has quit [Ping timeout: 268 seconds]
<ac_slater>
hey guys, how do I change u-boot's loadaddress and entrypoint to another address?
<ac_slater>
CONFIG_SYS_TEXT_BASE ?
dentalppl has joined #u-boot
<ac_slater>
well I tried that and it seemed to work but didn't run. bleh
<ac_slater>
actually nevermind, sorry for the noise guys
<dentalppl>
np
<ac_slater>
I can't tell how to get `bootm` (and ITB) to load my kernel at a specific address. Apparently there is a requirement for aarch64 to load at a 2mb aligned address
<ac_slater>
https://paste.debian.net/plain/1301137 ... the vendor (xilinx) default is load/entry at 0x8000. I tried to change this to 0x200000 but I think `bootm` is still putting it somewhere wierd? idk
stefanro has joined #u-boot
<ac_slater>
maybe I tell uboot it's not compressed? idk
<ac_slater>
hmm nope
<ac_slater>
trying to boot kernel 5.15.0 using Xilinx's fork of uboot, dated around feb 2022. I have a compressed kernel, Image.gz, ramdisk (with uboot header), and devicetree. I can load these with `booti` just fine. Here is the booti log: https://paste.debian.net/1301161/
<ac_slater>
[ 1.505647] Initramfs unpacking failed: invalid magic at start of compressed archive ... hmm this could be it. My ramdisk is a cpio with a uboot header
<ac_slater>
should it not have the uboot header?
<ac_slater>
it's actually a cpio.gz with a uboot header. Some dude online said to have compression="none" since the kernel can load gzip'd initrd. I guess maybe the uboot header is messing us up here
<ac_slater>
yea damn that seems to be it
mckoan|away is now known as mckoan
<ac_slater>
maybe spoke too soon, I use buildroot and it does: `mkimage -A arm64 -T ramdisk -C none -d rootfs.cpio rootfs.cpio.uboot`. Buildroot specificallys sets compression to none
<ac_slater>
the option that does this says "add a u-boot header so the cpio root filesystem. Allows the initramfs to be loaded with the bootm command"
<ac_slater>
tried to boot an initrd with and without `mkimage` same "invalid magic at start of compressed archive"
<ac_slater>
actually that was it... it doesn't need the uboot header
<ac_slater>
jeez
dentalppl has quit [Ping timeout: 260 seconds]
dentalppl has joined #u-boot
ldevulder has joined #u-boot
prabhakarlad has joined #u-boot
ezulian has joined #u-boot
slobodan has joined #u-boot
<f_>
Hey all, working on the website again.
<f_>
dsimic: looking again at your suggestions, <dsimic> the opening paragraphs are good, we should just make them flow a bit better, by having it all formatted and reworded a bit like this: https://termbin.com/dh0t
<f_>
dsimic: that termbin.com link returns 404, seems like it expired :P
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
goliath has joined #u-boot
Hammdist has quit [Quit: Client closed]
dentalppl has joined #u-boot
dsimic has quit [Ping timeout: 256 seconds]
dsimic has joined #u-boot
mmu_man has quit [Ping timeout: 264 seconds]
mmu_man has joined #u-boot
persmule has quit [Quit: Leaving]
persmule has joined #u-boot
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
norton has joined #u-boot
jybz has quit [Excess Flood]
jybz has joined #u-boot
slobodan_ has joined #u-boot
dentalppl has quit [Changing host]
dentalppl has joined #u-boot
slobodan has quit [Ping timeout: 246 seconds]
slobodan has joined #u-boot
slobodan_ has quit [Ping timeout: 255 seconds]
Clamor has joined #u-boot
mmu_man has quit [Ping timeout: 264 seconds]
jaganteki has quit [Quit: Client closed]
Hammdist has joined #u-boot
mmu_man has joined #u-boot
Clamor has quit [Ping timeout: 260 seconds]
dentalppl has quit [Ping timeout: 256 seconds]
<f_>
Alright.
<f_>
Tartarus, sjg1, marex: I'll try sending patches tomorrow or the day after, unless one of you or someone else still wants to add one last thing :)
prabhakarlad has quit [Quit: Client closed]
<f_>
Until then, I'll continue working on Amlogic RE. Cheers!
<sjg1>
f_: Nothing from me. We can always adjust it later as needed
<f_>
Yeah I can always do that, indeed.
<f_>
(I, or someone else)
Hammdist has quit [Quit: Client closed]
Clamor has joined #u-boot
ldevulder has quit [Quit: Leaving]
mmu_man has quit [Ping timeout: 268 seconds]
prabhakarlad has joined #u-boot
hanetzer has quit [Quit: WeeChat 4.1.1]
<marex>
sjg1: I'll reply /wrt fitImage stuff at some point next week
<marex>
sjg1: basically I'm already using it in deployment with separate DT and multiple DTO entries
<marex>
sjg1: base DT for board, DTOs for expansion modules, application of DTOs is done via script which passes bootm $loadaddr#basedt#dto1#dto2...
mmu_man has joined #u-boot
jmasson has quit []
<Clamor>
Tartarus: hello! So what should we do with pinmux patches?
stefanro has quit [Quit: Leaving.]
<Tartarus>
Clamor: My general rule of thumb is to wait 2 weeks between posting and putting patches in a tree somewhere
<Clamor>
So 3 more days
<Tartarus>
They can go in -next soon, and you might want to play with Sumit's series to bring in upstream device trees as-is and see how they can/can't work for the tegra platforms you're working on
<Clamor>
Oh, I am not asking if you can pick them into next. I am asking if they can be picked at all.
<Clamor>
TBH, linux device trees should work with u-boot perfectly fine. But in the case of tegra, well, u-boot trees are a bit more advanced.
<Tartarus>
Yes, I would encourage you to see what the kernel people really won't take at this point, again.
<Clamor>
This is a cursed loop. I cannot develop linux without bootloader and I cannot add bootloader support without linux guys approval.
<Tartarus>
Right, and we're OK taking things in U-Boot first with the understanding that if they have to change once merged to Linux, U-Boot adapts
mripard has quit [Quit: mripard]
Hammdist has joined #u-boot
<Clamor>
Tartarus: u-boot has no endpoint system, linux uses for drm, correct?
mckoan has quit [Read error: Connection reset by peer]
mckoan has joined #u-boot
Clamor has quit [Ping timeout: 276 seconds]
IoT-Maker has joined #u-boot
Clamor has joined #u-boot
<IoT-Maker>
printenv give me this info https://bpa.st/IJCQ how can i load manually the jffs2 filesystem?
prabhakarlad90 has joined #u-boot
prabhakarlad41 has joined #u-boot
prabhakar73 has joined #u-boot
prabhakarlad41 has quit [Client Quit]
prabhakar73 has quit [Client Quit]
prabhakarlad53 has joined #u-boot
prabhakar83 has joined #u-boot
prabhakarlad53 has quit [Client Quit]
prabhakar83 has quit [Client Quit]
mckoan is now known as mckoan|away
prabhakar has quit [Ping timeout: 256 seconds]
prabhakarlad has quit [Ping timeout: 250 seconds]
prabhakarlad90 has quit [Ping timeout: 250 seconds]
<IoT-Maker>
https://bpa.st/XR2A this are the commands in this Marvell shell https://bpa.st/EZ3Q . Is it possible to load the jffs2 filesystem without booting vxworks?
prabhakarlad has joined #u-boot
prabhakar has joined #u-boot
gsz has joined #u-boot
mmu_man has quit [Ping timeout: 276 seconds]
<marex>
IoT-Maker: try 'help jffs2' ?
<marex>
IoT-Maker: mainline U-Boot does have cmd/jffs2.c
mmu_man has joined #u-boot
<IoT-Maker>
marex: it is a Marvell custom U-Boot version. I posted the available command list. No jffs2 command, only fatload or fsload. The printenv show a fsload command with variables.
<f_>
IoT-Maker: Is the manufacturer providing U-Boot source or not?
<IoT-Maker>
f_: The device is a Drobo B810i. The manufacturer filled for chapter 11 last year and this year for chapter 7. So he's no more providing anything. I only have this device and a firmwarefile trying to get the box working after failed firmwareupdate (done by the owner).
<f_>
Insane manufacturer disappearing :X
<f_>
Anyway you could try loading a kernel with fatload and jumping to it
<IoT-Maker>
gui not present, only vxworks (maybe not finished boot process) and a linux shell on a different uart console
<f_>
(mainline could work perhaps)
<f_>
Then wipe everything and use mainline u-boot!
<marex>
IoT-Maker: ask vendor for support with their modifications ?
<marex>
f_: you beat me to it
<f_>
marex: haha
vagrantc has joined #u-boot
<IoT-Maker>
i thought i could just flash the firmwarefile. But it's a tricky device. JTAG didn't work. Can't reset the CPU or maybe the ARMADA XP ARM7 SoC need some special config values.
<IoT-Maker>
Now i'm trying to use this Marvell kryten-uboot-2.33 version of U-Boot
f_ has quit [Remote host closed the connection]
hanetzer has joined #u-boot
ikarso has quit [Quit: Connection closed for inactivity]
sukrutb has joined #u-boot
f_ has joined #u-boot
ikarso has joined #u-boot
gsz has quit [Ping timeout: 260 seconds]
<Clamor>
clk_prepare_enable is intentionally a dummy?
<Clamor>
marex: maybe you are aware?
f_ has quit [Remote host closed the connection]
f_ has joined #u-boot
<marex>
what ?
<Clamor>
Which function is preferred clk_prepare_enable or clk_enable?
<CounterPillow>
clk_enable assumes you've prepared the clk beforehand
<Clamor>
It seems that not in uboot
<marex>
the behavior is the same as linux
<marex>
prepare in probe, enable as needed
<marex>
CounterPillow is right
<Clamor>
But I have got a nit because I used prepare_enable
qqq has joined #u-boot
<Clamor>
Not just enable
<Clamor>
Lucky me
rockosov has quit [Quit: WeeChat 3.4-dev]
dentalppl has joined #u-boot
Clamor has quit [Ping timeout: 268 seconds]
mmu_man has quit [Ping timeout: 246 seconds]
<Forty-Bot>
marex: there's no clk_prepare in U-Boot since we don't have critical sections