Unable to mount rootfs

[tinito]

I'm trying to boot the image generate with buildroot (thanks so much for adding edison support!) but I still have some problems. U-boot finds the kernel, but then the kernel fails to mount rootfs:

Starting kernel ...

[    1.546249] Warning: unable to open an initial console.
[    1.552029] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,8)
[    1.552120] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.10.17 #1
[    1.552173] Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 466 2014.06.23:19.20.05
[    1.552239]  f6c37f18 f6c37f18 f6c37ed0 c1680fc3 f6c37ef0 c167d7e7 c17c5eb0 c1974260
[    1.552350]  00000000 f6c37f18 00008001 f677e000 f6c37f44 c18d9e3f c17b8148 f6c37f18
[    1.552458]  f6c37f18 fffffffe 00000000 fffffffe f7adcfc0 c17b7c39 6e6b6e75 2d6e776f
[    1.552565] Call Trace:
[    1.552616]  [<c1680fc3>] dump_stack+0x16/0x18
[    1.552671]  [<c167d7e7>] panic+0x87/0x181
[    1.552723]  [<c18d9e3f>] mount_block_root+0x1b1/0x234
[    1.552784]  [<c132174d>] ? SyS_mknod+0x2d/0x30
[    1.552835]  [<c18da020>] mount_root+0x5e/0x64
[    1.552887]  [<c18da16f>] prepare_namespace+0x149/0x18d
[    1.552942]  [<c1312be5>] ? SyS_access+0x25/0x30
[    1.552995]  [<c18d9bba>] kernel_init_freeable+0x1b0/0x1bd
[    1.553051]  [<c18d94de>] ? do_early_param+0x7a/0x7a
[    1.553107]  [<c166fd30>] kernel_init+0x10/0xd0
[    1.553160]  [<c168af77>] ret_from_kernel_thread+0x1b/0x28
[    1.553217]  [<c166fd20>] ? rest_init+0x80/0x80
[    1.553346] emmc_ipanic: panic notified
[    1.553383] emmc_ipanic: Crash partition in use!
[    1.553458] ------------[ cut here ]------------
[    1.553515] WARNING: at arch/x86/kernel/smp.c:123 native_smp_send_reschedule+0x4b/0x50()
[    1.553577] Modules linked in:
[    1.553621] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.10.17 #1
[    1.553672] Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 466 2014.06.23:19.20.05
[    1.553736]  00000000 00000000 f6c37d34 c1680fc3 f6c37d5c c123b1f4 c17cc45f c17bafc5
[    1.553849]  0000007b c121fbeb c121fbeb 00000000 f73ef880 f73fd880 f6c37d6c c123b232
[    1.553960]  00000009 00000000 f6c37d74 c121fbeb f6c37d90 c1275d27 00000001 ffff8b67
[    1.554070] Call Trace:
[    1.554113]  [<c1680fc3>] dump_stack+0x16/0x18
[    1.554168]  [<c123b1f4>] warn_slowpath_common+0x64/0x80
[    1.554225]  [<c121fbeb>] ? native_smp_send_reschedule+0x4b/0x50
[    1.554285]  [<c121fbeb>] ? native_smp_send_reschedule+0x4b/0x50
[    1.554348]  [<c123b232>] warn_slowpath_null+0x22/0x30
[    1.554403]  [<c121fbeb>] native_smp_send_reschedule+0x4b/0x50
[    1.554465]  [<c1275d27>] trigger_load_balance+0x137/0x1c0
[    1.554526]  [<c1269f89>] scheduler_tick+0xd9/0x100
[    1.554581]  [<c124ba85>] update_process_times+0x55/0x70
[    1.554642]  [<c128b33d>] tick_sched_handle.isra.10+0x2d/0x70
[    1.554703]  [<c128b540>] tick_sched_timer+0x40/0x70
[    1.554759]  [<c1260200>] ? __remove_hrtimer+0x40/0xa0
[    1.554815]  [<c126046b>] __run_hrtimer+0x7b/0x200
[    1.554871]  [<c128b500>] ? tick_sched_do_timer+0x50/0x50
[    1.554930]  [<c12611e7>] hrtimer_interrupt+0x117/0x2b0
[    1.554988]  [<c126daf5>] ? sched_clock_cpu+0x105/0x190
[    1.555051]  [<c168b654>] smp_apic_timer_interrupt+0x54/0x85
[    1.555113]  [<c140e0c8>] ? trace_hardirqs_off_thunk+0xc/0x14
[    1.555176]  [<c168626a>] apic_timer_interrupt+0x32/0x38
[    1.555238]  [<c12300d8>] ? intel_mid_hsu_switch+0x138/0x1c0
[    1.555297]  [<c167d8aa>] ? panic+0x14a/0x181
[    1.555351]  [<c18d9e3f>] mount_block_root+0x1b1/0x234
[    1.555410]  [<c132174d>] ? SyS_mknod+0x2d/0x30
[    1.555463]  [<c18da020>] mount_root+0x5e/0x64
[    1.555515]  [<c18da16f>] prepare_namespace+0x149/0x18d
[    1.555571]  [<c1312be5>] ? SyS_access+0x25/0x30
[    1.555624]  [<c18d9bba>] kernel_init_freeable+0x1b0/0x1bd
[    1.555682]  [<c18d94de>] ? do_early_param+0x7a/0x7a
[    1.555739]  [<c166fd30>] kernel_init+0x10/0xd0
[    1.555792]  [<c168af77>] ret_from_kernel_thread+0x1b/0x28
[    1.555850]  [<c166fd20>] ? rest_init+0x80/0x80
[    1.555896] ---[ end trace 8d7158639187ad3c ]---

