Ok trying filling the gaps
Boot rom -> u-boot ->. Openwrt
Some boot rom versions support loading u-boot loadind from serial if given any with kwboot software from another machine
Right. There is a very small ROM in the SoC which runs before anything in flash. It's function is mostly to get the RAM controller and RAM chips initialized and usable to store data. Then (in normal operation) it will load the bootloader from flash to RAM and jump to it.
A few SoC have an additional feature to load from serial to RAM, to recover in case there is not a usable bootloader in the flash.
The problem seems to have started when I followed some instructions for installing OpenWrt on this unit, in particular the command:-
nand erase 0x0 0x100000
From the section
Install u-boot and OpenWrt 18.06.1 into NAND via serial cable and tftp-server
in
This seems to have zapped the existing uBoot, but I suspect the environment remains and that is interfering in the boot. Not exactly sure where that lives...
Here is my environment:-
GoFlexHome> printenv
baudrate=115200
bootcmd=run startboot; run bootubi
bootdelay=3
bootdir=/boot
bootfilem=uImage
bootfilez=zImage
bootm=run load_debian; echo Booting from ${type} ${disk}:1 ...; bootm ${uimage_addr} ${initrd_addr} ${fdt_addr}
bootpart=1:1
bootubi=echo Trying to boot from NAND ...; if run mountubi; then ubifsload ${loadaddr} /boot/zImage;ubifsload ${fdtaddr} /boot/dtbs/${fdtfile}; ubifsumount; setenv boota
rgs console=${console} ubi.mtd=1 root=ubi0:rootfs ro rootfstype=ubifs rootwait ${mtdparts}; bootz ${loadaddr} - ${fdtaddr}; fi
console=ttyS0,115200
devnum=2
ethact=egiga0
ethaddr=00:10:75:28:cc:00
fdt_addr=0x1c00000
fdt_file=/boot/dts/kirkwood-goflexhome.dtb
fdtaddr=0x800000
fdtdir=/boot/dts
fdtfile=kirkwood-goflexhome.dtb
fileaddr=810000
filesize=2eb
initrd=/boot/uInitrd
initrd_addr=0x1100000
ipaddr=192.168.1.23
load_debian=setenv type usb; setenv disk 0; run set_bootargs; echo Running loadfdt ...;run loadfdt; echo Running loaduinitrd ...;run loaduinitrd; echo Running loaduimage
...; run loaduimage
loadaddr=0x810000
loadfdt=ext2load ${type} ${disk}:1 ${fdt_addr} ${fdt_file}
loadimage=load ${devtype} ${bootpart} ${loadaddr} ${bootdir}/${bootfilez} || load ${devtype} ${bootpart} ${loadaddr} ${bootdir}/${bootfilem}
loadrd=load ${devtype} ${bootpart} ${rdaddr} ${bootdir}/${rdfile}
loaduimage=ext2load ${type} ${disk}:1 ${uimage_addr} ${uimage}
loaduinitrd=ext2load ${type} ${disk}:1 ${initrd_addr} ${initrd}
mainargs=setenv bootargs console=${console} ${mtdparts} root=${root} rw rootwait ${optargs} ${ncargs}
mountubi=ubi part rootfs; ubifsmount ubi0:rootfs
mtddevname=u-boot
mtddevnum=0
mtdids=nand0=orion_nand
mtdparts=mtdparts=orion_nand:1M(u-boot),-(rootfs)
ncip=10.10.10.5
ncipk=10.10.10.4
netconsole=on
partition=nand0,0
preboot=if env exists netconsole && test ${netconsole} = on; then if ping ${ncip}; then setenv stdin nc; setenv stdout nc; setenv stderr nc; version; if env exists ncarg
susr; then echo ncargs has been defined by user; setenv ncargs ${ncargsusr}; else setenv ncargs ignore_loglevel netconsole=6665@${ipaddr}/eth0,6666@${ncipk}/; fi; fi; el
se echo Netconsole has been turned off.; echo To turn it on, set netconsole variable to on.; setenv stdin; setenv stdout; setenv stderr; setenv ncargs; fi
rdaddr=0x1100000
rdfile=initramfs-linux.img
serverip=192.168.1.2
set_bootargs=setenv bootargs console=$console root=LABEL=rootfs rootdelay=10 $mtdparts
startboot=usb start; ide reset; for devtype in usb ide; do setenv devnum 0; while ${devtype} dev ${devnum}; do echo ${devtype} found on device ${devnum}; setenv bootpart
${devnum}:1; echo Checking for: ${bootdir}/uEnv.txt ...; if test -e ${devtype} ${bootpart} ${bootdir}/uEnv.txt; then load ${devtype} ${bootpart} ${loadaddr} ${bootdir}/
uEnv.txt; env import -t ${loadaddr} ${filesize}; echo Loaded environment from ${bootdir}/uEnv.txt; echo Checking if uenvcmd is set ...; if test -n ${uenvcmd}; then echo
Running uenvcmd ...; run uenvcmd; fi; fi; if run loadimage; then if env exists root; then echo root has been defined by user; else part uuid ${devtype} ${bootpart} uuid;
setenv root PARTUUID=${uuid}; fi; run mainargs; if run loadfdt; then if run loadrd; then bootz ${loadaddr} ${rdaddr}:${filesize} ${fdtaddr}; else bootz ${loadaddr} - ${
fdtaddr}; fi; else if run loadrd; then bootm ${loadaddr} ${rdaddr}:${filesize}; else bootm ${loadaddr}; fi; fi; else echo No kernel found; fi; setexpr devnum ${devnum} +
1; done; done;
uimage=/boot/uImage
uimage_addr=0x800000
Environment size: 3560/131068 bytes
GoFlexHome> .]0;root@archlinux:~/projects/u-boot.[root@archlinux u-boot]# exit
logout
Not sure if kwboot needs any of this to boot.... Can I zap it all and incrementally add any variables I need via /boot/uEnv.txt ?
Is your
bootpart 1:1
Command right ??
Too many u-boot versions recipes online
With different env ... difficult to understand
Could @jeff or somebody else guide you
With a step by step guide by console command instead of running bootcmd ?
Like stop the boot up process
Then
Usb reset
And so on ?
I think the whole environment is screwed.
I'm looking at how to replace it so that it works properly with my .kwb .
1 Like
Guess there should be a way !!
Does u-boot handles both uimage and zimage?
What is the ls equivalent for u-boot
After usb reset
And
usb scan ?
This is going to be the easiest path for you to learn more about the process without creating more issues for your self. So invest some time in understanding this.
2 Likes
First you need to complete the process of writing the bootloader to the mtd0 flash partition that you erased (which as the other post painstakingly explained, was simply a failure to round up the file size to the next 1 kB increment). This should allow it to boot (at least into u-boot) out of flash each time the power is turned on without needing kwboot serial download. The bootloader you're loading with kwboot likely has its own environment built in and changes you make to it will not be persistent.
1 Like
Actually saveenv saves variables in the environment and are persistant between kwboot reboots, by my experience.
So next question will be:
Where does it saves them and how ?
setenv ?? uenv ??
U-Boot typically saves its environment on a partition on flash.
Inexpert or panicked changes to that partition or U-Boot environment can easily render the unit unbootable.
Temporary changes to the U-Boot environment can generally be made through the U-Boot console. This is the recommended approach, rather than altering the saved environment.
Thank @jeff this kwboot things is making my logic wandering !
For normal uboot I’ve found thi blog
Very informative:
https://www.vermasachin.com/posts/3-u-boot-environment-variables/
@jeff another question or two
1 - So booting from kwboot I can only use compiled uboot env into my uboot.bin ? Or not?
Then I can flash a new uboot.bin compiled with the CONFIG_ENV_SIZE variable and then I can flash next to it the u-boot env.bin (blob ?) compiled from uboot mkenvimage using a text file and setting the blob size same as CONFIG_ENV_SIZE ?
2- I dumped my ar150 uboot env on a file ? How can I read its content ? Meaning using a hex reader isn’t quite informative to my eyes ?
With the warning that I'm not very familiar with kwboot!!!
Assuming that kwboot loads its own bootloader over serial, I would guess that:
- Compiled-in parameters of the flash-resident U-Boot are not present
- The flash-resident U-Boot environment might be read by the bootloader downloaded and started by
kwboot
The AR150 is a very different device. From what I understand, kwboot is specific to a different SoC family. If you want to "see" what is stored there, hexdump -C <path-to-partition-dump> generally reveals key=value pair data.
So my u boot env only FF FF ad infinitum means I am relaying on env written on u boot main ?
If you've got the right partition and it's "empty", most likely yes.
GL.iNet has a full-featured U-Boot through their own, on-going, development efforts. , so it wouldn't surprise me that they've made it self-contained.
Edit
Are you sure you've got the right partition?
From my AR300M-Lite:
root@OpenWrt:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00040000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00fa0000 00010000 "firmware"
mtd3: 00190000 00010000 "kernel"
mtd4: 00e10000 00010000 "rootfs"
mtd5: 00a50000 00010000 "rootfs_data"
mtd6: 00010000 00010000 "art"
root@OpenWrt:~# hexdump -C /dev/mtd1ro
00000000 aa 1f 78 57 62 6f 6f 74 61 72 67 73 3d 62 6f 61 |..xWbootargs=boa|
00000010 72 64 3d 43 55 53 35 33 31 2d 4e 41 4e 44 20 63 |rd=CUS531-NAND c|
00000020 6f 6e 73 6f 6c 65 3d 74 74 79 53 30 2c 31 31 35 |onsole=ttyS0,115|
00000030 32 30 30 20 20 75 62 69 2e 6d 74 64 3d 35 2c 32 |200 ubi.mtd=5,2|
00000040 30 34 38 20 72 6f 6f 74 3d 2f 64 65 76 2f 6d 74 |048 root=/dev/mt|
[...]
After managing to reinstall u-boot on my GoFlex Home, I'm trying figure how the whole thing works....
According to https://openwrt.org/toh/seagate/goflexhome this is the Flash Layout
Flash Layout
Original FlashLayout
mtd# mtd0 mtd1 mtd2 mtd3
start 0x000000 0x100000 0x500000 0x2500000
size 0x100000 0x400000 0x2000000 0xdb00000
in MiB 1 4 32 219
name u-boot uImage root data
file system none ??? JFFS2 ??
so why do the instructions for install u-boot have this:-
download from tftp-server u-boot.kwb file to RAM start offset 0x6400000
tftp 0x6400000 u-boot.kwb
rather than installing at 0x000000
My current u-boot was installed using:-
nandwrite /dev/mtd0 uboot.2017.07-tld-1.goflexhome.mtd0.kwb
Can't I do a similar thing with u-boot.kwb?
is not in flash. If you read carefully above you will find references to downloading and booting from RAM. Understanding the difference between the two is very important to your success.
Yes, an expert user likely could. However, any mistake made may, or may not be recoverable.
1 Like
I’ll re-check and let you know could be I didn’t scroll down the entire hex dump