Wouter01001 has quit [Read error: Connection reset by peer]
Wouter01001 has joined #u-boot
Wouter01001 has quit [Read error: Connection reset by peer]
Wouter01001 has joined #u-boot
Wouter01001 has quit [Read error: Connection reset by peer]
Wouter01001 has joined #u-boot
Wouter01001 has quit [Read error: Connection reset by peer]
Wouter01001 has joined #u-boot
Wouter01001 has quit [Read error: Connection reset by peer]
Wouter01001 has joined #u-boot
Wouter01001 has quit [Read error: Connection reset by peer]
Wouter01001 has joined #u-boot
mwalle has joined #u-boot
frieder has joined #u-boot
Wouter01001 has quit [Ping timeout: 272 seconds]
akaWolf has quit [Ping timeout: 244 seconds]
akaWolf has joined #u-boot
mckoan has joined #u-boot
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
ldevulder has joined #u-boot
guillaume_g has joined #u-boot
guillaume has joined #u-boot
rvalue- has joined #u-boot
rvalue has quit [Ping timeout: 240 seconds]
rvalue- has quit [Remote host closed the connection]
guillaume_g has quit [Ping timeout: 244 seconds]
rvalue has joined #u-boot
zibolo has joined #u-boot
Wouter01001 has joined #u-boot
Wouter01001 has quit [Remote host closed the connection]
Wouter01001 has joined #u-boot
zibolo has quit [Ping timeout: 272 seconds]
zibolo has joined #u-boot
apritzel has joined #u-boot
guillaume_g has joined #u-boot
Wouter01001 has quit [Read error: Connection reset by peer]
Wouter01001 has joined #u-boot
guillaume has quit [Ping timeout: 255 seconds]
akaWolf has quit [Ping timeout: 244 seconds]
Xeroine has quit [Ping timeout: 240 seconds]
akaWolf has joined #u-boot
mmu_man has joined #u-boot
Xeroine has joined #u-boot
torez has joined #u-boot
guillaume has joined #u-boot
eloi1 has quit [Quit: WeeChat 3.5]
guillaume_g has quit [Ping timeout: 272 seconds]
<haritz>
hi, I'm trying to get U-Boot to work on an rpi 3b+
<haritz>
everything seems fine if I use the miniUART but as soon as I switch the firmware to enable the PLL UART0 as the primary one, U-Boot stops working altogether
<haritz>
not only I get no serial output at all, but also the default bootcmd command is never run even in the abscence of output
<hramrach>
my suggestion is to find a distribution that uses upstream u-boot, copy their image to SD card, and if it works find out what they built and how
<hramrach>
it works for me but I am using openSUSE image and don't know what configuration is used for building that thing
<haritz>
I'm afraid I don't know of any linux distros for rpi that use U-boot
<haritz>
most of them are happy to set config.txt kernel=whatever
<haritz>
oh
<haritz>
well that's a good starting point
<j`ey>
ubuntu does I think
<j`ey>
kernel=uboot_rpi_4.bin
<haritz>
anyway as I said the problem lies in trying to use UART0 as the primary uart rather than the miniuart
<haritz>
I'll check out ubuntu is building their uboot and maybe a bit of an older version just in case it's a recent regression
<hramrach>
haritz: you probablywant to change this part: stdout-path = "serial1:115200n8";
<hramrach>
also serial0 is reportedly connected to BT so if you use it and send garbage to the module it may send some garbage back and stop boot
sszy has joined #u-boot
<hramrach>
due to the 'pressany key to stop boot'
<haritz>
hramrach: I thought uboot's start sequence had some logic to pick the right UART device
<haritz>
I remember seeing that discussed in a patch serie sometime around 2019
<hramrach>
the stdout-path is the logic (at least so far)
guillaume has quit [Quit: Konversation terminated!]
<hramrach>
but unless I am missing something the bcm2837 has two UARTs, one is connected to BT, and the other is the default console. It is not advisable to use the non-defualt UART for console unelss you also remove the BT module
<haritz>
I did remove that module in Linux
<hramrach>
the hardware module
<haritz>
and also loaded the right dtb overlay to disable BT and wire UART0 to its GPIO pins
<hramrach>
chenging the pinmux to different location might work but it's too late in Linux, you have to change the DT for u-boot
<haritz>
oh that makes sense
<haritz>
one thing I didn't do though was copying the dtb file generated in the build process to the /boot partition in the sdcard
<hramrach>
not sure, actually. On many platforms the dtb is embedded inside u-boot but it may be different for rpi
<haritz>
chosen {
<haritz>
/* 8250 auxiliary UART instead of pl011 */
<haritz>
stdout-path = "serial0:115200n8";
<haritz>
}
<haritz>
this is inside bcm2837-rpi-3-b-plus.dts
<haritz>
eventually makes its way into the overall dtb file
<haritz>
sorry, already changed it to 0, but original value was serial1
<hramrach>
yes, changing this and changing where the uart0 is routed with the gpio mux should give you access to the uart
<haritz>
that's done inside config.txt, isn't it
<haritz>
and first read by the board's firmware before uboot kicks in
guillaume_g has joined #u-boot
<hramrach>
fo u-boot it's defined in the dtb
<haritz>
dtoverlay=disable-bt
<hramrach>
that's for linux
<haritz>
oh also there
<haritz>
alright, then I need to do it all over again
<haritz>
thanks
<hramrach>
or maybe use the default uart for console, and connect whatever else to the uart0
<haritz>
now I can see serial output, but it doesn't take any input
<hramrach>
that's a good start
Xeroine has quit [Ping timeout: 272 seconds]
<hramrach>
get a logic analyzer and start debugging ;-)
<hramrach>
or at least check the wiring with schematic and connectivity with a multimeter
guillaume has joined #u-boot
<hramrach>
also if you can boot all the way to linux you can check if linux can accept input
<haritz>
I thought config.txt would also affect uboot's functionality
<haritz>
in fact, it kind of does, because if uboot were thoroughlyu independent, then adding a dtoverlay option to config.txt to disable bluetooth wouldn't stop uboot from workign altogether
<hramrach>
there might be other device connected to the pin causing the problem or bad wiring
<haritz>
could be wifi
<hramrach>
technically if you get the output you should have successfully rerouted the peripherial in pinmux so your problem is what is conencted where now
<hramrach>
but if this configuration is seldom used there might be a bug in the pinmux data, too
<hramrach>
so it might route the output but a bug may cause the input to not get routed
<hramrach>
if it works on cm and not on pi as reported then it's more likely the wiring
<haritz>
dtoverlay=disable-wifi
<haritz>
added this to config.txt and now it works
rburkholder has joined #u-boot
<haritz>
but now the uart is kind of slow
<haritz>
I'll have to do quite a bit more research
<qschulz>
didn't manage to send a mail to the ML even though I'm registered (now)
<qschulz>
the only doubt I have is that I've disabled Mail delivery in the settings
<qschulz>
is this also not allowing me to send mails?
<apritzel>
Tartarus: so is the merge window cut short now, because of the delayed release?
<qschulz>
seems to have resolved itself, though my second mail (when I'm registered) appears in the same thread as the first one (sent before registering)
lucascastro has quit [Remote host closed the connection]
frieder has quit [Remote host closed the connection]
vagrantc has joined #u-boot
Xeroine has joined #u-boot
<sjg1>
Tartarus: I see huge progress with Kconfig in the last two releases
<sjg1>
Tartarus: Also there is only one ad-hoc SPL option remaining: CONFIG_SYS_SPL_MALLOC_START
<sjg1>
Tartarus: and it isn't even a SPL_TPL_ option
<sjg1>
Tartarus: So I suspect we could drop the SPL_TPL_ stuff and simplify the Makefiles if we want to
guillaume_g has quit [Ping timeout: 272 seconds]
<Tartarus>
apritzel: next has been open for a while
<Tartarus>
sjg1: Ugh, how'd I miss that one, I'll take a look
<apritzel>
Tartarus: yeah, fair enough, just wanted to check
<Tartarus>
I've been trying, in general, to take what I think of as the more risky patches in to -next when it opens rather than waiting for the merge window too, to give things more time still for testing.