<hays>
I am not seeing saveenv in my u-boot menu. is this something that has to be turned on?
<hays>
is there another way to save?
<Tartarus>
it's under cmd
thopiekar has quit [Ping timeout: 248 seconds]
thopiekar has joined #u-boot
Wouter010067044 has joined #u-boot
qschulz_ has joined #u-boot
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #u-boot
Net147 has quit [Changing host]
Net147 has joined #u-boot
Wouter01006704 has quit [*.net *.split]
qschulz has quit [*.net *.split]
Patater has quit [*.net *.split]
wooosaiiii has quit [*.net *.split]
redbrain has quit [*.net *.split]
Wouter010067044 is now known as Wouter01006704
<hays>
Tartarus: you don't happen to know where I can find documentation about the first 512 bytes of the disk for an amlogic s922x device would you? heh
Patater has joined #u-boot
wooosaiiii has joined #u-boot
redbrain has joined #u-boot
<hays>
OK, sorry--- Is this output from U-boot? I am guessing not: LOOP:1;EMMC:800;NAND:81;SD?:20000;USB:8;LOOP:2;EMMC:800;NAND:81;SD?:20000;USB:8;LOOP:3;EMMC:800;NAND:81;SD?:20000;USB:8;LOOP:4;EMMC:800;NAND:81;SD?:20000;USB:8;LOOP:5;EMMC:800;NAND:81;SD?:20000;USB:8;LOOP:6;EMMC:800;NAND:81;SD?:20000;USB:8;LOOP:7;
alpernebbi has quit [Quit: alpernebbi]
alpernebbi has joined #u-boot
naoki has quit [Quit: naoki]
naoki has joined #u-boot
<jpsollie>
Tartarus: sorry for the late reply: v2022.04 gives me this (seems to be in an endless loop):
<jpsollie>
but I can work with that ... there's probably an easy fix
Leopold has quit [Ping timeout: 252 seconds]
rockworld has joined #u-boot
<rockworld>
does anyone here is familiar with u-boot ?
<rockworld>
:)
<rockworld>
well, I buyed the new orangepi 5 and it looks like it use u-boot instead of a regular bios, im wondering how can I make it boot from usb instead of microssd
ldevulder_ has joined #u-boot
ldevulder has quit [Ping timeout: 248 seconds]
Leopold has joined #u-boot
persmule has quit [Remote host closed the connection]
<clarity>
I don't think mkimage -l validates hashes
<clarity>
it just prints whatever is in there, correct or not
<clarity>
.. I think
<clarity>
Yea it just prints the stored hashes
<clarity>
Nothing changes if you dd random bytes in the middle of the itb
<marex>
hmmm, then I do not know if there is a host tool for that
naoki has quit [Quit: naoki]
<jpsollie>
does anybody here know whether the psci checker on linux has anything to do with u-boot's psci?
<jpsollie>
psci_checker: CPU 2 suspend test results: success 1, shallow states 9, errors 0
<jpsollie>
but after "psci_checker: PSCI checker completed" the device doesn't boot anymore
akaWolf has quit [Ping timeout: 268 seconds]
Net147 has quit [Quit: Quit]
Net147 has joined #u-boot
Net147 has joined #u-boot
Net147 has quit [Changing host]
Ava has joined #u-boot
Ava has quit [K-Lined]
<broonie>
jpsollie: If it's running on a system with u-boot providing PSCI then it'll be that PSCI implementation that it's checking.
clarity has quit [Ping timeout: 248 seconds]
clarity has joined #u-boot
vulpes2[m] has quit [Quit: Bridge terminating on SIGTERM]
vitali64[m] has quit [Quit: Bridge terminating on SIGTERM]
elvishjerricco has quit [Quit: Bridge terminating on SIGTERM]
LinuxHackerman has quit [Quit: Bridge terminating on SIGTERM]
sylensky[m] has quit [Quit: Bridge terminating on SIGTERM]
samueldr has quit [Quit: Bridge terminating on SIGTERM]
kallisti5[m] has quit [Quit: Bridge terminating on SIGTERM]
mvaittin has quit [Quit: Bridge terminating on SIGTERM]
maxim[m]1 has quit [Quit: Bridge terminating on SIGTERM]
Intel[m] has quit [Quit: Bridge terminating on SIGTERM]
hthiery has quit [Quit: Bridge terminating on SIGTERM]
matthias_bgg has quit [Read error: Connection reset by peer]
matthias_bgg has joined #u-boot
ladis has joined #u-boot
samueldr has joined #u-boot
epoll has quit [Ping timeout: 246 seconds]
naoki has joined #u-boot
epoll has joined #u-boot
LinuxHackerman has joined #u-boot
mvaittin has joined #u-boot
vitali64[m] has joined #u-boot
sylensky[m] has joined #u-boot
elvishjerricco has joined #u-boot
vulpes2[m] has joined #u-boot
maxim[m] has joined #u-boot
hthiery has joined #u-boot
kallisti5[m] has joined #u-boot
Intel[m] has joined #u-boot
mmu_man has joined #u-boot
<jpsollie>
broonie: and so does that mean the PSCI from u-boot is not completely functional?
naoki has quit [Quit: naoki]
mvaittin has quit [Ping timeout: 246 seconds]
kallisti5[m] has quit [Ping timeout: 248 seconds]
vulpes2[m] has quit [Ping timeout: 248 seconds]
LinuxHackerman has quit [Ping timeout: 248 seconds]
vitali64[m] has quit [Ping timeout: 248 seconds]
maxim[m] has quit [Ping timeout: 248 seconds]
sylensky[m] has quit [Ping timeout: 246 seconds]
samueldr has quit [Ping timeout: 246 seconds]
hthiery has quit [Ping timeout: 252 seconds]
Intel[m] has quit [Ping timeout: 252 seconds]
elvishjerricco has quit [Ping timeout: 264 seconds]
<marex>
u-boot psci implementation ? on which soc ?
mncheck has joined #u-boot
<jpsollie>
rk3328
<broonie>
jpsollie: Or doing something the kernel doesn't deal with very well
matthias_bgg has quit [Ping timeout: 252 seconds]
<jpsollie>
I'm confused ... u-boot builds a layer between the hardware and linux kernel, right?
<jpsollie>
so, is this layer malfunctioning? of the hardware itself?
sylensky[m] has joined #u-boot
lucascastro has joined #u-boot
justache is now known as deliriumt
deliriumt is now known as justache
maxim[m] has joined #u-boot
mvaittin has joined #u-boot
<marex>
hanetzer: ^ was that the rockchip you worked with ?
hthiery has joined #u-boot
<marex>
qschulz_: ^
vitali64[m] has joined #u-boot
elvishjerricco has joined #u-boot
LinuxHackerman has joined #u-boot
vulpes2[m] has joined #u-boot
<qschulz_>
marex: sorry no, rk3399, px30, eventually rk3368 but nothing else atm
qschulz_ is now known as qschulz
kallisti5[m] has joined #u-boot
samueldr has joined #u-boot
<jpsollie>
this rockchip has a few other issues: the linux kernel doesn't seem to activate the mmc
Intel[m] has joined #u-boot
<jpsollie>
and the misc init (applying the ethernet mac) isn't working either
<jpsollie>
and this is only for 2022.4, currently it doesn't work at all anymore
torez has joined #u-boot
lucascastro has quit [Remote host closed the connection]
<sjg1>
xypron: Do you have any interest in the UI side of firmware? Something like the BIOS screen we see on x86 machines
CounterPillow has joined #u-boot
dgilmore has quit [Ping timeout: 252 seconds]
<CounterPillow>
Hello! Is there some low limit to the maximum size an fdt can be? If so, how low is it? I'm currently running into an issue with turning on CONFIG_OF_LIBFDT_OVERLAY=y, where adding that option makes it so the board doesn't get out of SPL
<CounterPillow>
My hypothesis right now after much frustrating debugging is that my device tree simply gets too big with the symbols for overlaying compiled in
paulbarker has quit [Ping timeout: 252 seconds]
<CounterPillow>
whether that hypothesis holds any water would be tested by me finding the limit of the size somewhere, and rearranging things (fdt_addr_r?) to where it can take up more space
dgilmore has joined #u-boot
paulbarker has joined #u-boot
rvalue has quit [Ping timeout: 252 seconds]
redbrain has quit [Read error: Connection reset by peer]
naoki has joined #u-boot
redbrain has joined #u-boot
rvalue has joined #u-boot
<hays>
Tartarus: saveenv is not under cmd--there is no cmd
<hays>
to be honest im not sure where its getting its environment
<hays>
I think this 245:CONFIG_DISTRO_DEFAULTS=y
<hays>
at any rate there appears to be a race condition with emmc where it loads the bootloader fine, but then i can't find the partitions and fails to boot. if I run bootcmd from the prompt it boots
<Tartarus>
CMD_SAVEENV is a thing, where do you have env set to?
<Tartarus>
And, re emmc, interesting
<Tartarus>
narmstrong: That's an amlogic soc on that chip, any ideas/
<hays>
Tartarus: I think maybe its not stored anywhere? I get a message saying it comes from nothing when I boot
<Tartarus>
Ah, then yeah, no saveenv
<hays>
narmstrong: I have patched 2023.01 with the n2l patchset you did
<narmstrong>
There’s no stable space for uboot env
<hays>
narmstrong: any idea about unavailable emmc?
<hays>
Im trying to insert some kind of delay but this is proving difficult
<narmstrong>
hays: can you explicit your issue ? Do you have a problem accessing emmc from uboot ?
<hays>
narmstrong: when I boot, the device usually goes to the uboot command prompt, but then run bootcmd allows it to continue. I am getting the following message:
<hays>
MMC Device 2 not found
<hays>
no mmc device at slot 2
<hays>
i can post full logs
<narmstrong>
Emmc should be at slot 1, sdcard at slot 0
<hays>
if I abort the sequence (press a key) and wait 5 seconds I still get the issue
<narmstrong>
let me get my n2l and boot it :-)
<hays>
if abort and do run bootcmd; run bootcmd it boots
<narmstrong>
hmm, what's the difference between `if I abort the sequence (press a key) and wait 5 seconds I still get the issue` & `if abort and do run bootcmd; run bootcmd it boots`
<narmstrong>
`wait 5 seconds I still get the issue` please explicit ?
<marex>
qschulz: ah, ack, thanks
<marex>
qschulz: btw do these rockchips have any CAN/CANFD ?
<qschulz>
marex: no, but we'll have one with CANFD soon
<marex>
qschulz: oh ?
<marex>
qschulz: which one ?
<qschulz>
I mean, the RK3588 have one, so the RK3588EVB and Rock 5B should have it (if exposed)
<hays>
narmstrong: case 1 / I press spacebar and wait 5 seconds, then run bootcmd... if I do this, I get the same behavior. It fails and I get u-boot prompt.
<hays>
case 2 / I press spacebar and type: "run bootcmd; run bootcmd" <-- this boots up
<narmstrong>
this is the output I have with the eMMC HardKernel sent me with the N2L
<hays>
narmstrong: the emmc I use on multiple boards but I did flash the whole emmc
<hays>
I can try a different tree. it might take me a while because i am building this in the cloud
<xypron>
sjg1: For me the reference for a GUI would be EDK II. Part of such an experience is offered by the eficonfig command which can be used in conjunction with bootmenu.
<narmstrong>
hays: the eMMC I used is marked "eMMC v0.5", I have another one with "eMMC v0.4" I can try
<qschulz>
they don't specify it's CANFD, but the wording is identical to RK3568 where they say it supports CANFD
<marex>
qschulz: is that also 3x CAN or just once ?
<marex>
sorry, I am new to all this rockchip stuff
<marex>
also, is there a driver ?
<qschulz>
marex: there's always a driver... downstream at least :)
<qschulz>
3 as well yes according to the address mapping
<marex>
well that's good enough
<marex>
qschulz: thanks !
<qschulz>
if it works that's another story though :)
<qschulz>
haven't tested yet so can't tell
<qschulz>
marex: lower your expectations in terms of docs if you're coming from NXP (at least from the imx6 era)
<qschulz>
but it's actually quite decent
<qschulz>
and RK3588 (and I assume RK3568) BSP is based on an Android 5.10 kernel, so it's not THAT bad :)
<marex>
qschulz: I am actually coming from renesas, so when working with nxp I have to lower my expectations ;-D
<qschulz>
and we have Kever from Rockchip who reviews and contributes to U-Boot and the kernel so that's a good thing already :)
<marex>
qschulz: I did indeed hear good things about rockchip upstream support , the downstream BSPs are almost always a devastated wasteland or toxic swamp, no surprises there
<qschulz>
well and I forgot Heiko obviously, long time contributor and maintainer to the Rockchip support :)
<hanetzer>
marex: rk3288/rk3399; afk and just caught this because of a wallet run. ping me later (or whoever it was), say 6-7hr from now
<qschulz>
marex: at least you didn't have to deal with a 360 pages long FULL datasheet from Amlogic :D
<qschulz>
I assume narmstrong and folks from baylibre had access to more when working on upstream, but that was quite depressing at my previous company :)
<narmstrong>
qschulz: in fact, no :-p we had a few more docs but not much more...
<qschulz>
oh wow
<narmstrong>
I won't say the same for the platform I'm working for, I have access to allmost everything
naoki has quit [Ping timeout: 260 seconds]
<marex>
qschulz: you are climbing up in the world ;-/
<qschulz>
qcom right?
<qschulz>
marex: dealt with Allwinner and NXP in the past, then moved to Amlogic and Mediatek, now to Rockchip :)
<narmstrong>
but the ultimate was for my first job, I was in the hw design team and I had access to the VHDL and developed the kernel support in the same time they designed the HW, this was awesome
<qschulz>
I guess that's what SoC vendors do too
<marex>
qschulz: so different kinds of awful, yeah
<narmstrong>
yep, making hw and sw team collaborate is how it's done now, Apple does this
<qschulz>
marex: i've heard good thing about BSP from Renesas, but didn't even know they actually had SoCs... this is pretty new no?
<qschulz>
narmstrong: wondering where you would put upstreaming in there
<marex>
qschulz: yeah, like 15 years or so
<qschulz>
marex: very new to the market then :p
<marex>
some of them were suggested to be removed recently by hch, the SH ones :)
<qschulz>
narmstrong: I guess I should ask intel folks how they do it :)
<narmstrong>
qschulz: you can't, this is why ther's special upstreaming teams in linaro ^^
mmu_man has quit [Ping timeout: 252 seconds]
<marex>
they did 3 generations of ARM SoCs since (well, more, depending how you count)
<narmstrong>
in a perfect world, hw design and upstreaming would be done at the same time
<narmstrong>
but ST did this actually
<narmstrong>
the stm32mp was upstreamed way before it was officially announced
<narmstrong>
but the stm32mp is quite simple, the Snapdragon 8 Gen2 would be like a Jet Fighter and an STM32MP a Citroen 2cv
<qschulz>
Yeah a bit depressing, the RK3588 BSP have some commits in 2019 and upstreaming is just starting now :/
<marex>
narmstrong: the mp15 yes, the mp13 no
* marex
silently weeps
<narmstrong>
yep it's sad for the RK3588, they had quite a good upstream support for other socs, I didn't understand why they suddently stopped
<marex>
pandemic ?
<narmstrong>
well I can, Amlogic did the same, business was more important
<qschulz>
narmstrong: I don't know how long it took for RK3399 to be upstreamed for example
<qschulz>
narmstrong: they also took VERY long to actually provide samples compared to when they announced it
<qschulz>
it took like 2-3 years to see the first design
<narmstrong>
yeah this can't help
<qschulz>
But yeah... Chinese company, COVID for sure didn't help with all the full lockdowns and all
<qschulz>
not sure home office work well for that industry :)
<narmstrong>
hard to say, it's quite opaque
<sjg1>
xypron: So you mean implement something with similar functionality to EDK2? I believe we cannot port code over due to the license
<xypron>
sjg1: edk2 is BSD licensed. But we don't need everything. You asked which widgets we need and how to implement them. I think the widgets used by edk2 are sufficient.
<narmstrong>
qschulz: the renesas SoCs are pretty cool, and very well documented, we worked on them at BL, but they are exclusively for the automotive market
<sjg1>
xypron: I am assuming we need both text and GUI
goliath has joined #u-boot
<xypron>
sjg1: a text console should be good enough. Does anyone need graphics?
akaWolf has joined #u-boot
<sjg1>
xypron: I see it on modern laptops so I don't think we can ignore it. It would be an incomplete solution
<sjg1>
Tartarus: It seems that your approach with splb is to avoid any size changes?
akaWolf has quit [Ping timeout: 252 seconds]
mckoan is now known as mckoan|away
<Tartarus>
sjg1: Any incorrect size change
<Tartarus>
The CMD ones we can maybe live with
<Tartarus>
but everything else is intentional
akaWolf has joined #u-boot
<Tartarus>
Or someone needs to explain and confirm that what we're doing today is wrong, really, at the functional level
<Tartarus>
I'm going to pull in the MMC_QUIRK change by itself shortly, since that'll make reviewing the rest of the series easier, and is a fix, but also grows many platforms
<sjg1>
Tartarus: OK...in that case I wonder if the approach should change, with def_bool used in all cases? I don't have an easy way to see which things actually affect SPL code
<Tartarus>
sjg1: I need to look harder at what the result is here, of the split config series
<Tartarus>
Since I keep mentioning that I think Yamada-san was right, in how I recall his position, that we really need to build u-boot separately, each time, rather than what we do today
<sjg1>
Tartarus: Well that also changes some things, although not too many from what I can see (apart from the CONFIG_CMDLINE patch)
<Tartarus>
Right, the cmdline one sounds like it's fixing a problem
<Tartarus>
But the things I've been flagging in this series so far are intentional things we do today
<sjg1>
Tartarus: Right...so does each of these become a 'def_bool n'? Just trying to figure out if we have a viable path here
<Tartarus>
sjg1: I mean, the logical extension would be to do def_bool n, yes, but if we end up with 200 def_bool n's, that shows we're going down the wrong path.
<sjg1>
Tartarus: So it seems like you are doing a middle path, trying to eliminate CONFIG_IS_ENABLED() where it doesn't affect SPL, but otherwise keep it?
<Tartarus>
sjg1: I think the pre-req series for your split config do highlight and fix a number of potential issues, as largely CONFIG_IS_ENABLED(FOO) should only be used when xPL_FOO is a symbol, but it's not a 100% rule
<Tartarus>
I don't know if what you're doing for split config is right, yet
<Tartarus>
But yes, reworking it to maintain the invalid symbol means false functionality of CONFIG_IS_ENABLED() today would be good I think
<sjg1>
Tartarus: I think I would give up if that is the goal, at least without more tooling. My suggestion is to change it and let the maintainers review and object / patch if they want to
<sjg1>
Tartarus: I was really hoping this might be a path to fixing the SPL_TPL and CONFIG_IS_ENABLED() stuff
<Tartarus>
Well, if we're forcing everyone to add hidden symbols to avoid writing out CONFIG_$(SPL_TPL_)_FOO in Makefiles, I'm not sure it's a big win
<Tartarus>
Which is why I want to see what it looks like at the end, what the trade-offs we're making are
<sjg1>
Tartarus: OK
<Tartarus>
For example, what happens, really, to drivers/Makefile and that huge block we hide under an SPL/TPL build check?
<Tartarus>
(related to the MULTIPLEXING patch)
frieder has quit [Remote host closed the connection]
naoki has quit [Quit: naoki]
<sjg1>
Tartarus: Yes I looked at that. I think we can just remove it, since we know (with m yseries) that nothing is affected by it
<sjg1>
Tartarus: But with the changes you are making, we'll need to revisit everything
<sjg1>
Tartarus: I'm just not sure this is feasible without new tooling
<Tartarus>
Yeah, we'll need to revisit things, but it should be a smaller set
akaWolf has quit [Ping timeout: 252 seconds]
prabhakarlad has quit [Quit: Client closed]
<jpsollie>
Tartarus: I got everything up and running after all on my rk3328 platform. Should I further try to bisect 2022.04 -> 2023.04-rc1? or will reporting be enough?
<jpsollie>
*reporting the bug
<Tartarus>
jpsollie: Well, if you can figure out what caused things to still not work on top of tree that'll help get it fixed
<jpsollie>
... and a few mods to make it work in 2022.04 after all :p
mmu_man has joined #u-boot
<sjg1>
Tartarus: OK I'll wait to see
<Tartarus>
jpsollie: Ah, well, git bisect will jump around for you, once you have a good and bad point
<Tartarus>
You might need to use git stash to save/apply fixups as you go, if there's more than one problem
<jpsollie>
all right ... I'll try to find something
<jpsollie>
I also noticed the misc_init() of the board doesn't work, probably due to efuse not working properly. Is it even worth reporting?
akaWolf has joined #u-boot
apritzel has quit [Ping timeout: 248 seconds]
akaWolf has quit [Ping timeout: 260 seconds]
ladis has quit [Quit: Leaving]
Leopold has joined #u-boot
akaWolf has joined #u-boot
naoki has joined #u-boot
<Tartarus>
Certainly won't get fixed if it's not reported
ikarso has quit [Quit: Connection closed for inactivity]
<jpsollie>
lol ... you got me there :p I'll report it then
<CounterPillow>
sjg1: question about Rockchip images, I have a 2023.04-rc1 based u-boot where making the DTB too large leads to atf never starting. As far as I can tell, the fdt shouldn't truncate atf for me. Any idea what else could cause this?
<CounterPillow>
notably, enabling fdt overlays balloons the size of the fdt to something where it doesn't boot unless I start slicing away a lot of nodes
Bebo35 has joined #u-boot
<CounterPillow>
Also open to input from anyone else, or suggestions as to other things that could cause this (size of dtb is the theory with the most evidence now since which nodes I remove doesn't seem to matter)
naoki has quit [Quit: naoki]
Bebo35 has quit [Quit: Client closed]
vagrantc has joined #u-boot
<hays>
narmstrong: oh you were able to reproduce
<hays>
narmstrong: if i run that init command twice it seems to work. its almost like there is something wrong with the sequence?
<hays>
narmstrong: also, do you follow the flashing advice in the docs? flash uboot.bin.sdcard.bin with the 444-512 hole?
akaWolf has quit [Ping timeout: 264 seconds]
<hays>
I am going to try 300us
<marex>
xypron:
<marex>
lib/efi_loader/initrddump.c:218:68: warning: comparison is always true due to limited range of data type [-Wtype-limits] 218 | if (key.unicode_char >= 0xD800 && key.unicode_char <= 0xDBFF)
<marex>
xypron: are you aware of that ?
ikarso has joined #u-boot
persmule has quit [Remote host closed the connection]
flyback has quit [Remote host closed the connection]
flyback has joined #u-boot
<hays>
narmstrong: This may be true... (?) If I let the board sit powered off for 20s or so, it more reliably boots. Hard to be sure im booting over and over again to try different things
<marex>
tlwoerner: that thing does either apply DTOs directly via fitImage configurations, or, if there is additional script 'loaddtoscustom' in U-Boot env, it extracts DT and DTOs from fitImage,applies them, and then lets you modify the DT in $loaddtoscustom before passing it to Linux using fdt command
<marex>
the fdt command is already configured to point to the assembled DT too
<marex>
tlwoerner: the trick is around the "Using base DT" print, see the imxtract there, like 100