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
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 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 ?
I am making a module to do some basic stuff in my pen drive following the example here . its stating that the usb storage(in my case pen drive) device uses usb-storage driver . I saw in hardware info that its usb_storage(which is same as usb-storage as when i do rmmod usb -storage it states that ERROR: Module usb_storage does not exist in /proc/modules) . I have done even lsmod with and without device its not showing any module name usb-storage.
My doubt is simple how to know which module controles which device and i know it could be unloaded by rmmod (module name).
Assuming that your kernel actually has usb-storage support this means the module is built in to the kernel and cannot be removed.
Try rebuilding your kernel after changing the usb-storage support to be built as a module, rather than directly into the kernel.
There should be no problem removing the module if you are the Super user. Otherwise, change to super user then try to remove it. It can be done by sudo su command.
And for the list of modules being used, you can view the device log by dmesg and check out.