How to boot and run from SD card?

[Jason Pepas]

I feel like I'm missing something obvious.  Every time I try to boot from an SD card, the LED turns blue and it copies the SD card to the onboard flash, then I reboot and the system runs from the onboard flash.

I want to boot *and run* from the SD card, *not* from the onboard flash.

I can't seem to find any notes or docs about this issue, so I'm guessing that I'm just missing something which is obvious to everyone else.

What do I need to do to accomplish this?

Thanks!

[Paul Cercueil]

Hi Jason,

Indeed, you are missing something obvious ;)

Technically the CI20 does boot from SD, but the software you have on
the SD card is the *flasher*. The only thing it will do is flash the
NAND.

If you want to boot a full operating system from the SD, then you need
a SD card with a full operating system installed on it.

Cheers,
-Paul


Le ven., nov. 22, 2019 at 18:55, Jason Pepas <jason...@gmail.com> a
écrit :

> --
> You received this message because you are subscribed to the Google
> Groups "MIPS Creator CI20" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to mips-creator-c...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/mips-creator-ci20/c1cd2078-1939-4422-9c9d-4e7fe5ddc9d5%40googlegroups.com.

[Jason Pepas]

Thanks Paul.  I thought that might be the case, so I mounted the filesystem on the SD card, but grep as I might, I couldn't find any obvious "copy the bytes to NAND script".

Where is the flasher?  Perhaps I can just disable it and run the OS install which is on the SD card normally?

> send an email to mips-cre...@googlegroups.com.

[Jason Pepas]

Ah, perhaps uboot itself is what flashes the NAND?  In the "Building the system images for boot from sdcard" section, they don't mention why they do this, but they use dd to wipe out the first 512-byte block of the SD card.

https://elinux.org/CI20_Dev_Zone#Making_a_bootable_SD_card_from_sources

[Paul Cercueil]

Either uboot flashes the NAND directly, or it loads a kernel + initramfs that contains the flasher software.

The first 512 bytes of the SD card is the first-stage bootloader, I suppose "mksdcard" writes it again after it's been wiped?

[Gabriele Svelto]

Hi Jason,

On 26/11/19 00:38, Jason Pepas wrote:
> Ah, perhaps uboot itself is what flashes the NAND?  In the "Building the
> system images for boot from sdcard" section, they don't mention why they
> do this, but they use dd to wipe out the first 512-byte block of the SD
> card.
>
> https://elinux.org/CI20_Dev_Zone#Making_a_bootable_SD_card_from_sources

this script is used to make SD cards that install to the internal flash:

https://github.com/ZubairLK/ci20_other_files/blob/master/make-flash-card-ci20-sd.sh

It generates a long boot command here:

https://github.com/ZubairLK/ci20_other_files/blob/master/make-flash-card.sh#L121-L156

That is stored in the U-boot environment here:

https://github.com/ZubairLK/ci20_other_files/blob/master/make-flash-card.sh#L161

So when you boot a card generated with that script those commands will
be the first ones to be executed and they will flash the internal NAND.

The other script available on that repo can be used to generate bootable
SD cards that don't write to the internal NAND flash:

https://github.com/ZubairLK/ci20_other_files/blob/master/make-flash-card-ci20-sd.sh

Hope this helps.

Gabriele

[Kai Nacke]

The script to flash the NAND is stored in the U-Boot environment starting at 526Kib (with a length of 32KiB).

You can wipe it with this command:dd if=/dev/zero of=/dev/mmcblk0 bs=1K seek=526 count=32

Regards,

Kai

[jason...@gmail.com]

Thanks so much for the replies everyone!

Sent from my iPhone

To unsubscribe from this group and stop receiving emails from it, send an email to mips-creator-c...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/mips-creator-ci20/6f50ee2b-738f-4a5c-991b-6902618d3906%40googlegroups.com.

[Jason Pepas]

Hi Gabriele,

I am revisiting this years later.

I'd like to use the https://github.com/ZubairLK/ci20_other_files/blob/master/make-flash-card-ci20-sd.sh script to create a bootable / runnable SD card image, but using your Gentoo kernel + rootfs, together with the u-boot modifications which you made which fix the RAM timings / stability issues.

The first step seems to be extracting these pieces from your image https://www.setphaserstostun.org/ci20/gentoo-2023-01-22.img.xz

However, I've been struggling with this.  I'm at the point where I have a bunch of ubifs files and am attempting to mount them using nandsim and ubiattach, but it isn't working.

Perhaps you have a kernel + rootfs tarball somewhere which I can simply download?

[Jason Pepas]

Actually, has anyone ever released a run-from-SD-card image which integrates your forked uboot which fixes RAM timings?

