<matthewcroughan->
I've tried to get in touch with Naoki, the maintainer of rock-4c-plus-rk3399 for the past 3-4 days now, does anybody have any insight into whether the build results for this board were ever tested? I've been looking around the commits, PRs and mailing lists and I cannot find anything to indicate it was, and the u-boot-rockchip.bin build result flashed seek=64 into an SD Card does not yield anything. The RK33 ROCKCHIP_MAGIC is
<matthewcroughan->
present and mkimage seems to think the result is fine, but there is no activity over serial on the board.
<matthewcroughan->
could CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y really be it? :D
camus has quit [Ping timeout: 245 seconds]
rvalue has quit [Ping timeout: 246 seconds]
sng_ has joined #u-boot
sng has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
sng has joined #u-boot
sng_ has quit [Read error: Connection reset by peer]
sng_ has joined #u-boot
sng has quit [Ping timeout: 245 seconds]
<matthewcroughan->
Nope, still appears to do nothing in my case
sng_ has quit [Remote host closed the connection]
<matthewcroughan->
Ah.. okay.. now I'm getting somewhere. I get scrambled serial if I set CONFIG_BAUDRATE=115200, whereas if I leave it at the default I get no serial at all
<matthewcroughan->
I guess my cable isn't up to the job :D
sng has joined #u-boot
sng has quit [Remote host closed the connection]
sng has joined #u-boot
sng has quit [Remote host closed the connection]
sng has joined #u-boot
<marex>
matthewcroughan-: you seems to have missed this naoki person
<marex>
oh
<marex>
matthewcroughan-: btw if this is aarch64 system, you likely do need the atf blob
<marex>
matthewcroughan-: do you have that blob ?
<matthewcroughan->
bl31.elf?
<matthewcroughan->
Here's the logs I'm getting from u-boot, a bit scrambled however https://termbin.com/n7uap
<matthewcroughan->
I'll double check and try ga1b10fcc92 of arm-trusted-firmware
<matthewcroughan->
Kwiboo: Excellent, thank you so much
<sjg1>
matthewcroughan-: Yes it's supposed to be 1.5Mbaud though, if that matters
<Kwiboo>
not sure that is the correct git sha for atf, but this was using a build of the atf v2.8 tag
<matthewcroughan->
Yeah I'm building with 2.9, may cause an issue, it's possible but unlikely
<marex>
remembering my massive issues with STM32MP13xx, TFA and OpTee-OS due to firmware ABI incompatibility and the tragic way in which TFA is maintained, I wouldn't be surprised Y_Y
<sjg1>
marex: What happened to pulling that stuff into U-Boot, or at least making it a library? Last I looked it has libfdt!
<matthewcroughan->
marex: can you give me the exact commit hash your thing is based on?
<matthewcroughan->
v2.8.0 is currently at 9881bb9, I'd love to make triple sure that I'm using the same as you
<matthewcroughan->
Also, can you tell me what commit of u-boot you're using?
<marex>
sjg1: what stuff ?
<marex>
matthewcroughan-: ask Kwiboo
<matthewcroughan->
Oh derp, misread the chat log sorry
<matthewcroughan->
Kwiboo: and you're flashing the resulting `u-boot-rockchip.bin` in order to achieve the log you posted?
<matthewcroughan->
thank you so much, this will reveal if I have other issues going on :D
sng_ has joined #u-boot
<sjg1>
marex: ATF bits
<matthewcroughan->
Does the ATF not end up in u-boot-rockchip.bin because of binman?
<Kwiboo>
matthewcroughan-: look like I was having a patch for atf that changed RK3399_BAUDRATE to 1500000, here are new boot logs: https://gist.github.com/Kwiboo/e11b04dda9cba08ef7b17429b55deb41 one using atf v2.9 and the second one using rkbin bl31 v1.36
<marex>
sjg1: you have to ask ARM why they dont want to cooperate on single bootloader codebase, but rather fragment the landscape
<sjg1>
marex: I think I have done that enough, but ARM has not exactly led the way on bootloader innovation, so waiting for something from them seems brave to me
persmule has joined #u-boot
<matthewcroughan->
Kwiboo: What is rkbin needed for exactly? If my build produces a u-boot-rockchip.bin, do I still have to do some post-processing on this?
<Kwiboo>
rkbin bl31 is an atf blob provided by rockchip, you should use mainline atf 2.9, my pipeline is only setup to use rkbin blobs as BL31=
<matthewcroughan->
I wonder what's going wrong then.
<matthewcroughan->
I'm building natively, not cross-compiling, only other problem I can think of.
<matthewcroughan->
Kwiboo: `9525248 bytes (9.5 MB, 9.1 MiB) copied, 6.28027 s, 1.5 MB/s` how many bytes does your 2.9 ATF have?
<matthewcroughan->
when put into the u-boot-rockchip.bin, I mean
persmule has quit [Remote host closed the connection]
<Kwiboo>
matthewcroughan-: you should not put anything into u-boot-rockchip.bin yourself, just build u-boot using e.g. make BL31=/path/to/bl31.elf etc. and binman puts it in u-boot-rockchip.bin
<Kwiboo>
the resulting u-boot-rockchip.bin have everything or build should have failed
<matthewcroughan->
Yeah that is what I thought, and now the only difference I can see between what you are doing and what I am doing is that you're cross-compiling and I am not
<matthewcroughan->
I don't seem to have a cable that can do that baudrate, sadly ;D
<matthewcroughan->
I would be able to try if you set it to CONFIG_BAUDRATE=38400, I'm really not sure why this is the case, as I've been using 115200 on other boards just fine, but I can only get normal output at 38400 on this board
<matthewcroughan->
although I'm going to try it and see if it boots my OS via HDMI still
<matthewcroughan->
Oh and additionally, the official OS images seem to be garbled at 1500000, until they boot into the OS, on my cable, once in the OS I can use it just fine, it's very odd
sng_ has quit [Remote host closed the connection]
rvalue has quit [Ping timeout: 246 seconds]
rvalue has joined #u-boot
<matthewcroughan->
It seems unhappy still, but I have no cable that can verify what's going on at that baudrate
<matthewcroughan->
Just borrowed a genuine FTDI, hopefully produces different results
<matthewcroughan->
I don't seem to get any output even with a genuine ftdi cable from your u-boot-rockchip.bin Kwiboo
<matthewcroughan->
Yeah, still can't achieve 1.5mbps even with a genuine ftdi cable
<matthewcroughan->
115200 is still garbled with that too
sng_ has joined #u-boot
qqq has quit [Quit: leaving]
<matthewcroughan->
Kwiboo: what serial cable are you using? What does it report in `dmesg` when you plug it in? I want to see if we have the same cable, or if yours is different in some way. I'm unable to achieve 1.5mbps with any cable I have here, including genuine FTDI
<matthewcroughan->
Kwiboo: My board is revision V1.41, can you confirm what your board revision is?
<marex>
__ad: any plan to clean up NEEDS_MANUAL_RELOC on m68k ?
<matthewcroughan->
An external TPL is required to initialize DRAM. Get the external TPL
<matthewcroughan->
Is this actually still necessary to include in the build?
<Kwiboo>
matthewcroughan-: I also have the v1.41 revision and are using the pine64 "Woodpecker" for serial console, and you only need atf 2.9 built for rk3399 and build u-boot with rock-4c-plus-rk3399_defconfig and BL31=/path/to/your/aft-2.9/bl31.elf
<matthewcroughan->
Not to bother too much, but can you do a CI run with a baudrate of 38400 so I can see what's going on?
<Kwiboo>
ROCKCHIP_TPL and other rkbin blobs is only required for newer SoCs like rk3568 and rk3588, they do not have open source version of TPL or TF-A
<matthewcroughan->
and just to confirm, you're attaching your serial to UART2 not UART4?
<Kwiboo>
correct, uart2 and 1500000 baudrate is the default on rockchip
<matthewcroughan->
Additionally, the logs are very random. Sometimes U-Boot tells me that there's a 256B stride. Sometimes Trying to boot from BOOTROM and sometimes Returning to boot ROM... TPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###
<matthewcroughan->
Sometimes 0B stride
<matthewcroughan->
Whatever the case, it never seems to get to the SPL
<Kwiboo>
have you tried with another sd-card or emmc module, or any of the vendor images and see if they work? your device could be damaged
<matthewcroughan->
There is no emmc module inserted into the board, it came without one, and I do not have one. The vendor images work fine, that's what's so confounding about this :D
<matthewcroughan->
mkimage reports the same for the vendor images and my u-boot image
<matthewcroughan->
Well, slightly different, but same magic
<matthewcroughan->
But yes, even with the vendor images, u-boot is corrupted on all of my serial cables, at 1.5mbps.
<matthewcroughan->
Only once the OS boots does it stabilize and allow me to read it at 1.5mbps
<matthewcroughan->
vendor images won't be using the upstream u-boot though, they'll be using the old vendor methods, right?
<matthewcroughan->
I have thought about trying to reproduce the vendor methods, but I figure it's a better use of time to try to get official u-boot working
<matthewcroughan->
Kwiboo: just tried my fourth FTDI based cable, all from different manufacturers and various kinds, I can't get any serial out of your github actions binaries
<matthewcroughan->
the baudrate is just too damned high! :d
<marex>
matthewcroughan-: why not just reduce the baudrate ?
<marex>
matthewcroughan-: doesnt the code allow that ?
<matthewcroughan->
I have, on my builds, and my builds don't boot anything and do not get to the SPL for some reason
<matthewcroughan->
whereas kwiboo's builds supposedly work, and I want to test them on my hardware
<matthewcroughan->
but I can't test kwiboo's builds without 1.5mbps, which 4 of my serial cables cannot achieve
<matthewcroughan->
4 diverse FTDI cables, 2 laptops, screen and picocom, 1.5mbps, it's a no go
<matthewcroughan->
Only on one of the cables do I get anything, and it's just garbage chars
<Kwiboo>
matthewcroughan-: you should probably build with verbose debug logging and to see how far it gets
<matthewcroughan->
Kwiboo: Oh what's the option to do that?
<matthewcroughan->
SPL malloc() before relocation used 0x22b0 bytes (8 KB)
<matthewcroughan->
Trying to boot from BOOTROM
<matthewcroughan->
>>TPL: board_init_r()
<matthewcroughan->
Freezes at "Trying to boot from BOOTROM"
<matthewcroughan->
but only occasionally. Sometimes it freezes at Finish SDRAM initialization...; SPL malloc() before relocation used 0x22b0 bytes (8 KB) >>
<matthewcroughan->
Kwiboo: it looks like there's an FDT Overlap, I've modified `lib/fdtdec.c` to print a better log `FDT:000000000031ecf0 gd:00000000002fbdf0 top:0000000000334000 &stack_ptr:00000000002fbdac `
<clever>
but i dont know what LTO would do in that case
<Forty-Bot>
I think what's happening is that LTO is inlining everything, but these functions still need to be separate so they can be called in arm mode
<clever>
yeah, its possible it inlined it into a thumb function
<clever>
and LTO was able to just rebuild it in thumb mode, except for the asm
<clever>
throw a no-inline on it as well? will LTO respect that?
rvalue has joined #u-boot
<marex>
Forty-Bot: is there no thumb equivalent or what ?
<Forty-Bot>
marex: not for arm5-arm6
<marex>
arch/arm/lib/ashldi3.S- ARM( orrmi ah, ah, al, lsr ip )
<marex>
arch/arm/lib/ashldi3.S: THUMB( lsrmi r3, al, ip )
<marex>
cfr ^
<Forty-Bot>
yeah, I think I'm going to end up just using a .S file, since it gets compiled correctly (afaik)
<marex>
Forty-Bot: err , are you using inline asm or just C code that is miscompiled ?
<marex>
if C code that is miscompiled, then that's compiler bug
<Forty-Bot>
inline asm
<Forty-Bot>
since the __builtin version was calling out to a library function
<marex>
so what ?
<marex>
just call the library function ?
<marex>
that one probably handles it correctly, no ?
<Forty-Bot>
it's part of the gcc builtins
<clever>
then -lgcc ?
<marex>
... so ? :)
<Forty-Bot>
well, the goal is to reduce code size
<marex>
clever: you cannot do that easily
<marex>
Forty-Bot: which function is that ?
<marex>
Forty-Bot: u-boot already does provide PRIVATE_LIBGCC