Closed JaciBrunning closed 8 years ago
Hi Jaci,
this is related to the boot arguments passed to the kernel. Before actually booting the kernel, you may enter this command:
setenv bootargs "console=ttyS0,115200n8 earlycon=uart,mmio32,0x01c28000 root=/dev/mmcblk0p10 rootwait ro fsck.repair=yes"
and then
run boot_kernel;
This will tell the kernel to check the file systems before mounting them (which is highly recommended).
You can modify the u-boot environment which is loaded by run load_env;
by:
$ cat uEnv.txt
bootargs=console=ttyS0,115200n8 earlycon=uart,mmio32,0x01c28000 root=/dev/mmcblk0p10 rootwait ro fsck.repair=yes
_t=sunxi_flash read 76eb70e0 dtb; fdt resize; fdt addr 76eb70e0; sunxi_flash read 4107f800 shell; boota 4107f800;
_b=sunxi_flash read 76eb70e0 dtb; fdt resize; fdt addr 76eb70e0; sunxi_flash read 4107f800 mainline; boota 4107f800;
$ (cat uEnv.txt | tr '\n' '\0' ; /bin/echo -e -n "\0\0") | sudo dd of=/dev/mmcblk0p5
Thanks @umiddelb, manually interrupting U-Boot and setting bootargs successfully grants a read-write filesystem.
It seems however, that after modifying the /dev/mmcblk0p5
partition with the uEnv.txt file you provided makes the Pine spam the following to the console indefinitely (this is during autoboot)
[ 14.887]sunxi flash read :offset 7500000, 1048576 bytes OK
## Info: input data size = 345 = 0x159
If I manually interrupt the autoboot, load_dtb
, set_cmdline
, load_kernel
and boot_kernel
are all undefined.
yes, the uEnv.txt
contains two macros instead:
_b
, which will boot the kernel from the mainline/mmcblk0p9
partition._t
, which will boot the kernel from the shell/mmcblk0p7
partition.so after run load_kernel
simply issue run _b
. When you've finished to compile your own kernel, you can test it safely without overwriting your working kernel.
With some tweaking of that file I managed to get it to boot into mainline automatically at startup as a rw partition. Thanks for the help!
Now I just need to see if there's a way to get the Ethernet / USB Drivers for the board.
@umiddelb: thanks for jumping on it while my notebook was refusing to use WiFi ;-) @JacisNonsense: Traditionally Linux systems asked for having the rootfs first mounted read-only, to be able to do a filesystem check safely. After this check they should remount the rootfs read-write. Not sure why that didn't work in your case, but anyway it seems to be fixed now.
Regarding the environment issue: If you interrupt U-Boot, it does not know about any fancy commands, so you have to bootstrap them from sdx5 by typing "run load_env". This load_env command is the only one I actually hacked into the hardwired environment on the SD card. After having loaded the env from sdx5 you can use the commands defined in there (including your own ones if you put them there). But please keep in mind that this is still a hack and not considered a proper solution.
@JacisNonsense
you can find here the original contents of the u-boot environment, feel free to add them to your uEnv.txt
:
boot_kernel=boota $kernel_image_addr
boot_normal=run load_env; run bootcmd
bootargs=console=ttyS0,115200n8 earlycon=uart,mmio32,0x01c28000 ro root=/dev/mmcblk0p3 rootwait
bootcmd=run load_dtb load_kernel set_cmdline boot_kernel
dtb_part=dtb
fdt_addr=76eb70e0
fdtaddr=76eb70e0
init=/init
kernel_image_addr=4107f800
kernel_part=mainline
load_dtb=sunxi_flash read $fdt_addr $dtb_part; fdt resize; fdt addr $fdt_addr
load_env=sunxi_flash read 43000000 env; env import -b 43000000
load_kernel=sunxi_flash read $kernel_image_addr $kernel_part
loglevel=8
mmc_root=/dev/mmcblk0p7
nand_root=/dev/nandd
partitions=dtb@mmcblk0p2:altdtb@mmcblk0p5:bpart@mmcblk0p6:env@mmcblk0p7:boot@mmcblk0p8:shell@mmcblk0p9:debug@mmcblk0p10:mainline@mmcblk0p1
set_cmdline=setenv bootargs "console=ttyS0,115200n8 earlycon=uart,mmio32,0x01c28000 ro root=/dev/mmcblk0p10 rootwait"
setargs_mmc=setenv bootargs console=${console} root=${mmc_root}init=${init} loglevel=${loglevel} partitions=${partitions}
setargs_nand=setenv bootargs console=${console} root=${nand_root}init=${init} loglevel=${loglevel} partitions=${partitions}
@apritzel
I believe you need either have to add fsck.repair=yes
or /etc/fstab
contains a reference your rootfs.
@umiddelb I did change the values of the mmcblk05 parition manually, changing 'ro' to 'rw' and 'shell' to 'mainline'. It seems to be properly booting without any issues.
@apritzel Thanks for the help on the matter, I'm fairly new when it comes to dealing with stuff as low as the bootloader
Hey there!
It seems that after copying a rootfs (debian jessie, in my case) to the /dev/sdd10 partition (which I have formatted to ext4 via gparted) of the SD card, and following the instructions laid out in the readme, the board successfully boots into a linux shell. The issue, however, is that the partition the rootfs is located on is in readonly mode. Is there a step I'm missing, or is it to do with the way the partition was formatted?
Thanks, ~Jaci