Serial Output Garbage after initial messages

[jamforlunch]

Hi, 

I've been trying for 3 days to get an linux image to boot on my RockPro64 without any success. I followed the initial sticky forum message and ended up waiting a day for 0% downloaded from various servers. 

Then I found the latest daily images and used a boot installer by concatenating the FW and partition, and burning the img to an SD in linux with dd. I cant seem to get a new single partition SD card to boot, I only had success with an SD I had used with my Pi - that has 3 or 4 partitions on it.

Anyway the new May 2022 installer got to 100%, then I got a flashing cursor where I could type, rebooted and back to the installer again.  Also, has anyone actually got a RockPro64 to install Debian and boot to it in the last 3 months ? If so, was there anything you had to do apart from create the SD image, answers the installer questions and let it install ? 

For the serial UART output, I watch it with 115200 baud, and I can see the initial messages, then it starts outputting garbage. Any reason it switches like that ? Is the first part the rom/boot at 115200, and then does the baud rate change when its running the installer ? 

NOTICE:  BL31: Built : 23:34:19, May 13 2022
INFO:    GICv3 with legacy support detected.
INFO:    ARM GICv3 driver initialized in EL3
INFO:    Maximum SPI INTID supported: 287
INFO:    plat_rockchip_pmu_init(1624): pd status 3e
INFO:    BL31: Initializing runtime services
INFO:    BL31: cortex_a53: CPU workaround for 855873 was applied
WARNING: BL31: cortex_a53: CPU workaround for 1530924 was missing!
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x200000
INFO:    SPSR = 0x3c9
⸮⸮⸮⸮⸮_O⸮bWWG⸮_GG_⸮f⸮⸮⸮G⸮c⸮"gGGG^gGG⸮⸮GoW_WW⸮O⸮WWF⸮_Ww⸮ݾ_⸮⸮⸮^⸮gW_gG_wo⸮GE⸮OOO}_fWWVGfDWFg_⸮FWF/⸮NFND⸮VgFFF⸮oWFGowFgoFGGF'O⸮⸮^____O⸮FG⸮gǮ⸮ϧDoOn⸮/F⸮F_fooW⸮NngDwDFFD_⸮FFogO⸮&G_FF_⸮WFFWnFFDWGFWFGFW⸮⸮W⸮FGGFGFFGGD⸮WFFFGDFFGGWF⸮FFDfFfDGWF⸮FWWF⸮FnW_ooGOFGw^Wo⸮n⸮v⸮FOFg_FnDNFF_g⸮_FOODWOOFO_"F⸮V⸮V⸮FV^GW.FgOV^D⸮⸮FVfOOD⸮W⸮O⸮OoG⸮MgFg⸮O~_g⸮⸮F/D_/F⸮g⸮e>⸮FWGF^GbFg_⸮FG⸮⸮F⸮G_F⸮⸮F\_FOf_G⸮nFO_bOOfF⸮⸮G_b__OF⸮_FGGF_⸮⸮VFDG⸮⸮GF⸮⸮FOFg⸮⸮FFGO_fF_F⸮⸮⸮⸮FW_O⸮DOWO7W⸮⸮oD⸮DFGFGD⸮O⸮WN/Fw⸮⸮F⸮G/o⸮w⸮wODG⸮wOGNF⸮⸮Wf_o⸮F_o^^/VF/⸮wFGwGwFGG⸮⸮FOF?FWGWWWWVWoWN"NG^gF"Vo"FW6o6oWG⸮W6ogV__R__VW⸮VOg⸮_7FO⸮_⸮f⸮⸮vWOFg'_nw⸮⸮⸮OnF⸮⸮V⸮⸮VFW_~⸮FG_⸮F&⸮nF⸮nFTGOn⸮⸮g⸮^G'N'O⸮G_⸮⸮GFOWNo>o"f7_oGF_⸮TgO⸮VoW⸮⸮G^F_^GN^⸮N__GFoOFGNF_⸮o⸮FGf_fWf_ofO⸮f⸮⸮dw⸮⸮gW_⸮⸮⸮⸮NGddOFnG⸮gVF⸮⸮FGOFGVWO^GOFWVOgFgOF⸮GnGFnF⸮GFGF⸮⸮g_g_⸮⸮oG_g_GV_w_wO⸮Gg⸮⸮VOvWG_WV_OOOTGoOGoO⸮GwGGLNWWVW⸮OvF^gT⸮WVG⸮O⸮G⸮⸮V⸮wFw⸮V⸮^⸮oG⸮⸮GVGOG⸮GWVOGN⸮wVB⸮VwOO⸮o⸮DG⸮GGBWf_oODGW⸮⸮GWFGGGWoOGTGdNoGG⸮D⸮NOOGFOGGWoFGoNf⸮NoGFgFogG⸮G⸮⸮'7⸮FfMOTogϯ_⸮FFFFFFF⸮FFFF⸮FDFF⸮⸮⸮FFFF⸮DF⸮FFFFFFFFFFFFnFF⸮>^FDFFNvFF~^F&N>FF⸮⸮vFF^F⸮NfffFF^FF⸮>D⸮^FFNvF&NFvNF&^Fv⸮tFF⸮F&F⸮⸮F.>ffFFF⸮vF&F⸮NFNG^F^FN⸮tN>FN⸮FNF⸮N⸮F⸮vff.⸮FG^FfFNN⸮F.fFv⸮F>F⸮f^FNFN^F>F^G⸮F&ff&f⸮F⸮⸮⸮lN⸮fNVfN&⸮fGf⸮N.⸮^vGv⸮v⸮GF⸮⸮f$⸮vG⸮N>^^⸮GVf⸮f⸮GG^⸮⸮n⸮NFFF⸮FFvFF⸮FFFF⸮FFFF⸮FFFFF⸮FFFFDFFDF⸮FFFFFFFFFFFFF^FFFFFFFFFFFFDFFFFFFFF⸮FFFF⸮FFFFFFFFFFFFFFFFFF
FFFF⸮FFFFF⸮FFfFF⸮FFF&⸮FFFDDFFFFFFFFFF⸮FFFFFF⸮FF⸮FFFvFFFFFFFFFF&FFFFFFFFFFFFFFFF⸮^FFFFFFFFFFFFFFFFFFFfFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF&FFFFFFFFFFFFFFFFDFFvFFFFFF^FFFFFFFDFFFFFFFFFFFFFFDFFFDFFF^_OwO&W_G.FFFFF.FFFFFFN⸮FFFFFFFFFF&FF⸮FFF⸮⸮F^FDd⸮FFFFFFf>FFFF&FFFF.FFFDF&OFNVF.^^GNfF⸮vV.⸮v

U-Boot and the OS can have different baudrates, try 1500000 if you want to read the second part.

Thanks for the info, changing the board rate didnt work though. Now I have switched to using a Debian install from mr fixit - its an old kernel version 4 from 2019 - but its the only one I got working. 

Do you know if the latest Debian works on the RockPro64 - with all its peripherals ?