I need to boot from kernel image uImage which already flashed onto sdcard using dd command of linux.
from u-boot prompt
u-boot>....
To load the kernel from the SDcard, you probably need to do something like:
> mmc dev 1
> mmc read ${loadaddr} 0x800 0x2000
> bootm
Related
I have an embedded device with an emmc and a qspi-flash, both of which have an operating system on them.
From the OS running in the qspi-flash, I have a rootFS.ext4 file, the entire root filesystem for the OS on the emmc. From the qspi, I can see /dev/mmcblk1p3, which is the rootfs partition of the emmc.
I am trying to do
dd if=root.ext4 of=/dev/mmcblk1p3 bs=1M
Unfortunately when i then boot from the emmc, the kernel is complaining that it cannot mount to mmcblk1p3.
What is the correct way to completely erase the contents of the original filesystem and overlay the new filesystem image into the partition? Am I missing a step?
The mmc partitions are gpt.
The rootfs file I was using was incorrect.
I also needed to clear the exisiting filesystem by using mkfs.ext4.
Now the dd worked and the new rootfs was copied. I was able to successfully boot up from the emmc and see the new version of the rootfs.
I have some linux kernel & SFP/I2C driver issue.
I am using a buildroot linux kernel for an embedded board.
I need to be able to read the eeprom file of the SFP i2c device.
1. working case:
When SFP module is inserted in my development unit board from the start (before the kernel loads up) then when startup completed i can see and read the eeprom file in the path: /sys/class/i2c-adapter/i2c-1/1-0050/eeprom
kernel prints on startup the i2c device scan result:
2. not working case:
If there is no SFP module inserted on startup,and kernel completes the boot procces, then when i'm inserting the SFP module in,i observe that the path:
/sys/class/i2c-adapter/i2c-1/1-0050/ DOESN'T include the eeprom file.
The device tree part of the sfp-eeprom code:
My guess is the SFP driver is responsible for that trigger that should happen once the SFP module is inserted, and should trigger the creation of eeprom file.
Would like to ask you what am i missing ?
some binding code from sfp driver to trigger the i2c scan or something?
Any suggestion?
Thanks in advance.
A possible workaround for this issue was found.
to use the ethtool -m interface.
from ethtool man page:
-m --dump-module-eeprom
Retrieves and if possible decodes the EEPROM from plugin modules, e.g SFP+, QSFP
I am trying to port eCos on an i386 PC.
I have downloaded prebuilt redboot.bin from
http://ecos.sourceware.org/ecos/boards/redbootbins/x86pc/
I boot it onto usb disk, using
dd conv=sync if/redboot.bin of=/dev/sdb1
After booting target from usb, I get "IA2!" string on the target monitor always, and on serial port on 38400 8n1 configurations, I receive nothing.
I tried using i386-elf-gdb, but it is not able to connect to the target and starts printing "Ignoring error packet, Continuing..."
I also tried to build redboot using configtool for i386, but it is only able to build library, when I try Tests, It gives ERROR: multiple definition of cyg_start()
I am very new to eCos, and I don't know what I am doing wrong!!.
Ok, I figured out how to boot Redboot on a target i386 pc with RealteK RTL8139 ehternet card.
install grub on usb stick,
mkdir /mnt/USB && mount /dev/sdx1 /mnt/USB
grub-install --force --no-floppy --boot-directory=/mnt/USB/boot /dev/sdx
Build Redboot using ecosconfig, make sure the number of pci bus are less than 8 or more, if more, then need to increase the pci bus range from from 8 inside pci.h, I had my realtek ethernet card on bus 10 dev 10, I had to increase the bus to 11, so that redboot finds realtek card on bootup.
ecosconfig new pc redboot
configtool ecos.ecc
add common ethernet support
Build Library
copy redboot.elf on usb.
on grub startup menu,
insmod multiboot
multiboot /redboot.elf
boot
Thats it, redboot will use BOOTP and provide IP Address, then I can test redboot commands like ip_address, reset, ping, version etc.
DFU does not seem to work on a development board (Hitex LPC1850 or Keil MCB1800), but the manual states that it should work.
I could not find the same problem on the internet, so I posted my problem here.
(I manually compiled dfu-util 0.7, but the lpcXpresso bundled binary gives similar result)
tijs#debian:~/u-boot$ sudo ../dfu-util/src/dfu-util -R -D u-boot-dfu.bin boot/u-boot/u-boot-dfu.bin dfu-util 0.7
Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc. Copyright 2010-2012 Tormod Volden and Stefan Schmidt This program is Free Software and has ABSOLUTELY NO WARRANTY Please report bugs to dfu-util#lists.gnumonks.org
Opening DFU capable USB device...
ID 1fc9:000c Run-time device DFU version 0100
Claiming USB DFU Runtime Interface...
Determining device status: state = dfuIDLE, status = 0
dfu-util: WARNING: Runtime device already in DFU state ?!?
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0100
Device returned transfer size 2048
Copying data from PC to DFU device
Download [=========================] 100%
90640 bytes Download done.
dfu-util: unable to read DFU status
The problem is, that I am not sure if u-boot has been executed.
Reset (-R) should do that, but it tells me that it is 'unable to read dfu status'.
Am I missing something here?
Does anyone know what might be the problem here?
I already used dfu-util and this message has always been displayed but it doesn't affect the Reset. Once you execute
dfu-util -R -D u-boot-dfu.bin
you should get U-Boot console through serial port (ttyS0... or ttyUSB0 if you are using a Serial to USB dongle...) using minicom or a similar tool.
I ported U-Boot on the Hitex board in SPI Flash and using USB to get the console during a internship, so maybe I can help you further.
Thanks for helping.
It seems that the message "dfu-util: unable to read DFU status" is normal.
The problem was that my bootloader was not working because it was for a similar board with more internal SRAM. I just had to port my bootloader first, console is now working.
I am working with QEMU 1.1.0, emulating Versatile Express board with ARM Cortex-A9. I have managed to launch simple "Hello World" example following this instructions:
http://balau82.wordpress.com/2012/03/31/compile-linux-kernel-3-2-for-arm-and-emulate-with-qemu/
but now I want to create filesystem by myself.
I decided to use buildroot, version 2012.05. and I've configured it to create toolchain, kernel and filesystem image for ARM Cortex-A9 target.
Kernel is of version 3.3.7 and for the filesystem I've selected to be cpio, non-compressed. The initrd argument in call to qemu-system-arm is pointing to
/output/images/rootfs.cpio
When I launch QEMU kernel boots, but then I get this message:
Initializing random number generator... done.
Starting network...
can't open /dev/ttyS0: No such device or address
can't open /dev/ttyS0: No such device or address
can't open /dev/ttyS0: No such device or address
...
All I can do is to terminate QEMU.
I have checked the contents of rootfs.cpio like this:
cpio -t < rootfs.cpio
and saw that there is /dev/ttyS0.
Have I missed something in configuring the filesystem? Or should I use filesystem in
/output/target
to somehow create device(s) there (Buildroot does not do that), and then rebuild the filesystem?
I'm new to Buildroot, so any hint or suggestion is more than welcome.
Extract rootfs and type ls -all /dev/ttyS0 and check it's major and minor number. Because if your major number is not the required one then it will not invoke respective kernel functionality and in that case it will only be a junk character device.
Also can you post the whole log file (copy all those dmesg and post those somewhere and give link here.)
And if you are sure that /dev/ttyS0 is there then do the following steps :
extract(unpack using cpio) rootfs
find out which init file kernel is using as parent process. If you are lucky then it would be lying in root directory. named init or initrc
open init file in your favorite editor.
starting few lines of your init would be like
::respawn:/sbin/getty -L 38400 tty1
::respawn:/sbin/getty -L 38400 tty2
::respawn:/sbin/getty -L 38400 tty3
::respawn:/sbin/getty -L 38400 tty4
add ::respawn:/sbin/ls -all /dev and save the file. (We have added list command to see what is there inside /dev directory)
reboot your system and check the dmesg. See if /dev/ttyS0 is really missing ?