Wouter01001 has quit [Remote host closed the connection]
Wouter01001 has joined #u-boot
rvalue has quit [Ping timeout: 240 seconds]
rvalue has joined #u-boot
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
apritzel_ has joined #u-boot
frieder has joined #u-boot
mckoan|away is now known as mckoan
zibolo has joined #u-boot
apritzel_ has quit [Ping timeout: 240 seconds]
akaWolf has quit [Ping timeout: 244 seconds]
aggi has joined #u-boot
akaWolf has joined #u-boot
sszy has joined #u-boot
jclsn has joined #u-boot
guillaume_g has joined #u-boot
<jclsn>
Morning, does mainline u-boot support the imx8 boards by now? We are currently still using uboot-imx and I was wondering if we could switch to mainline
<hramrach>
technically you can build u-boot for imx8 but I don't have such board so I would not know how well it works
<hramrach>
seems the ATF is not buildable with older gcc because it uses some weird tricks
<jclsn>
ATF?
sszy has quit [Remote host closed the connection]
<hramrach>
trusted-firmware-a
<jclsn>
Ah okay
<jclsn>
So you mean I could run into problems with the chain of trust?
<jclsn>
Or was ATF only for Android?
<hramrach>
no, I mean you can run into problems with non-cutting-edge compilers
<jclsn>
That shouldn't be a problem
sszy has joined #u-boot
<jclsn>
We are currently setting everything up from scratch
<hramrach>
you likely need ATF
<jclsn>
So we want to have the latest versions of everything
<jclsn>
imx8 is listed under arch/mach-imx at least
<jclsn>
Should work
<jclsn>
I want to get away from vendor firmware etc. as much as possible
<LeSpocky>
jclsn: if you look into arch/arm/dts there are quite some imx8 boards already
matthias_bgg has joined #u-boot
<jclsn>
LeSpocky: Yes, thanks
<jclsn>
I will need to get a board without the eFuse blown first anyway :Ü
<jclsn>
:P
<jclsn>
So what is the deal with uboot-imx anyway? Seems to be obsolete by now. Ah well guess they publish the latest changes there first, which get merged into mainline after some time
<aggi>
apropos bleeding edge compilers
<aggi>
for various reasons, i kept gcc-4.7 (which didn't require c++), and maintain some custom gentoo-profile with all c++ dependencies removed
___nick___ has joined #u-boot
<aggi>
then the idea was, to compile u-boot too, with the usual cross-compilers etc... yet with my test-case it is gcc-4.7 and everything removed which contains c++
<aggi>
suddenly i noticed... u-boot requires python-swift, which is, written in c++
<aggi>
meaning, it isn't possible, to compile u-boot without a c++ compiler involved somewhere
<j`ey>
aggi: some fork of u-boot? I dont see python-swift being a requirement
aggi has quit [Quit: aggi]
aggi has joined #u-boot
<hramrach>
requirements vary between target platforms
<aggi>
ups, anyway, didn't update u-boot for a while (2020-10 iirc)
<aggi>
and it was a typo: python swig
<aggi>
python swig is required for the FDT things i think
<aggi>
anyway, with this dependency involved, swig, u-boot loader cannot be compiled without a c++ compiler involved
<aggi>
may seem, at first glance, that's not a big issue, except i had been hacking to remove _all_ c++ dependencies for my gentoo profile
<aggi>
including the fact, i don't accept any later version than gcc-4.7
la_mettrie has joined #u-boot
<la_mettrie>
if hardware platform's register data is placed in u-boot and passed to OS's kernel, where is the point in which u-boot & OS kernel interract? how u-boot placed register data is seen on the kernel code?
<mps>
aggi: not that I have solution, also I tried to keep with gcc 4.7 but gave up about year ago
<j`ey>
linux-kernel requires 5.1 now
<mps>
(nowadays building anything become 'monsters')
Ybombinator has joined #u-boot
<Ybombinator>
Hello, I am using a raspberry pi, I have no way to check serial output, is there a way I can have output be display on my monitor using HDMI instead?
<aggi>
j`ey: by coincidence patched kernel-5.9/5.10 and it still compiles with gcc-4.7 (and some old binutils-2.22)
<j`ey>
sure, just not sustainable I guess
<aggi>
however, for u-boot i need various other cross-compilers/versions, too aarch64 requires at least gcc-4.8/c++
<aggi>
besides the python swig issue (c++ dependency)
<Ybombinator>
I'm guessing this needs to be setup using menuconfig but I couldn't find any relevant options so far. I tried disabling CONFIG_SYS_DEVICE_NULLDEV but this hasn't made any difference.
<aggi>
mps: in userspace gcc-4.7 isn't a huge issue, it's still possible, for the architectures supported
<aggi>
cross-compilation and toolchain maintenance, it's tested and fully functional here
<aggi>
by coincidence, i was working on x86_64 cross-compiler setup in recent days, and soon will know if kernel 5.10 keeps booting when compiled with gcc-4.7
<aggi>
however, couldn't test aarch64, which is required by the cortex a53 i got, and gcc-4.7 doesn't support aarch64
<aggi>
same with u-boot, aarch64 requires c++ compilers (written in c++), and python swig for the FDT stuff too requires c++
<aggi>
even if, i succeeded one day, to fully integrate tinycc compiler for aarch64 for example, to compile kernel, userspace etc.
<aggi>
python swig required by uboot will alwasys introduce a c++ compiler (>gcc-4.7)
apritzel has joined #u-boot
persmule has quit [Quit: Leaving]
<mps>
aggi: last years I work more and more on aarch64
<aggi>
there was some questions raised by other participants, don't mean to interrupt
<aggi>
anyway, mps: with aarch64 there is no chance to keep gcc-4.7 without c++ dependencies
<aggi>
and the aarch64 backend for tinycc was/is incomplete still
<sjg1>
josem: Are you about?
matthias_bgg has quit [Ping timeout: 244 seconds]
matthias_bgg has joined #u-boot
<mps>
aggi: yes, I know. because this I already gave up and follow mainstream bandwagon
<aggi>
mps: i am using an aarch32 userspace (c-only toolchain system profile) on top of an aarch64 kernel/uboot
<aggi>
and for testing kernel builds, i maintain gcc-4.7 cross-compilation toolchains for amd64 now
<aggi>
with this, i can continue maintaining the c-only toolchain system profile (gcc-4.7), and next i'll test tinycc for userspace
<mps>
I wish you good luck (though I think it will not be easy task)
<aggi>
yes, with a c-only toolchain system profile, "free software" reached a dead end at all frontlines, including support for aarch64, u-boot dependency swig(c++)
<mps>
didn't looked but wonder why DT needs swig
<aggi>
already got the entire userspace parts ready, cross-compilers and toolchain maintenance, kernel support up until version 5.10
<aggi>
and yes, the swig dependency inside uboot loader is a nasty one
<aggi>
because, removal of this one would require extensive rewrites, otherwise c++ build-time dependencies creeped deep down into u-boot territory
<hramrach>
Ybombinator: I think serial output is the default even on pi but you need to set the correct port speed to see anything - provided you connected the serial port correctly in the first place
<hramrach>
if you can boot Linux you can try dumping something like dmesg to your serial port in a loop to make it easier to find
<Ybombinator>
hramrach: I have nothing to connect to the serial port, that's why I want to use HDMI instead
<hramrach>
that's much less reliable, not sure it even works, and likely depends on your pi model as well
persmule has joined #u-boot
<hramrach>
spending $3 on a serial adapter saves you a lot of trouble in the long run
<Ybombinator>
I found CONFIG_DISPLAY which sounds like what I want to use
<Ybombinator>
hramrach I have no job and I am poor
<hramrach>
even then
<Ybombinator>
but it only adds the drivers needed for HDMI display, I guess, I don't know how to actually use them
<hramrach>
the pi itself is not free either
<Ybombinator>
can we try not arguing about money and instead try solving the issue? even if I had a USB to TTL I would still want to use HDMI instead. "buy this" isn't really a solution.
<hramrach>
you did not even say which pi you use so I can't really say if it's supposed to work or not
<Ybombinator>
rpi 4b
<hramrach>
and from my experience the graphical output is very fragile, using USB TTL is much more useful unless you are going to use pre-built release image and never touch the low-level stuff such as u-boot
<hramrach>
for me it works on 3b, and the 4b is significantly different so YMMV
<Ybombinator>
ah, so what do you mean by "fragile"? input doesn't work some of the time, stuff doesn't render sometimes or what?
<Ybombinator>
I just wanna know why USB TTL is better
mmu_man has joined #u-boot
<hramrach>
the serial driver is literally trivial. To get the graphical console working you need assorted clocks, some interconnect bridge setup, RAM, pixel valves, the hdmi phy, usb, and probably a few things I am forgetting. So many things that can and do go wrong
<Ybombinator>
ah, well thanks a lot
<hramrach>
right, and I had to patch the USB driver to be able to use the 3b without serial console - you get the idea
<aggi>
geoffs vt100 serial to ps2/vga terminal, got this one in shopping cart for almost 2years now
<mps>
hramrach: speed on serial consoles usually are 115200 by default