"it includes important fixes to the DDR memory timings that greatly improve the board's stability." https://www.setphaserstostun.org/pages/mips-creator-ci20-gentoo-resources/

[Jason Pepas]

Ok, I made some progress towards roofs-on-SD-card.

I used this script: https://github.com/ZubairLK/ci20_other_files/blob/master/make-flash-card-ci20-sd.sh

I used this rootfs tarball: http://mipscreator.mips.com/CI20/images/default_NAND/Debian8_20160602/rootfs_2016_06_02.tar

I had to 'apt-get install gcc-mipsel-linux-gnu' so the script could build u-boot.

I made an initial SD card with:

CROSS_COMPILE=mipsel-linux-gnu- ./make-flash-card-ci20-sd.sh /dev/sdc rootfs_2016_06_02/boot/uImage-3.18.3-ci20-1 rootfs_2016_06_02.tar

However, it didn't boot.  After hooking up a serial console, I saw this from u-boot:

Hit any key to stop autoboot:  0
** File not found /boot/uImage **
Wrong Image Format for bootm command
ERROR: can't get kernel image!
ci20# 

I was able to list the root directory from the u-boot prompt:

ci20# ext4ls mmc 0:1 /
<DIR>       4096 .
<DIR>       4096 ..
<DIR>      16384 lost+found
<DIR>       4096 bin
<DIR>          0 boot
<DIR>       4096 dev
<DIR>          0 etc
<DIR>       4096 home
<DIR>          0 lib
<DIR>       2492 media
<DIR>          0 mnt
<DIR>    5270623 opt
<DIR>       4096 proc
<DIR>        894 root
<DIR>          0 run
<DIR>       4096 sbin
<DIR>          0 srv
<DIR>       4096 sys
<DIR>          0 tmp
<DIR>       4096 usr
<DIR>       4096 var
ci20# 

But notice: a lot of those directory entries are zero-size.  That's not good.

And there's nothing in /boot:

ci20# ext4ls mmc 0:1 /boot
ci20#

I mounted the SD card in a linux box and double-checked: the files are in fact present:

$ ls -1 /boot
config-3.18.3-ci20-1
System.map-3.18.3-ci20-1
uImage
uImage-3.18.3-ci20-1
vmlinux.img

It appears other people have been experiencing this problem as well: https://forum.doozan.com/read.php?3,16125,16151

I tried the suggested work-around in that link by changing the mkfs.ext4 call in the script:

sudo mkfs.ext4 -E lazy_itable_init=0 ${device}1

but that didn't work.

What did work though, was changing the script to first format as ext2:

sudo mkfs.ext2 ${device}1

then make all of the filesystem changes, then unmount and convert to ext4:

echo "Converting from ext2 to ext4"
sudo umount ${sdMount}
unset sdMount
sudo tune2fs -O extents,uninit_bg,dir_index,has_journal ${device}1

Booting the CI-20 confirms the filesystem does get mounted correctly as ext4:

$ mount | grep mmc
/dev/mmcblk0p1 on / type ext4 (rw,relatime,data=ordered)

I then switched to using Gabriele's u-boot fork which includes the RAM timing fixes:

CROSS_COMPILE=mipsel-linux-gnu- UBOOT_REPO=https://github.com/gabrielesvelto/CI20_u-boot UBOOT_BRANCH=fixed-timings ./make-flash-card-ci20-sd.sh /dev/sdc rootfs_2016_06_02/boot/uImage-3.18.3-ci20-1 rootfs_2016_06_02.tar

I now have a working CI-20, running the stock Debian image, using the SD-card as rootfs, with the RAM timing fixes.

Not bad!

I'll write up a github gist which documents this and publishes the modified script.

[Jason Pepas]

Here's the write up, with the modifications I made to the script: https://gist.github.com/cellularmitosis/a79c663f2e8430bc58bab61d459c9c1b

[Paul Boddie]

On 2025-04-08 20:58, Jason Pepas wrote:
> Here's the write up, with the modifications I made to the script:
> https://gist.github.com/cellularmitosis/a79c663f2e8430bc58bab61d459c9c1b

Thanks for sharing your experiences and investigations! I can't be
particularly helpful with the details at the moment, but your
difficulties with booting from SD reminded me of an infuriating
unreliability I experienced with U-Boot on the CI20, where I repeatedly
had to copy the uImage file until it worked, which was obviously very
tedious, and in some cases I just gave up and spent my time on other
matters instead.

I think that my workaround was to make sure that the appropriate
partition on the card was not too large, and then the kernel would boot
every time. I could imagine that there is some strange offset-related
issue where a file (or parts of it) ends up out of range or incorrectly
located when handled by some code in U-Boot's ext4 implementation.
Limiting the size of the partition seemed to suppress the occurrence of
this issue, but perhaps that is just a coincidence.

