flyback has quit [Remote host closed the connection]
flyback has joined #u-boot
mmu_man has quit [Ping timeout: 260 seconds]
mmu_man has joined #u-boot
jclsn has quit [Ping timeout: 256 seconds]
jclsn has joined #u-boot
vagrantc has quit [Quit: leaving]
mmu_man has quit [Ping timeout: 258 seconds]
jclsn has quit [Ping timeout: 256 seconds]
jclsn has joined #u-boot
Stat_headcrabbed has joined #u-boot
mtoy has quit [Ping timeout: 260 seconds]
mtoy has joined #u-boot
_whitelogger has joined #u-boot
persmule has quit [Remote host closed the connection]
<shadows>
Tartarus: I don't know how to do reStructured text links, when searching for information how to do this it is not really landing with my brain :-|
_whitelogger has joined #u-boot
haritz has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
jclsn has quit [Ping timeout: 260 seconds]
jclsn has joined #u-boot
chewitt has joined #u-boot
fgarcia has joined #u-boot
Jones42 has joined #u-boot
jclsn has quit [Ping timeout: 256 seconds]
weirdtreething has quit [Remote host closed the connection]
weirdtreething has joined #u-boot
jclsn has joined #u-boot
jclsn has quit [Ping timeout: 245 seconds]
jclsn has joined #u-boot
Stat_headcrabbed has quit [Remote host closed the connection]
jclsn has quit [Ping timeout: 248 seconds]
jclsn has joined #u-boot
Sout_ has quit [Server closed connection]
Sout_ has joined #u-boot
goliath has joined #u-boot
ikarso has quit [Quit: Connection closed for inactivity]
jclsn has quit [Ping timeout: 248 seconds]
jclsn has joined #u-boot
Stat_headcrabbed has joined #u-boot
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
slobodan has joined #u-boot
jclsn has quit [Ping timeout: 256 seconds]
jclsn has joined #u-boot
mmu_man has joined #u-boot
tlwoerner has quit [Ping timeout: 260 seconds]
tlwoerner has joined #u-boot
jclsn has quit [Ping timeout: 260 seconds]
jclsn has joined #u-boot
slobodan_ has joined #u-boot
slobodan has quit [Ping timeout: 245 seconds]
fsinger has quit [Server closed connection]
fsinger has joined #u-boot
dsimic has quit [Ping timeout: 258 seconds]
dsimic has joined #u-boot
haritz has joined #u-boot
haritz has joined #u-boot
haritz has quit [Changing host]
sng has quit [Ping timeout: 256 seconds]
jclsn has quit [Ping timeout: 245 seconds]
jclsn has joined #u-boot
npcomp has quit [Server closed connection]
npcomp has joined #u-boot
mmu_man has quit [Ping timeout: 248 seconds]
<Ermine>
tinker-rk3288 defconfig states that environment is stored on mmc at offset 0x3f8000 , which is roughly 4 megabytes. Given that u-boot itself is written at offset of 32 kilobytes and is 8.6 megabytes big, it would cover environment zone. I guess u-boot's image has space for the environment?
<Ermine>
or saveenv will basically damage u-boot ?
persmule has joined #u-boot
jclsn has quit [Ping timeout: 248 seconds]
jclsn has joined #u-boot
mmu_man has joined #u-boot
ikarso has joined #u-boot
chili-b has quit []
jclsn has quit [Ping timeout: 248 seconds]
jclsn has joined #u-boot
sng has joined #u-boot
<urja>
..... what happened to make u-boot as big as the linux kernel? or are you measuring the elf file with debug info etc?
<Ermine>
no, it's u-boot-rockchip.bin which I usually flash
<urja>
ah yes
<urja>
and yeah i also have that file in my old u-boot tree, and yeah i think it includes the environment (atleast, u-boot proper (u-boot.bin) is only 440k vs 8.4M for the rockchip one...)
fgarcia has quit [Ping timeout: 260 seconds]
fgarcia has joined #u-boot
fgarcia has quit [Max SendQ exceeded]
fgarcia has joined #u-boot
fgarcia has quit [Max SendQ exceeded]
<urja>
but yeah my old u-boot tree is from 2020 so i wont guess more on how it works now :P
<urja>
but a quick hexdump says u-boot-rockchip.bin is mostly empty, so it is putting things (like the SPL and the dtb) at their correct positions... and just padding between them
fgarcia has joined #u-boot
fgarcia has quit [Max SendQ exceeded]
fgarcia has joined #u-boot
monstr has joined #u-boot
<shadows>
urja: 'binwalk' python language utility can be useful to quickly discover offsets and locations, and extract portions easily. The command line arguments and functionality changes slightly between 'binwalk' that is packaged by most distros, and the re-write 'binwalk' that is from the same project author with more features and in a compiled language.
<marex>
Ermine: look at the *map files , I think image.map , it contains the layout of the image generated by binman
monstr has quit [Ping timeout: 256 seconds]
tpw_rules has quit [Ping timeout: 258 seconds]
jclsn has quit [Ping timeout: 248 seconds]
goliath has quit [Quit: SIGSEGV]
goliath has joined #u-boot
jclsn has joined #u-boot
tpw_rules has joined #u-boot
chili-b- has joined #u-boot
<chili-b->
hi, i'm having some issues since upgrading to debian 13 on my rockpro64. i'm asking here because i'm wondering if the problem is related to u-boot. currently, there is no display output and the LED on my ssd doesn't come on after powering the system on
<chili-b->
does this suggest that u-boot on the device is not working? i understand it could also just be that the device tree is wrong
<shadows>
chili-b-: is it the release of U-Boot that ships with Debian 13 Trixie?
rfs613 has quit [Server closed connection]
<chili-b->
shadows, my understanding is that i have u-boot installed to the beginning of the drive, i.e. if i examine the partitions on the device it says there is some "unallocated" space at the start, but that's actually occupied by u-boot
<chili-b->
do i need to update this somehow?
rfs613 has joined #u-boot
<marex>
chili-b-: linux should be independent of U-Boot, so likely a kernel bug
<shadows>
I've only got to be familiar with the RISC-V devices where U-Boot is located in SPI NOR flash typically
<marex>
chili-b-: you could try to boot the older kernel using current u-boot (and vice versa) and see if that changes anything, then you would know if this is a u-boot problem
<chili-b->
marex, i've done this before but remind me: how do I replace just the u-boot at the start of the drive?
<shadows>
"When powered on, ROCKPro64 will attempt to find a bootloader in the following order: " "Onboard 128MB SPI Flash","Removable eMMC","microSD card"
<chili-b->
gentoo wiki shows writing 2 files to storage with dd, but debian only ships one
<chili-b->
they only provide "firmware.rockpro64-rk3399.img.gz"
<shadows>
so there is an SPI Flash involved, and you would want to update U-Boot to something at least as recent as what ships with Debian 13 Trixie
<chili-b->
okay, i will try that
<chili-b->
IIRC i'm not doing anything with the SPI, i'm just installing u-boot to the start of my storage device
<chili-b->
i have a firmware image from debian which is meant to be written to the start of the drive, remind me: will dd stop writing once it reaches the end of the file? i just want to overwrite the u-boot without breaking my filesystem
<shadows>
chili-b-: you can tell it the count of how many blocks (of a certain size) to write
<shadows>
otherwise it will write to the length of the input
<chili-b->
the input is already the length i want, i just want assurance that dd is not going to do anything beyond that point
<chili-b->
to reiterate: the storage device has some "unallocated" space before the beggining of the filesystem partition
<marex>
chili-b-: maybe debian wiki has some how-to ?
<marex>
chili-b-: they have some flash...something script to install bootloader
<chili-b->
the debian documentation for doing this is very, very bad.
<shadows>
however looking at this I think now that what we lack is information, you should obtain a UART serial adapter because they are not expensive
<shadows>
without such information we do not know what the problem is or is not
<shadows>
anyways for learning, chili-b- you may extract the content of that Debian package `dpkg -x packagename.deb outputdirectoryname` and read share/doc/u-boot-rockchip/README.Debian which answers your question about dd hopefully
<chili-b->
> you should obtain a UART serial adapter because they are not expensive
<chili-b->
yes, i should
<chili-b->
thanks for the help. i think i know what i have to do. i'm making a copy of everything because i've destroyed my partition table in the past. i will come back if i need more help
<shadows>
I have had good success with CP2102N chipset, from vendor Adafruit Store there's one for $6USD that has USB-C connector which I find useful p/n 5335 "CP2102N Friend - USB to Serial Converter" yep. Good luck
<chili-b->
i screwed up and broke the filesystem, good thing i copied everything. to make sure I get it right this time: I need to first create a truncated image of the firmware by skipping the first 64 blocks, then I need to use seek=64 when i write it to the actual drive
<shadows>
yes, this is described in the document I mention.
Guest854 has quit [Quit: Ping timeout (120 seconds)]
Guest854 has joined #u-boot
<chili-b->
i saw that, the pine64 docs suggest using a different image which appears to be a combination of everything to copy to the start of the drive and i screwed up using that. i am just going to follow the README.Debian normally this time.
persmule has quit [Remote host closed the connection]
<chili-b->
okay, i'm getting some display output now. i think something incorrectly modified u-boot during the distribution upgrade (either that or the u-boot was incompatible with the kernel version)
<chili-b->
now it's stuck at "starting kernel"
<shadows>
time for UART adapter.
<chili-b->
i've been messing with /boot on the os install, so this is probably my fault, but are there any other reasons this could happen?
<chili-b->
i will be placing an order shortly
jclsn has quit [Ping timeout: 256 seconds]
monstr has quit [Remote host closed the connection]
jclsn has joined #u-boot
persmule has joined #u-boot
persmule_ has joined #u-boot
persmule has quit [Remote host closed the connection]
fgarcia has quit [Ping timeout: 260 seconds]
fgarcia has joined #u-boot
soxrok2212 has quit [Server closed connection]
soxrok2212 has joined #u-boot
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
mmu_man has quit [Ping timeout: 258 seconds]
mmu_man has joined #u-boot
<chili-b->
so, following the notes in README.Debian from that package didn't work... that build of u-boot hangs after starting the kernel (i tried several kernels)
<chili-b->
i went back and tried the image linked from the pine64 wiki and copied it properly this time and it gets into the kernel
<chili-b->
currently my device trees are wrong, so it doesn't get any farther than that
flom84 has joined #u-boot
flom84 has quit [Remote host closed the connection]
<marex>
chili-b-: do you know who did the debian port for this device ?
slobodan_ has quit [Ping timeout: 260 seconds]
goliath has quit [Quit: SIGSEGV]
<shadows>
chili-b-: there's an "internal" devicetree used by U-Boot, which might be very different than what is needed by the version of Linux kernel you are booting to; so... typically there is some action either from U-Boot or in a secondary bootloader to prepare the devicetree in memory from the corresponding dtb on-disk
<shadows>
notable though is U-Boot recently has many builds already using upstream Linux kernel devicetree directly at compile time, and so the "internal" devicetree is very similar or identical to what is needed by recent Linux kernel
<shadows>
that is known as OF_UPSTREAM and if your board U-Boot was built this way, just disable extra prepare devicetree action and boot to some recent Linux kernel should be successful
slobodan has quit [Read error: Connection reset by peer]
slobodan has joined #u-boot
<chili-b->
thank you. marex, no i don't know who did the debian port, but that's the next thing i'm figuring out because it looks like my problems with u-boot are all solved.
<chili-b->
The system gets past u-boot (i see the graphics mode change on the display (probably not the right terminology, but the font-size changes and i see messages if i add/remove devices)). I believe the system is now properly booting and my problems are now debian problems. Does it sound like I'm missing anything?
<shadows>
chili-b-: the advice at that forum seems to be newer than the U-Boot release packaged for Debian 13 Trixie, so when your UART serial adapter arrives try that
<marex>
chili-b-: get a serial console cable, then you will surely know what's going on (assuming you dont have one)
<marex>
chili-b-: and the author of the debian port, that's something you can dig out of git log on debian u-boot git repo (on salsa.debian.org)
<chili-b->
is there any way i can change the kernel cmdline from u-boot (either interactively at start or by changing some files on the system)?
<chili-b->
i just want to see if there's some output i'm missing if something like quiet is set
<shadows>
chili-b-: yeah, you can set the boot parms, specify the initramfs, etc.
<marex>
chili-b-: setenv bootargs "content as needed"
<chili-b->
marex, this overrides the kernel cmdline, correct?
<shadows>
Debian tends to use Grub2 as a secondary bootloader
<marex>
depends on your setup, but most likely yes
<xypron>
Hello Tartarus, I cannot find any RISC-V instance of `git grep -ni fdt_addr | grep -i ffff` in origin/master. Hence Tuesday's question is unclear to me.
mmu_man has quit [Ping timeout: 260 seconds]
<shadows>
xypron: host I use for IRC reboot and I lose this context, remind what was it we are searching for?
<xypron>
Tartarus wrote: "Oh, xypron, or anyone else with a riscv platform handy, can you see if you can boot when removing fdt_addr=0xffff... from the environment, and if not, figure out what's broken on the riscv side and fix it?"
<shadows>
xypron: the only reference I see is qemu-riscv and one of the andes tech docs
mmu_man has joined #u-boot
<xypron>
shadows: Where did you see it for QEMU?
<shadows>
grep -rni fdt'.*'high | grep -i risc
<shadows>
include/configs/qemu-riscv.h refers to fdt_high
<shadows>
oh I'm searching something else, let me adjust...
<shadows>
I see Tom mention '0xffff...' and think this must be fdt_high, but what they said was fdt_addr
<shadows>
xypron: the other source of these values changing will be uEnv.txt from vendors. From context though asking if we have this platform handy, I am guessing that the question is something to do with not having the platform i.e. qemu
<shadows>
xypron: I'll bet $1usd dollar what Tom complains about is fdt_high and initrd_high being set in include/configs/qemu-riscv.h
<shadows>
maybe also include/configs/sifive-unleashed.h and include/configs/voyager.h i.e.
<xypron>
shadows: boot_relocate_fdt() is only invoked when booting via the Linux legacy entry point or when using FIT images. Ubuntu uses kernels with EFI_ZBOOT, so this is not relevant here.
<xypron>
shadows: I don't have access to any of these boards.
<shadows>
on the boards we do have access to fdt_high and initrd_high are set with the vendor BSP, and not set with mainline U-Boot; pretty certain about this.
<shadows>
like you I don't know what else the complaint is referring to, taken literally as-is it is not found in the codebase fdt_addr=0xffff...