U-boot on my platform provides POST(Power on self test) for UART and DDR .Now for some requirement I need to port it to Linux.
I need to know, is it possible porting POST from u-boot to Linux , will it work?
Also, is there some other ways to do self post for UART and DDR at kernel level?
Thanks
Amit.
Related
I am working on the ATMEL ATtiny1616 micro-controller.
I am looking for a (Linux C/Phython based) serial bootloader application to program the ATtiny1616.
Will you please help me to know, Where I can get the source code for it?
I'm going to use pyupdi for these new tinies (ATtiny814 which has the same programming protocol).
For now, pyupdi
Can read/write fuses
Can write FLASH
Can not read/verify FLASH
Can not read/write EEPROM
UPDI is another way to program the ATtiny1616. But as I said, I would like to program the ATtiny1616 using the Serial Bootloader Application.
I have found a reference link on the site of the microchip. Serial Bootloader Application
& this application will work for me.
I have read this post How to emulate an i2c device on QEMU x86? about a solution for configuring an I2C device for QEMU emulating x86_64.
I am trying to do the same thing for ARM. Currently I have a simple I2C user space program that is timing out because although QEMU lists an I2C device in /dev it has no actual method of simulating the device and returning ACK. I was curious if someone could provide more detail on how I might implement the solution from that post because I am not very experienced in that area and the answer is pretty sparse in detail.
I am wondering how peripheral devices, other than USB, like ones using CAN and SPI are emulated when using QEMU.
Devices are supported on a device-by-device basis. QEMU emulation of Zynq 7000 can emulate certain EEPROM and flash devices and read and write to them over the I2C bus. Device support is listed here. Xilinx QEMU peripheral device support: http://www.wiki.xilinx.com/QEMU+-+Zynq-7000
I assume that support for other machine types is also on a by device basis, and hopefully it is as well documented as Xilinx's QEMU machines' peripheral support.
The wiki provided has other pages which provide examples of adding peripheral devices to the device tree. When you specify the device tree at QEMU invocation, QEMU will read the device tree and will begin emulating devices for which it has support.
So I was wondering: Since libusb provides userspace access to USB, is it possible to port already existing kernel drivers to libusb?
I do understand it might need rewriting of the driver, but do you think it is possible to write a "virtual kernel" that relies on libusb for access to devices and link already existing drivers to that? Essentially writing a layer between libusb and kernel modules that translates kernel USB commands to libusb commands.
Why bother? If you want to run a kernel driver on Android for example, you need to make sure it was compiled for a particular kernel version/device model. So an app will not be able to run on all devices. On the other hand libusb is fully compatible with most of the latest Android devcices.
AFAIK, libusb is a library that communicates with the higher level of the USB layer of the kernel. The lowest parts of the USB subsystem have to be written in kernel space, because they need to have access to the physical address space of the USB host controller and uses interrupts, and other low-level functions that are not possible to implement in user space.
So I don't think that it is possible to port low-level parts of the USB subsystem in user-space.
I have some basics knowledge on Linux (RHEL 5.4) Device Driver and Kernel internals and wish to gain expertise on same. I came to know of raspberry pi board.
My question is that the same code that I write on a Linux server will work there - is their architecture and concepts same. Kindly note that if it is not the same case then I need to buy a desktop PC otherwise for offline practicing purpose.
Note - I was unable to add raspberry pi group hence needed to remove the same and add the below ones.
Yes it depends on Architecture and the same code compiled on x86 will not wrok on Pi. However, there are ways to get around it.
As mentioned in the above post, use a cross compile toolchain(that comes with its own libc) to comile your code (kernel/userspace) to try it out on R pi. Again doing this, you will still not be able to test your code. To do that get a VM tool like qemu. I am not sure if there is a qemu port for R pi but in general a ARM 11 (ARMv6) based qemu should do. The following link should get you going with initial kernel development on your PC without owning a R pi.
http://xecdesign.com/qemu-emulating-raspberry-pi-the-easy-way/
Cheers
Subbu
Is their architecture and concepts same??
I would like to clarify that Rasperry Pi is ARM based board. Mostly I guess your server is running on X86.
Device drivers meant for devices. Rasperry Pi should have the device which you are writing driver for.
I suggest you to study the data sheet of rasperry pi and linux driver model.
Linux driver model is architexture independent only. so you need only some effort for porting your X86 driver to ARM. You need to concentrate on hardware part.
You might need to cross compile your code for ARM arch. if you are using x86 machine on your Linux Server.You can cross compile your modules for ARM using GNU ARM toolchain and then run on Raspberry pi.
I am working on ARM S3C6410 device now.
The problem is first 256KB of NAND was broken.
I am trying to boot with SD card, uboot works.
What I want to know is as following.
Can I boot kernel from SD card without NAND?
Can I run uboot from SD card, and then boot kernel from non-broken area of NAND?
I am a newbie. I hope guru's help.
yes, many boards use sd-card instead of nand, just modify the bootargs in u-boot. You probably don't even need to change the kernel, just make sure that uboot supports the SD-card for your platform as a boot device
yes. Again, it's only a problem of configuring bootargs correctly. Probably even simpler than point 1