Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
1,814 Views

Booting intel edison board from SD card or pendrive

Jump to solution

Tutorials are available just for rootfs that will boot from SD.

I have some cases that I would like to know

1 . I would like to put u-boot and kernel images in external SD card/ Pen-drive and bring up the board without using flash memory or internal SD.

2 . Then from u-boot, I would like to read external SD card, and copy kernel/DTB/rootfs in RAM.

Is these two scenarios are possible ?

3 . What is the booting process of edison board.

4 . In u-boot, how to read file (zImage using fatload) from external SD card. In my case I am not able to see external SD card if I command mmcinfo.

Thanks in advance.

Any help will be appreciated.

0 Kudos

Accepted Solutions
Highlighted
Valued Contributor I
38 Views

AFAIK you can not have u-boot on the sd card.

When booting a microkernel is loaded from ROM. Roughly this loads u-boot from the internal flash.

The latest u-boot supporting eds (without acpi) is here: https://github.com/andy-shev/u-boot/tree/edison GitHub - andy-shev/u-boot at edison

I don't think this one can load the kernel directly from sd card either, it also needs to be on the internal flash. If it doesn't you would need to add support for the sd card into u-boot.

And finally (again AFAIK) the kernel drivers for the sd card need to be built as modules, so you need a kernel with initramfs containing these. Updated (unofficial) meta-intel-edison automating the build process is here: https://github.com/htot/meta-intel-edison/tree/pyro64-acpi GitHub - htot/meta-intel-edison at pyro64-acpi

View solution in original post

0 Kudos
35 Replies
Highlighted
Community Manager
38 Views

Hello Pritam,

 

 

Thank you for your interest in our Intel products.

 

Your request has been received and is currently being investigated.

 

We will get back to you as soon as possible.

 

 

Regards,

 

Octavian
0 Kudos
Highlighted
Valued Contributor I
39 Views

AFAIK you can not have u-boot on the sd card.

When booting a microkernel is loaded from ROM. Roughly this loads u-boot from the internal flash.

The latest u-boot supporting eds (without acpi) is here: https://github.com/andy-shev/u-boot/tree/edison GitHub - andy-shev/u-boot at edison

I don't think this one can load the kernel directly from sd card either, it also needs to be on the internal flash. If it doesn't you would need to add support for the sd card into u-boot.

And finally (again AFAIK) the kernel drivers for the sd card need to be built as modules, so you need a kernel with initramfs containing these. Updated (unofficial) meta-intel-edison automating the build process is here: https://github.com/htot/meta-intel-edison/tree/pyro64-acpi GitHub - htot/meta-intel-edison at pyro64-acpi

View solution in original post

0 Kudos
Highlighted
Beginner
38 Views

Thanks for your quick response.

My actual intention is to compile and modify u-boot and kernel,

I am using ubuntu 17.10, where yocto is getting failed to create images. For errors https://stackoverflow.com/questions/48373815/yocto-fails-to-build-images-for-intel-edison-in-ubuntu-... 48411915 https://stackoverflow.com/questions/48373815/yocto-fails-to-build-images-for-intel-edison-in-ubuntu-... 48411915 , refer this link.

And I have tried following steps on buildroot

1 . make edison_defconfig.

2 . make

and Images are installed in output/images.

But when I tried to flash u-boot on board using https://edison.internet-share.com/wiki/U-Boot This Link,

3 . Then I did truncate -s %4096 u-boot.bin in output/images

4 . dfu-util -v -d 8087:0a99 --alt u-boot0 -D u-boot.bin

5 . run do_force_flash_os on board

I am able to flash the u-boot on board successfully. But board is not booting up with new u-boot .

What is process to use images built from buildroot ?

How to flash bzImage and .img file on board from output/images ?

NOTE : I used https://github.com/htot/meta-intel-edison/wiki/6.4-Recovery 6.4 Recovery · htot/meta-intel-edison Wiki · GitHub to recover the board.

Now my requirements are

1 . How can i modify u-boot and kernel manually without using yocto and buildroot. and flash them on flash mem. ?

2 . Buildroot is able to create images in output/imgaes. how can i use them to flash on board ?

3 . I have compiled u-boot manually and flashed successfully, but how to compile kernel and flash it on board manually.

Any help will be appreciated and for further activities, I will keep you posted.

Thanks

.

0 Kudos
Highlighted
Valued Contributor I
38 Views

If you follow this link under unsorted the is how get a newer u-boot and vanilla kernel: https://edison.internet-share.com/wiki/Main_Page https://edison.internet-share.com/wiki/Main_Page

I think your u-boot update process is right, but maybe your u-boot version not. Try one from https://github.com/andy-shev/u-boot/releases Releases · andy-shev/u-boot · GitHub with tag starting with edison.

I see you don't want to use Yocto, but it pretty much does exactly what you want: download and build a u-boot and kernel. Keep in mind that to have your rootfs on the sd card the kernel needs drivers and the drivers need to be compiled as module (last time I checked). Long story short, eventually you need a kernel with initramfs with these drivers built-in.