I tried flashing the image both from a running yocto distribution and by using XFSTK, with same results.

Inspecting partitions from u-boot console I see:

boot > mmc part

Partition Map for MMC device 0  --   Partition Type: DOS

Part    Start Sector    Num Sectors     UUID            Type
  1     14336           2097152         00000000-01     83

Any advice to solve this?

[atlury]

Same problem here...not matter what i try it just doesnt boot Initramfs file. Even though I correct it by loading at the correct addresses.

[fhunleth]

Sorry - I've given up on Edison and Galileo. I can tell you that this was definitely working at one point, but I don't have any intention of spending any more time on the boards. If you get this working, I'd encourage you to submit your changes to upstream Buildroot. I had wanted to do that, but I needed Intel to distribute their kernel and uboot outside of the big Yocto tarball for it to be accepted. I was told that Intel was planning on doing that, but I gave up waiting for it to happen after 6 months or so.

[atlury]

Can you atleast share your setenv bootargs settings? Along with "load mmc" commands for Initramfs + kernel (more specifically load address and "zboot" command)? It be a kind help. :-)

[fhunleth]

It's been over a year. If it's not in this repository or https://github.com/fhunleth/bbb-buildroot-fwup/tree/edison/board/edison, then I'm not sure.

[atlury]

Appreciate it, gonna try out latest u-boot and report back (and probably syslinux if it works)

[atlury]

Okie I am going to release with instructions once I get it working (DIY style as well as full images). I have written another instructions albiet for arm that are here https://wiki.alpinelinux.org/wiki/DIY_Fully_working_Alpine_Linux_for_Allwinner_and_Other_ARM_SOCs

As we speak, I have compiled u-boot (2015 version), custom OSIP bin (using fwup), rootfs (livecd)...have to figure out a way to compile u-boot-env.bin file.

Most importantly

./tools/mkenvimage -s 0xaddress -o uboot-env.bin uboot-env.txt -s 0xaddress option allows to specify the size of the image to create. It must match the size of the flash area reserved for the U-Boot environment

-r option must be used when there are two copies of the environment stored in the flash and these options have to set while compiling the u-boot for edison in edison.h CONFIG_ENV_ADDR_REDUND and CONFIG_ENV_SIZE_REDUND.

We must tell mkenvimage whether you’re using a redundant environment or a single environment.

I was looking at redundant environment when browsing the great work frank has done especially while referring to https://github.com/fhunleth/bbb-buildroot-fwup/blob/edison/board/edison/fwup-simple.conf https://github.com/fhunleth/bbb-buildroot-fwup/blob/edison/board/edison/fwup-pingpong.conf

Thank you frank...will follow up here..

[thdxr]

@atlury Thanks! Looking forward to it

[thdxr]

@atlury Hey, did you make any progress with generating full images? Thanks!

[atlury]

Yes it boots fine, however there is one last issue. We can run any kind of OS now on Edison but the one last problem is this...

After flashing, I sometimes see folders with cryptic names poping up (garbled up).. I was thinking the intel flash tool fully doesn't format the internal emmc

And after that even if we try to reflash it using stock flash image it doesnt help.

I guess the problem stems from the fact that there is no way to directly format the internal emmc. At times we are only altering the partition tables.....i may have to find a way to wipe it clean before flashing any other image....

I honestly dont know if its the internal emmc issue or partition tables...

No help from here as well https://communities.intel.com/thread/103050

[fhunleth]

@atlury: This sounds familiar. If I remember right, the Intel flashing tool uses the image-size-blocks field in the OSIP header to figure out how many bytes to write. This is wrong, but the workaround is to modify image-size-blocks in the fwup file to the total size of your image / 512. It looks like I have it set to 0xc000 which would correspond to a 25 MB image. I don't know how big your image is, but I might try playing around with the OSIP header to affect the tool or fix Intel's flashing tool.

