<qschulz>
i think I know the answer already... but how do we feel about -Wdiscarded-qualifiers warning?
<qschulz>
because I'm trying to change env_get_from_linear and now it's like I have to rewrite U-Boot entirely to fix all those warnings :)
<qschulz>
https://paste.ack.tf/c44be7 is what I have right now that triggers this warning on env_get_from_linear level
persmule has joined #u-boot
<f_>
calebccff: yeah I saw.
<f_>
am following you on fedi
<f_>
(unfourtunately not as active in the sdm845 matrix room as I used to)
slobodan has joined #u-boot
xroumegue has quit [Ping timeout: 248 seconds]
persmule has quit [Ping timeout: 264 seconds]
persmule has joined #u-boot
xroumegue has joined #u-boot
monstr has quit [Ping timeout: 255 seconds]
monstr has joined #u-boot
mmu_man has quit [Ping timeout: 258 seconds]
mmu_man has joined #u-boot
sakman has quit [Quit: Leaving]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
manchaw has quit [Quit: Connection closed for inactivity]
<Tartarus>
qschulz: Re that rockchip series now, what are the problems of trying devices in the wrong order? Is it that we can't force uSD recovery of broken eMMC ? Or is it "we probe the wrong SDHCI instance and the board gets in an invalid state" ?
<qschulz>
Tartarus: we have had a policy about storage media order for a while already, so just fixing it
<qschulz>
Tartarus: e.g. we want to load the next boot phase from the same storage medium as the current boot phase
goliath has quit [Quit: SIGSEGV]
<qschulz>
e.g. if loading SPL from eMMC, I want to try to boot U-Boot from eMMC as well
<qschulz>
and fallback to SD card otherwise
<qschulz>
if U-Boot was loaded from eMMC, I want standard boot to start checking for boot binaries (kernel, dtb, extlinux.conf, whatever) from eMMC
<qschulz>
if not, then fallback to SD card
<qschulz>
now swap SD card and eMMC and I want the same behavior as well
<qschulz>
for RK3399, if we boot from SPI-NOR, there's no chance there are boot binaries in it, so let's just use the default boot_targets instead (whatever the order is, default or not)
<qschulz>
obviously, if the user has changed the order themselves, we don't want to modify it
<qschulz>
Tartarus: and finally, this has been a bit of a PITA for us as sometimes we just want to boot something fully from eMMC or SD card for testing purposes and we end up figuring out that one boot phase just switched to something different than expected
<qschulz>
reminder also that we have a HW switch to enforce booting from SD card (but itself overridden in SW after SPL has booted)
<Tartarus>
Will digest this shortly, thanks.
sszy has quit [Ping timeout: 240 seconds]
prabhakar has joined #u-boot
sszy has joined #u-boot
Clamor has quit [Read error: Connection reset by peer]
tnovotny has quit [Remote host closed the connection]
Clamor has joined #u-boot
slobodan has quit [Read error: Connection reset by peer]
slobodan has joined #u-boot
<qschulz>
Tartarus: are you trying to figure out whether to pull this in for 2024.01? since it's been broken for a few releases already, I don't mind if it's kept for the next branch
<Tartarus>
qschulz: Ah, I was trying to figure out the severity of the issue in general, and then yeah, see what's next. And it reminded me of something pbrobinson noted re Pi platforms, so I wanted to know a little better just what's going on
<Tartarus>
And I marked it generally for kever but needs ack for the env parts and I will do my best to look at that sooner rather than later.
<qschulz>
Tartarus: FYI, I had tried another way: https://paste.ack.tf/c44be7 but this is a **really** invasive change. and i stopped when i had to change various function pointer signatures
<qschulz>
(the issue being that this triggers a -Wdiscarded-qualifiers warning and fixing it requires to constify A LOT of things
thopiekar has quit [Ping timeout: 240 seconds]
slobodan has quit [Remote host closed the connection]
monstr has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
mmu_man has quit [Ping timeout: 255 seconds]
Clamor has quit [Ping timeout: 240 seconds]
mmu_man has joined #u-boot
mmu_man has quit [Ping timeout: 240 seconds]
<Tartarus>
re discarded-qualifier, ah, so I see you answered your own question from a few days ago about why that other function wasn't changed further at the time. Yeah, that does seem a lot more invasive for just this kind of fix.
<Mis012>
I needed someone with an i.MX board to sanity check that it works before changing over the other platforms, looks like now I'll also have to rebase everything... will be fun
tnovotny has joined #u-boot
<Forty-Bot>
Mis012: what's your goal for that patch?
<Mis012>
ccf in u-boot was 6 months ago (and I assume still is) really annoying to use for porting drivers from Linux
<Mis012>
and the reasons given for making it so weird were that it would save memory
<Mis012>
but I found places where it stupidly wastes memory
<Forty-Bot>
can you give an example?
<Mis012>
it used the clk structure for two different purposes, so in both uses there were members which were not needed
<Mis012>
it was also extremely confusing because of that
<Mis012>
I had this more freshly in my memory 6 months ago, but sadly I wasn't able to get anyhting tested on the librem 5 because apparently even without my patches the HEAD didn't boot at that point
<Mis012>
iirc we even talked about it here
mmu_man has joined #u-boot
<Tartarus>
Mis012: So what platforms did you get it tested on at the time?
<Mis012>
I started with the i.mx platform since that's what ccf was originally added for
<Mis012>
my platform is qcom, so I wouldn't have anything to test on anyway
Stat_headcrabed has joined #u-boot
<Mis012>
and I figured getting someon to test on the librem5 would have been trivial
<Forty-Bot>
I think before we really make large changes like this we should have some clock unit tests
<Tartarus>
Should that tree as-is work in imx6 or ?
<Forty-Bot>
it's been on my todo list for a while
<Tartarus>
Or just 8?
<Mis012>
I ported two specific imx SoCs for start
<Forty-Bot>
I think it should get tested on 8
Stat_headcrabed has quit [Client Quit]
<Forty-Bot>
looks like 8mq?
<Mis012>
since I was doing it blind and I was pretty sure there would be issues found the second it gets tested
<Tartarus>
Ah ok, sorry, I don't have any 8 platforms available
<Tartarus>
Mis012: I think the answer for today is talk with calebccff as they are doing qcom U-Boot work Right Now, to figure out how to advance your overall goal of supporting some platform.
<Tartarus>
And yes talk with Forty-Bot too about general clock framework improvements
<Mis012>
well, the ccf port is horrific :(
<Forty-Bot>
I agree :l
<Mis012>
I have been switching between being extremely sad about this situation and trying to think about something less depressing for the last 6 months...
<Mis012>
Tartarus: I can somewhat easily port over another i.mx SoC, tell me which one you have and I'll try to re-familiarize myself with this tomorrow
<Mis012>
well, not the full six months, some of it was trying to get it tested on librem 5
<Tartarus>
Mis012: Well, I have mx6cuboxi in my farm, but, work with Forty-Bot since he's the clock custodian.
<Tartarus>
And if you want to focus on the qcom platform you have, calebccff is the one to talk with about that
<Tartarus>
I was going to offer to quick-test the old tree and give you feedback, but I don't have the HW to do that
<Mis012>
well, qcom platform is just sad, I will talk with caleb about it but sadly it seems he has figured out some short-term fixes instead of my vision of nuking the sad existing code
<calebccff>
for Qualcomm clock support is fairly straightforward because XBL does most of the hard work for us, so we just need to turn on a few peripheral clocks at most
<Mis012>
in my case, xbl never runs
<Mis012>
and ideally SPL would also be u-boot, which would mean even more stuff needs to be handled
<calebccff>
right, you're doing U-Boot as first-stage, in which case having some nicer clock framework is understandable
<Mis012>
fwiw idk why linaro doesn't just use qcom's sbl + u-boot proper considering the fact that I already had that work good enough to boot into Linux
<Mis012>
having xbl in the mix seems wholly unnecessary
<Mis012>
might have some fun with lawyers explaining that just because qcom is being clever with their single ELF solution, it doesn't constitute linking in the GPL sense
<Mis012>
Forty-Bot: well, do you have 8mq or should I port over another i.mx SoC?
<Forty-Bot>
I have some at work, but they are not upstreamed
<Forty-Bot>
at home I mostly have risc-v stuff
<Mis012>
so having Tartarus to test would be easier?
<Forty-Bot>
well, I think the easiest route is to start by testing all the CCF stuff in sandbox
<Forty-Bot>
when clock stuff doesn't work on real hardware it can be very annoying to debug since e.g. your jtag no longer works
<Tartarus>
And if you don't have sandbox tests for new things, it will be a problem too that needs to be resolved
<Tartarus>
So sandbox and tests now is a good starting point.
<frieder>
Hi, is there a way to run the "fdt" command on a devicetree that is inside a kernel fitImage before booting it?
<Forty-Bot>
frieder: you can do `imxtract ...; fdt addr $fileaddr`
<Mis012>
Tartarus: I guess I'll look into that tomorrow, thanks
<frieder>
Forty-Bot: Ah, ok. I will try that. Thanks!
<Tartarus>
frieder: And it also depends a little on what you want to change in the device tree. You don't need to get fancy like that for say cmdline, and some board fixups are done too. But more arbitrary changing and examining, yeah, what Forty-Bot said
<frieder>
Tartarus: Ok, I want to use a script in env to enable/disable some I2C device nodes.
<Tartarus>
frieder: Ah, ok. Not sure if you can use/abuse the extension framework off-hand for that too, within a FIT image.
flom84 has quit [Remote host closed the connection]
flom84 has joined #u-boot
justThanks is now known as justTesting
<kabel>
marex: yes. We would like to request realtek customer support for some documentation, but since we didn't buy the hardware we're seeling directly from realtek, we do not have a realtek contact and can't create customer portal account
<kabel>
marex: alternatively if someone has access to documentaiton to realtek ethernet PHYs and would share some register descriptions so that we can extend the linux driver, it would be even better
mripard has quit [Read error: Connection reset by peer]
mripard has joined #u-boot
<marex>
kabel: ah, sigh ...
frieder has quit [Remote host closed the connection]
Clamor has quit [Ping timeout: 258 seconds]
Clamor has joined #u-boot
flom84 has quit [Ping timeout: 245 seconds]
<Forty-Bot>
(as it turns out the datasheet for the phy is available on google)
<Clamor>
Fascinating ;)
Clamor has quit [Read error: Connection reset by peer]
Clamor has joined #u-boot
justTesting is now known as justThanks
Clamor has quit [Read error: Connection reset by peer]
pgreco_ has joined #u-boot
pgreco has quit [Ping timeout: 255 seconds]
pgreco_ is now known as pgreco
alan_o has quit [Remote host closed the connection]
alan_o has joined #u-boot
goliath has joined #u-boot
goliath has quit [Quit: SIGSEGV]
vagrantc has quit [Quit: leaving]
pivi has joined #u-boot
<marex>
Forty-Bot: some of those datasheets have hidden bits which are missing from them, but are part of the kernel driver already, sigh
<Forty-Bot>
better than nothing
qqq has quit [Remote host closed the connection]
<marex>
Forty-Bot: its the hidden bits that are often most interesting
<Forty-Bot>
sometimes
<Forty-Bot>
but a lot of times they're chicken bits
goliath has joined #u-boot
ungeskriptet has quit [Read error: Connection reset by peer]