If you try this one https://github.com/htot/meta-intel-edison/tree/pyro64-acpi GitHub - htot/meta-intel-edison at pyro64-acpi you will see it does what you want. You should then be able to reproduce using buildroot. Actually I think 0andriy uses buildroot for his kernel developments.

0 Kudos
Highlighted
Employee
38 Views

Yes, indeed, I'm using plain Buildroot distribution for development.

FerryT, I would rather suggest to point to the upstream U-Boot instead of my repo. Since v2017.09 Intel Edison is supported out-of-the-box. So, no need to be dependent on my custom repository anymore.

Yes, there are still issues, but they should be addressed properly in upstream. Referring to my repo provides people an ugly hacks and they would (faulty) think that everything works as expected.

0 Kudos
Highlighted
Beginner
38 Views

Thanks for quick response,

I will keep you posted for further studies.

0 Kudos
Highlighted
Valued Contributor I
38 Views

0andriy Yes sorry, you are right of course. For non-acpi builds use upstream U-Boot with a few patches applied by the recipe.

0 Kudos
Highlighted
Beginner
38 Views

I followed the link given in https://github.com/htot/meta-intel-edison/wiki Home · htot/meta-intel-edison Wiki · GitHub

But it's failed in building native qemu. I have attached the logs with this reply.

I am completely new to yocto, I am not able to figure it out.

Do I need to change any recipe or install packages in ubuntu . ?

NOTE Steps followed

1. installed sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib build-essential chrpath socat cpio python python3 libsdl1.2-dev xterm python3

2. git clone mailto:git@github.com git@github.com/htot/meta-intel-edison.git

3. git checkout pyro64

 

4. ln -s meta-intel-edison/utils/Makefile.mk Makefile

5. make setup

6 . make image

Other than this steps, do I need to do anything else .?

0 Kudos
Highlighted
Valued Contributor I
38 Views

Ah, yes. You should not be building qemu at all. But there is a bug (in the setup script) in pyro64, and it got fixed in pyro64-acpi. I hope you will try checking out that one. By default, you will get non-acpi u-boot and kernel.

0 Kudos
Highlighted
Beginner
38 Views

Thanks, and sorry for above reply where I posted a wrong step.

Yes, I am working in pyro64-acpi branch as we can see in errors log attached in above reply.

I will try to build the setup without qemu.

Am I missing any set up ?

I will keep you posted for further studies.

0 Kudos
Highlighted
Valued Contributor I
38 Views

I meant different: qemu should not be built, there is nothing you should need to do. That bitbake is trying to build qemu means your are being hit by a bug in the setup script that i probably fixed after you cloned my repo. Please checkout again. The problem is the local.conf is not correct, so then you fall back to a default and that builds qemu.

One you have the bad local.conf it will not be created again, unless you clean.

So after new checkout I think you will need to:

make clean

make setup

then follow the instructions:

echo "cd $my_build_dir"

echo "source poky/oe-init-build-env"

echo "bitbake -k edison-image"

Then there should be no errors (and only one warning). And no building of qemu. No error

ERROR: Nothing PROVIDES 'bcm43340-mod'. Close matches:

bcm43340-fw

0 Kudos
Highlighted
Beginner
38 Views

I followed above steps as given that was helpful to remove qemu errors.

I was almost done with the build, but I am getting errors in native nodejs.

Do I need to patch files in recipes ?

Logs I have attached with this reply.

0 Kudos
Highlighted
Valued Contributor I
38 Views

No, patching recipes should not be necessary. I looks like in your case 'make clean' does not sufficiently clean. You are just a bit unlucky.

Can you please try again:

'make clean'

'rm -rf bbcache/sstate-cache/*'

and then:

'make setup'

I just built from scratch myself and found no problems:

ferry@delfion:~/tmp/edison-intel/my/edison-morty/tmp/out/linux64/build$ bitbake -k edison-image

NOTE: Your conf/bblayers.conf has been automatically updated.

WARNING: Host distribution "ubuntu-17.10" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.

Parsing recipes: 100% |# | Time: 0:00:39

Parsing of 1942 .bb files complete (0 cached, 1942 parsed). 2712 targets, 343 skipped, 0 masked, 0 errors.

NOTE: Resolving any missing task queue dependencies

Build Configuration:

BB_VERSION = "1.34.0"

BUILD_SYS = "x86_64-linux"

NATIVELSBSTRING = "ubuntu-17.10"

TARGET_SYS = "x86_64-poky-linux"

MACHINE = "edison"

DISTRO = "poky-edison"

DISTRO_VERSION = "2.3.3"

TUNE_FEATURES = "m64 core2"

TARGET_FPU = ""

meta

meta-poky

meta-yocto-bsp = "pyro:e31d17d2e1a7a011f5ba0f14f392763846bd80fd"

meta-oe

meta-python

meta-networking = "pyro:dfbdd28d206a74bf264c2f7ee0f7b3e5af587796"

meta-nodejs = "master:eec531e97a17bfd406f3bf76dee4057dcf5286a4"

meta-intel = "pyro:8a2c9aee14eccca3e798d0c45bb5f8485f342c2c"

meta-intel-edison-bsp

