Then my understanding seems to be correct. I intended to use these commands at the bootloader stage.
The story is that "tpl" does not interrupt the bootup. So the TTL Serial communication interface is suspected. But I later found out that it responded after the linux booted up. Does this mean that the Serial interface is setup correctly?
continue to starting system. 0
Or this count down at the bootloader stage is too quick for any input?
4: System Enter Boot Command Line Interface.
U-Boot 1.1.3 (Dec 13 2018 - 09:07:16)
bootz is not recognized.
MT7628 # help
? - alias for 'help'
base - print or set address offset
bootm - boot application image from memory
bootp - boot image via network using BootP/TFTP protocol
coninfo - print console devices and information
cp - memory copy
crc32 - checksum calculation
erase - erase SPI FLASH memory
go - start application at address 'addr'
help - print online help
start www server for firmware recovery
loadb - load binary file over serial line (kermit mode)
loop - infinite loop on address range
md - memory display
mm - memory modify (auto-incrementing)
mtest - simple RAM test
nm - memory modify (constant address)
printenv- print environment variables
rarpboot- boot image via network using RARP/TFTP protocol
reset - Perform RESET of the CPU
rf - read/write rf register
saveenv - save environment variables to persistent storage
setenv - set environment variables
spi - spi command
tftpboot- boot image via network using TFTP protocol
version - print monitor version
I tried "tftpboot", but it seems that it only did what "tftp" does, loading the file to an address and then stopped there.
Does it have anything to do with the options when I config the .bin with "make menuconfig"?
seems like a bin file issue to me. maybe the uboot of this v5 will do some sort of checking preventing this kind of files to bootup? the previously mentioned v3-header issue seems a good way to start, but I cannot find this v3-header support at compiling the binary.
a ramdisk is loaded from usb / tftp
a kernel+.rd is loaded from tftp / usb
an image is written to your flash in full or in parts, that is almost if not more difficult than (a) and is 97% odds on to brick your device.... and if it doesn't you'll likely need it to fix your device.... unless your a kermit master....... even still your back at (b)
more info? not always.... often an oem bootlog and shell access is enough to get info. but it won't help you when things go wrong.
try squashfs + tar.gz as well. ( then make > check for uImage.bin in bin/targ......... )