Hello!
Have a try to change console port from ttyS2 to ttyS5 (have a serial shield that use ttyS2 port for data exchange).
Make changes from 0xff4c0000 to 0xff4f0000 address in DEBUG_UART_BASE, have a try to change fiq_debugger in dtsi to serial-id = <5>, have a try to change in bootargs.
No any success, just lost console after "Starting kernel..." in some cases while disable or make incorrect sets for FIQ.
As I understand, need to setup/correct *early_init* procedures in bootloader to change console port in uboot and later kernel will get it as earlycon (maybe wrong).
I think this makes into two tasks - change it in bootloader and change it in kernel.
Any advise how can change if it possible. I need to have console on ttyS5 to login for debug and other ports for data transfer.
Thanks!
Alex
change console from ttyS2 to ttyS5
Hello, ttyS2 as a UART debug port starts from the ddr.bin phase and is shared through the preloader firmware mechanism to the spl.bin and uboot, but it does not include the kernel phase. Both global replacement (replacing DDR.bin) and replacing only UBOOT are feasible. The global replacement method involves modifying <luckfox-pico SDK>/sysdrv/source/uboot/rkbin/tools/ddrbin_param.txt (refer to ddrbin_tool_user_guide.txt for configuration). Please note that incorrect settings may cause it to fail to run, and in the worst-case scenario, you may need to forcibly enter MaskROM mode to recover. We are not responsible for this.
If your application runs after entering the rootfs, changing the ddr.bin and uboot settings is meaningless, and we strongly discourage making such changes. If you're only replacing the kernel, your settings might be missing a pinctrl definition in rv1106.dtsi, and the status of the uart5 node may not have been changed to disabled in the final inherited DTS.
If your application runs after entering the rootfs, changing the ddr.bin and uboot settings is meaningless, and we strongly discourage making such changes. If you're only replacing the kernel, your settings might be missing a pinctrl definition in rv1106.dtsi, and the status of the uart5 node may not have been changed to disabled in the final inherited DTS.
Entering maskrom mode you mean boot button while switching power? And use SocToolKit to flash?
Another flashing question. New batch arrives and first tested chip shows:
in console while flashing it via SocToolKit. This is bad flash chip?
What about warranty?
Flash chips don`t tested after assembling pico board?
Another flashing question. New batch arrives and first tested chip shows:
Code: Select all
sfc_nand_check_bad_block page= 1bf80 ret= 0 spare= 0
e: 6fe00 is bad block skip0
What about warranty?
Flash chips don`t tested after assembling pico board?
The previous answer contains a correction: the status of uart5 in the DTS must be ensured to be disabled.
Forcing the device into maskrom mode involves shorting the storage chip's CLK pin to GND, which makes the main control ROM boot assume there is no storage medium, thus entering maskrom mode. At this point, you can use USB to erase the faulty image and restore the device to its initial state. This operation is a last-resort measure when the Luckfox Pico is out of control, but it carries the risk of damaging the storage chip.
The SPI flash versions of the Luckfox Pico come with a factory-programmed image to ensure that the SPI flash works correctly. Regarding bad blocks, our flash supplier guarantees that the proportion of bad blocks will not exceed 2%. Information about bad blocks, including new ones that develop during use, will be recorded in the first block of the flash. Bad blocks are an unavoidable issue when producing SPI NAND. If you are unable to successfully program the device, please consult your Luckfox Pico supplier for after-sales service.
Forcing the device into maskrom mode involves shorting the storage chip's CLK pin to GND, which makes the main control ROM boot assume there is no storage medium, thus entering maskrom mode. At this point, you can use USB to erase the faulty image and restore the device to its initial state. This operation is a last-resort measure when the Luckfox Pico is out of control, but it carries the risk of damaging the storage chip.
The SPI flash versions of the Luckfox Pico come with a factory-programmed image to ensure that the SPI flash works correctly. Regarding bad blocks, our flash supplier guarantees that the proportion of bad blocks will not exceed 2%. Information about bad blocks, including new ones that develop during use, will be recorded in the first block of the flash. Bad blocks are an unavoidable issue when producing SPI NAND. If you are unable to successfully program the device, please consult your Luckfox Pico supplier for after-sales service.
Have a try to change debug port with ddrbin.
Use Pico Max for tests. This board layout have uart1 on same pins that on plus are uart5.
Have dump rv1106_ddr_924MHz_v1.10.bin loader config by ddrbin_tool:
./ddrbin_tool -g dump_params.txt rv1106_ddr_924MHz_v1.10.bin
dump result have expected uart2:
Have change this params in ddrbin_param.txt -
./ddrbin_tool ddrbin_param.txt rv1106_ddr_924MHz_v1.10.bin
Replaced BIN file in /sysdrv/source/uboot/rkbin/bin/rv11 and make clean build.
After that - board loads well and can access by ethernet, but no any bytes from loader on uart1 or other uarts. Other uarts except uart1 are work well under linux.
Have check idblock.img - it have corrected bin with 0x800 offset with changed byte for serial1.
Also have change uboot CONFIG_DEBUG_UART_BASE to 0xff4b0000, it compiles and shows correct serial@ff4b0000 in binary file and same in uboot.img. But uart1 no makes any signs of life. Seems first preloader that after correction of 1 byte in rv1106_ddr_924MHz_v1.10.bin - makes this changes not correct and makes uart1 unavailable for future use in uboot and kernel.
Have check pdf that uart1 on pico max have same mux M1 as on uart2 port. Mux seems correct, but no any preloader boot text on uart after changing by ddrbin util.
Also have test on default firmware that uart1 works OK as /dev/ttyS1. No any wire/hardware problem. Only preloader makes me crying.
Another one strange thing - uart1 don`t pulls up after switching power on (on serial converter led are half-bright), just a second - and it pulls up (led half-bright off) with blinking activity led from kernel. Seems preloder and bootloader don`t access it and uart1 only inits later by dts/kernel/fiq.
Any ideas are welcome.
Alternatively, I can try to make changes to uart3 or uart4, but debug need on this exact pins of uart1 on pico max.
Use Pico Max for tests. This board layout have uart1 on same pins that on plus are uart5.
Have dump rv1106_ddr_924MHz_v1.10.bin loader config by ddrbin_tool:
./ddrbin_tool -g dump_params.txt rv1106_ddr_924MHz_v1.10.bin
dump result have expected uart2:
Code: Select all
...
uart id=2
uart iomux=1
uart baudrate=115200
...
Code: Select all
uart id=1
uart iomux=1
uart baudrate=115200
Replaced BIN file in /sysdrv/source/uboot/rkbin/bin/rv11 and make clean build.
After that - board loads well and can access by ethernet, but no any bytes from loader on uart1 or other uarts. Other uarts except uart1 are work well under linux.
Have check idblock.img - it have corrected bin with 0x800 offset with changed byte for serial1.
Also have change uboot CONFIG_DEBUG_UART_BASE to 0xff4b0000, it compiles and shows correct serial@ff4b0000 in binary file and same in uboot.img. But uart1 no makes any signs of life. Seems first preloader that after correction of 1 byte in rv1106_ddr_924MHz_v1.10.bin - makes this changes not correct and makes uart1 unavailable for future use in uboot and kernel.
Also have test on default firmware that uart1 works OK as /dev/ttyS1. No any wire/hardware problem. Only preloader makes me crying.
Another one strange thing - uart1 don`t pulls up after switching power on (on serial converter led are half-bright), just a second - and it pulls up (led half-bright off) with blinking activity led from kernel. Seems preloder and bootloader don`t access it and uart1 only inits later by dts/kernel/fiq.
Any ideas are welcome.
Alternatively, I can try to make changes to uart3 or uart4, but debug need on this exact pins of uart1 on pico max.
Same manipulations to change uart2 to uart3 - all ok, reloader send all to uart3, same byte have changed from 0x21 to 0x31.
And other uboot and kernel also OK with changes to uart3 just for FIQ, no any other address change or config files.
Seems only uart1 problem in preloader/rkbin.
And other uboot and kernel also OK with changes to uart3 just for FIQ, no any other address change or config files.
Seems only uart1 problem in preloader/rkbin.
Hey! I've also been trying to change pico console from ttyS2 to ttyS4, and i've changed everything that i was supposed to: uart parameters for ddr.bin, stdout-path in uboot dts:
fiq_debugger in uboot dts (also disabled uart4 in final one):
I've also done the same for linuix kernel dts: changed fiq_debugger to uart4:
and i also disabled uart4 in kernel dts. It makes absolutely no difference for idbloader and u-boot. Moreover, tty console get lost after kernel loading process start. Idk, is there any more configuration parameters to change? Any advice is appreciated, thanks!
Code: Select all
chosen {
stdout-path = &uart4;
u-boot,spl-boot-order = &sdmmc, &spi_nor, &spi_nand, &emmc;
};
Code: Select all
fiq_debugger: fiq-debugger {
compatible = "rockchip,fiq-debugger";
rockchip,serial-id = <4>;
rockchip,wake-irq = <0>;
rockchip,irq-mode-enable = <0>;
rockchip,baudrate = <1500000>; /* Only 115200 and 1500000 */
interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>;
status = "disabled";
};
Code: Select all
fiq_debugger: fiq-debugger {
compatible = "rockchip,fiq-debugger";
rockchip,serial-id = <4>;
rockchip,wake-irq = <0>;
rockchip,irq-mode-enable = <0>;
rockchip,baudrate = <115200>; /* Only 115200 and 1500000 */
interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>;
status = "disabled";
};