meta-intel-edison-distro

meta-intel-iot-middleware = "pyro64:27b20329b7d2165628eda8183dc293ae0f399344"

meta-acpi = "eds:3242f7d08882cacf30d350495b93d0b7beff5465"

NOTE: Fetching uninative binary shim from http://downloads.yoctoproject.org/releases/uninative/1.7/x86_64-nativesdk-libc.tar.bz2;sha256sum=ed0...

--2018-02-16 14:21:31-- http://downloads.yoctoproject.org/releases/uninative/1.7/x86_64-nativesdk-libc.tar.bz2

Resolving downloads.yoctoproject.org (downloads.yoctoproject.org)... 198.145.29.63

Connecting to downloads.yoctoproject.org (downloads.yoctoproject.org)|198.145.29.63|:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: 2286285 (2.2M) [application/octet-stream]

Saving to: '/home/ferry/tmp/edison-intel/my/edison-morty/tmp/bbcache/downloads/uninative/ed033c868b87852b07957a4400f3b744c00aef5d6470346ea1a59b6d3e03075e/x86_64-nativesdk-libc.tar.bz2'

2018-02-16 14:21:33 (2.02 MB/s) - '/home/ferry/tmp/edison-intel/my/edison-morty/tmp/bbcache/downloads/uninative/ed033c868b87852b07957a4400f3b744c00aef5d6470346ea1a59b6d3e03075e/x86_64-nativesdk-libc.tar.bz2' saved [2286285/2286285]

Initialising tasks: 100% |# | Time: 0:00:05

NOTE: Executing SetScene Tasks

NOTE: Executing RunQueue Tasks

WARNING: libmpc-native-1.0.3-r0 do_fetch: Failed to fetch URL http://www.multiprecision.org/mpc/download/mpc-1.0.3.tar.gz, attempting MIRRORS if available

WARNING: libpng-native-1.6.28-r0 do_fetch: Failed to fetch URL <a cl...

0 Kudos
Highlighted
Valued Contributor I
38 Views

Prityaa Have you been able to build using my last instructions?

BTW I uploaded another branch rocko64-acpi, based on rocko of course. This has acpi enabled by default, but you easily disable that if you prefer (see the commit that enables it)

0 Kudos
Highlighted
Beginner
38 Views

Regret for the late reply, I was on long vacation. I will inform you post doing above instructions.

and Thanks.

0 Kudos
Highlighted
Beginner
38 Views

Thanks for your suggestions, I followed the above instructions (make clean && rm -rf bbcache/sstate-cache/*).

But it is getting failed in nodejs. Logs I have attached below.

0 Kudos
Highlighted
Valued Contributor I
38 Views

The first error you have is unable to fetch prelink-native. Which is strange as http://git.yoctoproject.org/cgit/cgit.cgi/prelink-cross/?h=cross_prelink prelink-cross - Cross capable Prelink just works. I can't reproduce this error.

I am rebuilding on another machine to check the build.

First thing I found is that libelf-dev is also a prerequisite (added to wiki page).

And I get heaps of packages with Checksum failure. All originating from sourceforge, apparently sourceforge is messed up.

But I can reproduce the nodejs error. I don't know what is wrong, as it did build before. I'll get back on this.

Nodejs won't build with gcc-7 without patch. From the log files for nodejs-native and nodejs I see:

x86_64-poky-linux-g++ -m64 -march=core2 .... (nodejs)

g++ -I/home/ferry/out/linux64/build/tmp/work/x86_64-linux/nodej... (nodejs-native)

AFAIKT nodejs builds fine and nodejs-native fails (on this current test machine). And gcc -v gives:

gcc version 7.2.0 (Ubuntu 7.2.0-8ubuntu3.2)

There are 2 quick ways to solve this:

1) install gcc 6.3 and use alternatives to make it default. I just did:

sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-6 10

sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-7 20

sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-6 10

sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-7 20

sudo update-alternatives --config gcc

sudo update-alternatives --config g++

2) checkout the rocko branch, this already has a fix for gcc 7

0 Kudos
Highlighted
Beginner
38 Views

Thanks for your all help.

I have fetched all rocko-acpi in current working project.

It is successfully bitbaked but with some warnings .

and make image and post bitbake logs are attached.

Will this affect on future activities . ?

0 Kudos
Highlighted
Valued Contributor I
38 Views

Prityaa thanks for testing this. I noted too:

WARNING: edison-image-1.0-r0 do_populate_lic: ${COREBASE}/LICENSE is not a valid license file,...

and will fix that soon. For now, it does no harm.

I also noted that if I switch to building a 32b image there is an error building 'perf'. To fix that I need to a patch to the kernel (already tested).

rocko64-acpi turns on building a acpi enabled U-Boot and kernel. You can easily find the patch that does that and revert it if you don't want acpi.

If you leave it like this: the edison acpi tables are in U-Boot, but we also have sample tables for the edison-arduino board.

You can load those manually by running `acpi-tables-load` or `systemctl start acpi-tables-load`.

If you want them auto loaded on boot `systemctl enable acpi-tables-load`

0 Kudos