Sorry I cannot be more specific, but maybe it is of interest
nevertheless.

Paul

[Jason Pepas]

Oh interesting that eventually, copying a file multiple times is also a workaround.  I have a suspicion that the “lazy” features of ext4 are somehow the culprit, despite the fact that disabling them somehow doesn’t fix the issue.

I am so curious where this bug actually lies!

[Gabriele Svelto]

Hi Jason,
I've been quite busy so I haven't looked into this in a while, however I
might be able to dig out my kernel and rootfs, they're lying somewhere
within my projects if you still need them.

One word of warning regarding stability though: my patches for the
memory timings improved stability a lot for me but didn't make the board
rock solid. Several days of continous operation would still freeze the
board, but not during idle time, it would usually happen under heavy
load. IIRC this is because there was a bug in the kernel WRT thread
synchronization and there was a fix floating around, but I don't
remember when I saw it. The only other way to make the board completely
stable that worked for me was to disable the second core, which isn't great.

Gabriele

On 4/9/25 03:13, Jason Pepas wrote:
> Oh interesting that eventually, copying a file multiple times is also a
> workaround.  I have a suspicion that the “lazy” features of ext4 are
> somehow the culprit, despite the fact that disabling them somehow
> doesn’t fix the issue.
>
> I am so curious where this bug actually lies!
>
> On Tue, Apr 8, 2025 at 3:51 PM Paul Boddie <pa...@boddie.org.uk
> <mailto:pa...@boddie.org.uk>> wrote:
>
> On 2025-04-08 20:58, Jason Pepas wrote:
> > Here's the write up, with the modifications I made to the script:
> > https://gist.github.com/cellularmitosis/

> a79c663f2e8430bc58bab61d459c9c1b <https://gist.github.com/
> cellularmitosis/a79c663f2e8430bc58bab61d459c9c1b>

[Jason Pepas]

Very interesting.  Actually, disabling the second core would be fine for me, as I’m only using this board as part of learning to write a compiler.  Do you remember how you did this?

[Gabriele Svelto]

On 4/9/25 10:35, Jason Pepas wrote:
> Very interesting.  Actually, disabling the second core would be fine for
> me, as I’m only using this board as part of learning to write a
> compiler.  Do you remember how you did this?

Yes, add maxcpus=1 to the kernel command line at boot.

Gabriele

[jason...@gmail.com]

Thanks Gabriele, here's a script I used which builds and flashes u-boot with modified env variables, without touching the existing ext4 rootfs: https://gist.github.com/cellularmitosis/d41c2805a0cae004000067c587d93826

I used this to disable the second CPU core.

[Arkadi Shishlov]

For a somewhat simpler system, definitely more reproducible, the Buildroot worked for me about 2 years ago.

I had to make some small changes there and added v6.x kernel config. Could put that into GitHub if you you're interested.

[Jason Pepas]

Oh I would definitely be interested in the v6 kernel!

On Thu, Apr 10, 2025 at 4:45 AM Arkadi Shishlov <arkadi....@gmail.com> wrote:

For a somewhat simpler system, definitely more reproducible, the Buildroot worked for me about 2 years ago.

I had to make some small changes there and added v6.x kernel config. Could put that into GitHub if you you're interested.

--

You received this message because you are subscribed to the Google Groups "MIPS Creator CI20" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mips-creator-c...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/mips-creator-ci20/f486f372-7332-4557-bd7e-abdd00f08417n%40googlegroups.com.

[Arkadi Shishlov]

On Thursday, 10 April 2025 at 19:00:24 UTC+3 jason...@gmail.com wrote:

Oh I would definitely be interested in the v6 kernel!

 

https://github.com/OpenDingux/linux

IIRC, this is working v6.1, no SMP,

and a patch below for UBI with onboard flash.

diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c
index a901f8edf..06d8a614c 100644
--- a/drivers/mtd/ubi/build.c
+++ b/drivers/mtd/ubi/build.c
@@ -869,13 +869,14 @@ int ubi_attach_mtd_dev(struct mtd_info *mtd, int ubi_num,
         * will die soon and you will lose all your data.
         * Relax this rule if the partition we're attaching to operates in SLC
         * mode.
-        */
+        * /
        if (mtd->type == MTD_MLCNANDFLASH &&
            !(mtd->flags & MTD_SLC_ON_MLC_EMULATION)) {
                pr_err("ubi: refuse attaching mtd%d - MLC NAND is not supported\n",
                        mtd->index);
                return -EINVAL;
        }
+       */
 
        if (ubi_num == UBI_DEV_NUM_AUTO) {
                /* Search for an empty slot in the @ubi_devices array */