[atlury]

frank,

Is this where it should be changed?

osii 0 { os-major = 0 os-minor = 0 start-block-offset = ${UBOOT_OFFSET} ddr-load-address = 0x01100000 entry-point = 0x01101000 image-size-blocks = 0x0000c000 attribute = 0x0f }

I didnt realize the image-size-blocks field has to be changed. I remember you writing a comment somewhere as "#This need to be huge since xfstk uses it to figure out the size."

I will try to follow your advise and revert back...

[fhunleth]

Yes, that's the right place.

[atlury]

@fhunleth

quick question, does the image size blocks mean the total size including u-boot, rootfs etc or does it just mean the image size blocks relating to only rootfs image?

[fhunleth]

I've forgotten. I think that you'd need to go through xfstk to figure it out for sure.

[atlury]

@fhunleth

Dear Frank,

here is the osip config

define(BOOT_PART_OFFSET, 2048) define(BOOT_WRITE_OFFSET, 2056) # Skip 8 blocks (4K) before writing the U-Boot image define(UBOOT_ENV_1_OFFSET, 6144) define(UBOOT_ENV_2_OFFSET, 12288)

define(ROOTFS_PART_OFFSET, 14336) define(ROOTFS_PART_COUNT, 262144)

meta-product = "AL Intel Edison" meta-description = "This image boots to Linux Legacy Kernel." meta-version = "AL 3.4" meta-platform = "edison" meta-architecture = "x86" meta-author = "FH"

mbr mbr-a { include-osip = true osip-major = 1 osip-minor = 0 osip-num-pointers = 1

osii 0 {
    os-major = 0
    os-minor = 0
    start-block-offset = ${BOOT_PART_OFFSET}
    ddr-load-address = 0x01100000
    entry-point = 0x01101000
    image-size-blocks = 0x00090000
    attribute = 0x0f
}

partition 0 {
    block-offset = ${ROOTFS_PART_OFFSET}
    block-count = ${ROOTFS_PART_COUNT}
    type = 0x0b # FAT32
}

}

task complete { on-init { mbr_write(mbr-a) } }

Notice the image block size is 0x00090000 My rootfs is as follows dd if=/dev/zero of=rootfs.fat32 bs=1M count=100 mkfs.vfat -n "edison" -F 32 -v rootfs.fat32

Hardly 100MB and Image block size is very large enough however the board doesnt boot. Any ideas ????

[atlury]

@fhunleth @dax0

Sorry to hijack this thread but if it has to be told, it has to be told. I have done a bit of experimentation yesterday. If you enable (basically all being same blocks)

1) Rootfs-count to be 49152 2) Image-block-size to be c000 which is 49152 3) and keep the same count 49152 for BS=512 when creating using DD; the actual ext4 or fat file....

It seems to work. No garbled folders or anything. And it flashes correctly. I will have to do a bit more of testing before I can start releasing OS images.

[thdxr]

@atlury Awesome! I'm happy to help test if you have an image

[atlury]

@dax0

I will upload one soon...just testing a few things... any other size it doesnt work...even if they "all" are on the same block size..i cant understand why..be patient

[atlury]

@dax0

Update is that the Intel thingy (xfstk-dldr-solo.exe) can only flash the bootloader (i was told by intel folks) and not large files and also the bootloader wont repartition the emmc....hence they have the ugly hack of enabling dfu-util and then reflashing again the rootfs image using dfu-utils..exploring further to finalize...

[atlury]

@dax0 @fhunleth

Frank any last ideas for this?

http://paste.ubuntu.com/17465299/

XFSTK-LOG--usb_bulk_read() fails XFSTK-LOG--Windriver Error: 0x20000015, Timeout expired

Last nail in the coffin...is there an option to enable xfstk to do large transfer with large timeout option?

[atlury]

@dax0

Test release is here...

https://github.com/atlury/Intel-Edison-OS-Images/releases/download/AlpineLinux-3.4.0/Alpine-Edison-Distro.7z

More later...

[thdxr]

@atlury Thanks! Will try this out tonight

[mpapini]

@atlury any chance you could be so kind as to give us some indication as to how you were able to overcome this issue? I'm stuck at more or less where you were several months ago, and can't get the kernel to boot.

[atlury]

@mpapini there are multiple issues here. Please read through to gain some understanding a) https://communities.intel.com/thread/102968 b) https://communities.intel.com/thread/103309 c) https://communities.intel.com/thread/104366?start=15&tstart=0 d) https://communities.intel.com/thread/103050 e) https://communities.intel.com/thread/102412

Its an gigantic moronic epic mess. Edison as such. I can walk you through the entire steps but I can only do so in skype or gtalk.

You can find a Ubuntu Release I did for Edison here https://github.com/atlury/Intel-Edison-OS-Images/releases