<vagrantc>
hrm. i see a handful of files where the SPDX headers conflict with license notices in the file ... i suppose i should mention them on the mailing list?
<vagrantc>
a fair number of them are pulled in directly from linux, too ... to make the history a bit harder to make sense of.
<marex>
vagrantc: or send a patch
flyback has joined #u-boot
<vagrantc>
marex: well, a patch would require knowing what the right thing actually is.
<marex>
vagrantc: maybe an RFC patch ?
<vagrantc>
marex: in general, i would be inclined to accept the text over the SPDX ... but i suspect some files were licensed X or Y and SPDX just embedded X
<vagrantc>
stuff like that
<vagrantc>
i'll try to make a list, at least.
<marex>
vagrantc: I would rewrite everything to GPLv2 or v2+ , but that's just me
<marex>
vagrantc: thanks !
<vagrantc>
it's mostly GPLX || BSD-something
<vagrantc>
although ... the whole process of doing this review is exhausting and i will have to put this off a while :)
* vagrantc
waves
vagrantc has quit [Quit: leaving]
camus has joined #u-boot
mmu_man has quit [Ping timeout: 255 seconds]
persmule has quit [Quit: Leaving]
<ukky>
marex: arm-baremetal-elf toolchain works too, it was my fault, wrong .config settings.
<marex>
ukky: zynqmp is aarch64
<marex>
keep that in mind
<marex>
(except for pmu which is microblaze I think)
<ukky>
it can be compiled for zynqmp-r5 (arm)
<ukky>
yes, pmu is microblaze
<ukky>
for zynqmp-aarch64 baremetal toolchain works too
persmule has joined #u-boot
CounterPillow has quit [K-Lined]
<marex>
ukky: you cannot compile software for the aarch64 cores using armv7a toolchain
<ukky>
marex: agree. But I am using aarch64-baremetal-elf toolchain to compile U-Boot for ZynqMP-A53. arm-baremetal-eabi was just a test for U-Boot build for ZynqMP-R5
sakman_ has quit [Quit: Leaving]
sakman has joined #u-boot
<marex>
ok
gsz has joined #u-boot
Clamor has joined #u-boot
goliath has joined #u-boot
gsz has quit [Quit: leaving]
stefanro has joined #u-boot
stefanro has quit [Client Quit]
stefanro has joined #u-boot
monstr has joined #u-boot
ungeskriptet6 has joined #u-boot
ungeskriptet has quit [Ping timeout: 255 seconds]
ungeskriptet6 is now known as ungeskriptet
persmule has quit [Quit: Leaving]
jclsn has joined #u-boot
mckoan|away is now known as mckoan
frieder has joined #u-boot
persmule has joined #u-boot
sszy has joined #u-boot
sng has quit [Ping timeout: 240 seconds]
sng has joined #u-boot
mripard has joined #u-boot
stgloor has joined #u-boot
<stgloor>
Hi, I am having a weird problem with U-Boot 2023.10 on an Allwinner A20 (Olinuxino Micro board). There seems to be some sort of loop in the serial console, the output is somehow fed back as input, resulting in "Unknown command" errors.
<stgloor>
It looks like only some output lines are interpreted as console input, but they also seem to be mixed up somehow
<stgloor>
clarity: no, I tried with 2021.4 and I still had the same problem.
<stgloor>
I am building with Yocto and have now reverted all my changes, as it worked in the beginning... rebuilding from scratch now...
<stgloor>
I also disconnected the "RX" pin from my UART adapter, so it's not like the loopback is happening in the adapter or terminal software or something
<clarity>
Oh yocto and rebuilding from scratch.. se you next week then? D:
<clarity>
Sadly I don't have the micro board to play with :(
ldts_ has joined #u-boot
vagrantc has joined #u-boot
goliath has quit [Quit: SIGSEGV]
ikarso has quit [Quit: Connection closed for inactivity]
<ukky>
Can I preload environment data into DDR at specific address, set CONFIG_ENV_ADDR to that address, and enable CONFIG_ENV_IN_NVRAM? This is to define "scriptaddr" in DDR.
frieder has quit [Remote host closed the connection]
prabhakarlad has joined #u-boot
ungeskriptet has joined #u-boot
<marex>
clarity: crappy USB-serial adapter ?
<marex>
stgloor: ^
<marex>
stgloor: did you configure flow control (hw and sw) OFF in your terminal emulator ?
<marex>
stgloor: terminal set to 115200 8n1 ?
<f_>
hm I wonder if there's a minified pinctrl driver for SPL...
<f_>
Seems like I need it for eMMC to work on meson-gxl
<f_>
and I only have 44K available in total. Enabling CONFIG_SPL_PINCTRL overflows the max size..
<stgloor>
marex: USB-serial cable shouldn't be the issue, because it also occurs with the RX pin disconnected (so adapter can't send anything to board)
<stgloor>
marex: and yes, flowcontrol (hw/sw) is disabled and set to 115200 8n1
<marex>
stgloor: noise on some of the lines ?
<marex>
or missing pull resistor somewhere ?
<stgloor>
marex: unbelievable, that was it! thank you!
<stgloor>
Shorting the RX pin to GND fixed the problem
<stgloor>
So the TX pin (coming from the board) was actually directly interfering with the floating RX pin, generating this loopback effect
<stgloor>
I would have never believed the capacitive (?) coupling between two 2.54 mm header pins was so good that the UART receiver could actually receive readable text over it
persmule has quit [Remote host closed the connection]
<clarity>
stgloor: Oh so your RX pin was floating all along?
<clarity>
I thought you only disconnected after seeing the problem...
ldts_ has quit []
persmule has joined #u-boot
<stgloor>
clarity: Yes, I only disconnected it after seeing the problem and nothing changed, so I assumed it had nothing to do with it
<clarity>
Oh... so what caused the problem while the pin was still connected?
<stgloor>
clarity: I guess it must have been a faulty crimp contact on USB-serial adapter cable, I will replace it/solder it directly to see if it helps
<stgloor>
or as bswartz mentioned, poor grounding
<bswartz>
Sometimes it's worth paying more for an FTDI or other professional quality cable
monstr has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
<stgloor>
bswartz: lsusb tells me it's an FTDI cable, but I don't know where I got it or if it is genuine^^
<stgloor>
It's weird, connecting the RX and TX ends of the serial adapter gives loopback on the terminal, so I would think the adapter works
<stgloor>
But soldering the adapter cables directly to the board does not solve my problem... maybe there is something wrong with the board?
<stgloor>
I guess I have to get the oscilloscope out and investigate some more, anyway, thanks for the help!
<ukky>
stgloor: could TTL level on serial port be an issue? I have FTDI +3.3V UART2USB adapter, which does not work on standard RS232 due to different voltage levels
flom84 has quit [Remote host closed the connection]
<stgloor>
ukky: the label on the adapter says TTL-232R-3V3, so it should be the right one. The board is probably also 3.3V (need to check).
prabhakar has quit [Ping timeout: 255 seconds]
<bswartz>
Yeah make sure you didn't mix up the voltages
<bswartz>
In my experience real FTDI cables/chips are rock solid. There's some much cheaper stuff you can get on Amazon that works when you're lucky