gaston1980 has quit [Quit: Konversation terminated!]
sbach has quit [Read error: Connection reset by peer]
sbach has joined #u-boot
thopiekar_ has joined #u-boot
thopiekar has quit [Ping timeout: 268 seconds]
mmu_man has quit [Ping timeout: 252 seconds]
swiftgeek has quit [Ping timeout: 268 seconds]
swiftgeek has joined #u-boot
jclsn has quit [Ping timeout: 244 seconds]
jclsn has joined #u-boot
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #u-boot
vagrantc has quit [Quit: leaving]
persmule has quit [Quit: Leaving]
persmule has joined #u-boot
persmule has quit [Remote host closed the connection]
camus has quit [Remote host closed the connection]
persmule has joined #u-boot
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
camus has joined #u-boot
camus has quit [Client Quit]
aggi has joined #u-boot
redbrain has quit [Read error: Connection reset by peer]
redbrain has joined #u-boot
persmule has quit [Ping timeout: 258 seconds]
guillaume_g has joined #u-boot
persmule has joined #u-boot
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
xroumegue has joined #u-boot
frieder has joined #u-boot
ladis has joined #u-boot
mps has quit [Ping timeout: 260 seconds]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
akaWolf has quit [Ping timeout: 252 seconds]
mps has joined #u-boot
akaWolf has joined #u-boot
mckoan|away is now known as mckoan
LeSpocky has joined #u-boot
<LeSpocky>
hello
* LeSpocky
has to look each time before joing which irc network hosts this channel
<LeSpocky>
maybe someone™ should add this to docs?!
persmule has quit [Remote host closed the connection]
frieder has quit [Read error: Connection reset by peer]
frieder has joined #u-boot
persmule has joined #u-boot
frieder has quit [Quit: Leaving]
frieder has joined #u-boot
m5zs7k has quit [Ping timeout: 264 seconds]
m5zs7k has joined #u-boot
sszy has joined #u-boot
alan_ has joined #u-boot
alan_o has quit [Ping timeout: 252 seconds]
<hanetzer>
progress. I can now parse out the reg.bin for hisi socs using svd files (which are also useful wrt gdb/openocd and ghidra). Now the only major issue is a bunch of seemingly 'magic' values in those, as the regs they write are undocumented
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
mwalle has joined #u-boot
mwalle has quit [Changing host]
mwalle has joined #u-boot
mwalle has quit [Client Quit]
mmu_man has joined #u-boot
indy has quit [Ping timeout: 252 seconds]
indy has joined #u-boot
rvalue has quit [Ping timeout: 244 seconds]
indy has quit [Ping timeout: 268 seconds]
mwalle has joined #u-boot
mwalle has quit [Client Quit]
mwalle has joined #u-boot
mckoan is now known as mckoan|away
rvalue has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
<mps>
got this warning when building u-boot 2022.07 on riscv64 `/usr/bin/ld.bfd: warning: lib/efi_loader/dtbdump_efi.so has a LOAD segment with RWX permissions`
rvalue has quit [Ping timeout: 260 seconds]
<mps>
also this `/usr/lib/python3.10/site-packages/setuptools/dist.py:544: UserWarning: The version specified ('u-boot-2022.07') is an invalid version, this may not work as expected with newer versions of setuptools, pip, and PyPI. Please see PEP 440 for more details.`
prabhakarlad has joined #u-boot
alan_ is now known as alan_o
alan_o has quit [Quit: Leaving]
alan_o has joined #u-boot
torez has joined #u-boot
minimal has joined #u-boot
Sout_ has quit [Ping timeout: 268 seconds]
Sout_ has joined #u-boot
tre has quit [Remote host closed the connection]
Sout_ has quit [Ping timeout: 252 seconds]
<aggi>
reminds me of another issue with python and uboot, which i didn't want to interfere with in this channel
<aggi>
i verified an entire system-profile to remove _all_ c++ dependencies from, and already got a _userspace_ of ~600 builds which pass with a tcc-toolchain (aarch32)
<aggi>
however, uboot-loader, python, swig
<aggi>
ideally, some time in the future, an alternative toolchain such as tcc was capable to compile uboot-loader too
<aggi>
yet, python-swig is written in c++, hence it won't be possible to compile this dependency with tcc-toolchain of cause
<aggi>
and, python itself is troublesome for other reasons (libffi, aarch32 assembly which tcc assembler couldn't digest)
<aggi>
as a consequence, u-boot loader and it's build-time dependencies remain fully locked against GNU toolchain including c++ even
<aggi>
and if it is an aarch64 uboot-loader, then it's a recent version of GCC required with support for aarch64, and those compilers themselves are written in c++ too
Sout_ has joined #u-boot
<aggi>
question would be, if the python/swig build-dependency could be detangled from u-boot loader (required for FDT things)
<aggi>
otherwise, fyi, tcc-toolchain got some riscv64 support already
matthias_bgg has quit [Quit: Leaving]
rfried has quit [Excess Flood]
rfried has joined #u-boot
vagrantc has joined #u-boot
<xypron>
mps: see a8d52f9a9b7be90 ("efi_loader: suppress executable stack warning")
<mps>
xypron: aha, so it is fixed in -rc serie
<Tartarus>
aggi: Hard to say? Can we just delete all of that and replace it with something in C? I don't know, might be rather tricky?
mmu_man has quit [Ping timeout: 252 seconds]
mmu_man has joined #u-boot
indy has joined #u-boot
mmu_man has quit [Ping timeout: 252 seconds]
guillaume_g has quit [Quit: Konversation terminated!]
monstr has joined #u-boot
mmu_man has joined #u-boot
urja has quit [Read error: Connection reset by peer]
<aggi>
Tartarus: i don't know how; only want to raise awareness slightly, of the problems when uboot loader vendor-locks against GNU-toolchain _and_ c++
<Tartarus>
Well, fwiw we can build with clang too
<aggi>
currently it seems _impossible_ to detangle uboot-loader
<Tartarus>
So it's just c++
<aggi>
Tartarus: llvm/clang are written in c++ too, ys
<aggi>
and the python/swig-related build-time dependencies of uboot-loader are concering; depends, doesn't seem to be a prioritiy of uboot project
<aggi>
it's somewhat ironic nonetheless, tcc-toolchain is sufficiently capable, to compile a userspace containing ~600builds (including almost everyting desireable)
<aggi>
and it is _impossible_ to keep uboot-loader sanitized (no-c++, alternative toolchain support)
<Tartarus>
Well, to some extent python is a bit of a hard requirement as we also need it for binman to make the functional binaries on many aarch64 platforms.
<aggi>
the problem isn't python itself, it's the bootstrapping of it, and the dependency graph
<aggi>
on top of this, this prevents tcc-toolchain integration with uboot-loader
<mps>
aggi: also I don't like python is everywhere to build software, but I don't grumble, that's a life
<sjg1>
apalos: Can you please point me to the op-tee binding?
frieder has quit [Remote host closed the connection]
apritzel has quit [Ping timeout: 252 seconds]
prabhakarlad has quit [Quit: Client closed]
monstr has quit [Remote host closed the connection]
<apalos>
sjg1: there's 53 boards with that optee node currently
<apalos>
random examples, arch/arm/dts/synquacer-sc2a11.dtsi arch/arm/dts/stm32mp15-scmi.dtsi etc
<apalos>
optee: optee {
<apalos>
compatible = "linaro,optee-tz";
<apalos>
method = "smc";
<apalos>
};
<apalos>
that's basicalyl what you want in the DT
<apalos>
and the the trusted application in optee sit on a virtual bus which is scanable
<apalos>
so yea the patch is kinda of a hack because we dont *really* scan that bus
<apalos>
but I plan to fix that on the next release. But nevertheless being able to bind those devices regardless is important
<sjg1>
apalos: OK, I see. That binding is not good enough. It needs to be updated
<sjg1>
A better hack for now is to add a u-boot.dtsi file for those boards which adds the required nodes
<apalos>
the optee one?
<apalos>
there's more problems, I need to go back and check again but the kernel will complain if the device is both scanable and on a dts node
<sjg1>
apalos: Yes, add some subnodes to it. Once you can scan the bus and obtain the U-Boot drivers names from optee (is that what you mean?) then it can go away
<apalos>
you dont obtain a name, iirc you get a uuid of the trusted app
<sjg1>
apalos: I don't understand how the kernel can scan the bus if U-Boot cannot. Which kernel warning are you referring to?
<apalos>
so there's literally no need for subnodes
<apalos>
the kernel has more code in the optee driver, which basically sends an smc to optee
<sjg1>
Of course, we need more UUIDs in our lives :-)
<apalos>
and optee replies with the devices it supports
<apalos>
sjg1: i aint gonna argue the design
<apalos>
that's it, i've accepted the fact. I am more interested in having devices working
<apalos>
and I dont really care if it's a string/hex/uuid whatever
<apalos>
but think of it as a pci bus
<apalos>
and the uuid is the dev/vendor id
<apalos>
So there's nothing add a dt entry for, apart from the main optee node
<apalos>
if you are intersted in more detals, the kernel does an SMC with PTA_CMD_GET_DEVICES_SUPP
minimal has quit [Quit: Leaving]
<sjg1>
apalos: We are going to have to allow controlling where the random numbers come from. See the patch I cc'd you on. I haven't even seen the design, nor was I aware of the binding just now
<sjg1>
apalos: Let's talk it through at osfc
<apalos>
what numbers? you mean that ?
<apalos>
PTA_CMD_GET_DEVICES_SUPP
<apalos>
sjg1: and i agree that's not a right patch
<apalos>
but that's a completely different case than what I sent
<sjg1>
apalos: I mean we can get random numbers from software, SoC, hardware, op-tee, etc. Yes this is a different issue but it is the one that all the Linaro people argued about a month or so ago, including Rob Herring
<sjg1>
apalos: You are saying it is a discoverable bus, but even then we need DT nodes, so we can decide which random number thing to use from U-Boot. PCI allows you to add nodes for devices, at least in U-Boot
<apalos>
sjg1: not Linaro arm :>
<apalos>
but I generally agree with the notion that was explained
<apalos>
it's pretty simple in my head. A device goes into DT if there's hardware to describe, r.g clocks addresses etc
<apalos>
in case you have a discoverable bus, it's easier for all of us if we just scan the bus. As far as the 'random' number is concerned it's not really random
<apalos>
It's something that OPTEE defined as an ABI and the u-boot op-tee driver just delivers that promise
<apalos>
but sure we can talk more in osfc, i just got my tickets
<sjg1>
apalos: It's just as simple in my head. We have multiple devices in each uclass and need to be able to decide which one to use for a particular 'combining' device or purpose. That is what DT is for. The 'ship has sailed' argument founders when we actually need to do this
<sjg1>
apalos: Yes, easier f2f
<apalos>
sjg1: take a look at that smbios patch as well
<apalos>
I think we need to eventually add sysinfo drivers for specific board needs
<apalos>
but I think it's a sane fallback to look back at dt properties from the spec which at least describe the hardware and the vendor
<apalos>
because atm it's utterly confusing for distros, they just see a dmidecode output full of "Unknown"
pratyush has quit [Quit: Connection closed for inactivity]
<apalos>
Look at that picture :>. The great Unknown
ladis has quit [Ping timeout: 252 seconds]
ladis has joined #u-boot
Sout_ has quit [Ping timeout: 252 seconds]
Sout_ has joined #u-boot
ladis has quit [Quit: Leaving]
<sjg1>
apalos: OK I see. That seems very x86-y. Can we put our info in the device tree instead of that old-fashioned table?
<apalos>
so what happens right now is that u-boot has a special sysinfo node
<apalos>
but it doesnt have a sysninfo driver for that node, it parses the DT
<apalos>
and it makes sense the way it is. All I did was to add a mapping from 2 sysinfo nodes to the 2 DT nodes that are described in the spec
<apalos>
model and compatible,
<apalos>
At least that way even if someone doesn't add a sysinfo node when adding a board (and 99% of the boards dont have that)
<apalos>
we can at least display something reeasonable there
<apalos>
and if someone wants a more detailed report for special board features he can just add a sysninfo driver for his platform
prabhakarlad has joined #u-boot
<apalos>
and the default root .dtsi node you mentioned is a good idea. My problem here is not that u-boot uses the DT for it's own config and info
<apalos>
My problem is that maintaining, update, backporting changes is a bit painful
<apalos>
If we switch the build and split out the .dtsi which need to be included per board, that would make using the DT's from the kernel pretty easy
<apalos>
I havent fully looked into any TPL/SPL implications, but I can go and take a look
<apalos>
because bottom line u-boot is there to boot an OS and ideally i'd like the OS to be able to use the DT the firmware provides
<apalos>
which would also allow us to measure it and protect it
<cambrian_invader>
apalos: I had a look at your patch, but I'm not sure the defaults you've chosen make sense
<apalos>
cambrian_invader: what doesnt?
<apalos>
iirc it adds "model" and "compatible"
<cambrian_invader>
if you have compatible = "foo,bar", shouldn't you have manufacturer: foo?
<apalos>
sure, but the DT spec doesnt say you *must* have the manuf like that
<apalos>
is says it's a good idea to have it like that
<apalos>
OTOH it says the same thing for the model but half of the boards dont do that
<cambrian_invader>
yeah, but anyone who comes along and does this properly will want to change that
<apalos>
So i just send the entire compatible
<apalos>
but it's a fair point I had the same thopughts
<apalos>
but it's just an strtok and use that
<cambrian_invader>
idk, I think device tree is too heterogenous to map like this
<cambrian_invader>
if distros want to do this, they can easily patch their script to read /sys/firmware/devicetree/model or whatever
<apalos>
distros don't want that
<cambrian_invader>
*shrug*
<apalos>
because they use the same userspace for many architectures
<cambrian_invader>
device tree is on more arches than smbios
<apalos>
so it doesnt really make sense to start reasoning on the arch for reporting
<apalos>
yea i was mostly talking about x86
<cambrian_invader>
do you have an example project which does this sort of thing?
<apalos>
so most of the distros just do dmidecode -> print stuff
<cambrian_invader>
well perhaps they should be smarter :)
<apalos>
they are actually smart
<cambrian_invader>
IMO reading device tree is actually quite simple
<apalos>
it doesnt really make sense to look into the architecure and try to decide what to do
<cambrian_invader>
since the kernel already exposes it in terms of directories
<cambrian_invader>
anyway, can you send me a link to some distro code which would be improved by this?
<hanetzer>
cambrian_invader: yee. before i got better at firmware dissection, that was how I'd get dts files off devices I want to port openwrt to
<apalos>
pbrobinson: can probably tell you how this works internally in fedora
<cambrian_invader>
ok, so send a patch to neofetch
<cambrian_invader>
actually, I think things like serial number and chassis type are much better candidates for automatically extracting from a device tree
<cambrian_invader>
or rather, serial number from serial#
<cambrian_invader>
neat, serial# is already implemented
<apalos>
yea and chassis is as well
<apalos>
or it should be using sysinfo
<apalos>
but it's not there yet, I was planning to add another mapping once we sorted out this patch
<apalos>
cambrian_invader: I dont really get your point on neofetch
<cambrian_invader>
the complaint was that neofetch didn't show the host correctly, tight?
<cambrian_invader>
*right
<apalos>
whether we like it or not, tools read smbios, the msbios we expose has Unknown all over the place
<apalos>
so i dont see how making a userspace tool architecture agnostic solves any problem
<apalos>
s/agnostic/aware
<cambrian_invader>
removing x86isms one tool at a time
<apalos>
right i wont even comment on that
<cambrian_invader>
:P
<apalos>
if you want to remove x86sism come help over on the kernel efi stub
<apalos>
which need more help
<apalos>
but whether we like it or not people still use it
<apalos>
and the way to get rid of it is not show garbage until userspace tools catch up :>
<cambrian_invader>
hmm
<cambrian_invader>
on my debian system neofetch shows the correct arch
<cambrian_invader>
err, the correct Host
<apalos>
it's not the host that seems to be the problem
<apalos>
look at that link again and look at the picture
<cambrian_invader>
oh, the stuff on the right
<apalos>
yea
<apalos>
the great unknown
<cambrian_invader>
well, the host is "Unknown Product"
<cambrian_invader>
I wonder if it works properly if you boot without efi
<apalos>
it doesnt
<apalos>
we construct the same smbios tables iirc
<cambrian_invader>
I say that because I see "CPU: Freescale i.MX6 Ultralite (Device Tree) (1) @ 792MHz"