I am running xillinux on my microzed board. I need to define a new serial port on the board using vivado. I was able to add this to the IP core and the device is ready. But,how do I make this port visible on ubuntu (xillinux) like ttyPS0. DO I need to add this port to the device tree and generate the dtb file and boot.bin file ? IF so, how do I modify the device tree ?
1.) Now again, instead of vivado if I use ISE, then would I be able to update the device tree source file in the ISE software itself and generate the device tree .dtb file ? If so, where can I find and edit this dts file ?
2.) And for building the new boot.bin file in ISE, I can use http://xillybus.com/downloads/u-boot...ux-1.3.elf.zip for the microzed or can I use the bin file for microzed from xillybus.com/downloads/xillin...rozed-1.3c.zip ?
3.) Even after using the ISE and creating the new .dtb (if possible in ISE), do I have to edit dtc files on the xillinux OS in the micozed board ?
4.) If I need to follow step 3 above to get everything working, based on this link, http://xillybus.com/tutorials/device-tree-zynq-1
I can go only upto to cd /usr/src/kernels/3.12.0-xillinux-1.3/scripts/dtc/
If I type cd /dtc again, it says dtc not a directory.
How do I access the device tree script and add the address mapping to the bus in the peripheral section ?
How do I compile this and make the new device tree start on every boot ?
I can go only upto to cd
/usr/src/kernels/3.12.0-xillinux-1.3/scripts/dtc/
If I type cd /dtc again, it says dtc not a directory.
Sure, /usr/src/kernels/3.12.0-xillinux-1.3/scripts/dtc/dtc is a binary executable. It has been compiled with the Linux kernel. It is the Device Tree Compiler (thus its name) that turns a Device Tree Source foo.dts into a binary Device Tree Blob foo.dtb. The DTS is a text file describing the available hardware and how to access it. The DTB is the same information but in a binary format that the Linux kernel parses at boot time to discover the hardware it is running on and to attach software drivers to the hardware peripherals (among other things).
So, to use the dtc just add /usr/src/kernels/3.12.0-xillinux-1.3/scripts/dtc to your path and use it:
$ export PATH=$PATH:/usr/src/kernels/3.12.0-xillinux-1.3/scripts/dtc
$ dtc -I dts -O dtb -o foo.dtb foo.dts
Related
I want to run linux on qemu to test some system design, I use default config for x86_64, I found that I must append "console=ttyS0" to boot arguments so that I can get kernel message, without the ttyS0 I can't get any output.
So I want to check qemu's device tree, another strange thing is that I found there is no device-tree directory under /sys/fireware.
I want to check following question:
why we need "console=ttyS0" to get output ?
doesn't x86 use device-tree during booting ?
I'm getting started with imx6 processors and the procedure involved to bring up the board is to flash u-boot kernel dtb and rootfs which is taken care of by mfg tools provided by nxp.
For creating a rootfs partition the command run is
mkfs.ext3 -F -E nodiscard /dev/mmcblk1p2
and for untaring the rootfs into this partition it is.
pipe tar -jxv -C /mnt/mmcblk1p2
I'd like to know the working of this, which kernel driver is being called for executing these commands?
My kernel version is 4.9.88.
I did find a few driver files related to mmc in the path
/drivers/mmc/core
but there is nothing related to filesystem reading or writing here.
Can anyone explain which driver files are used to create filesystems?
Creating the filesystem is done by the userspace program mke2fs (of which mkfs.ext3 is an alias) which is part of the e2fsprogs package. The kernel and drivers have no way of creating filesystems. Therefore, only the block driver for accessing the MMC device is involved, but no file system driver.
My goal is to port this driver on current Linux Kernel.
Things which I did till now....
1) Downloaded the source code of the current kernel version.
2) Downloaded the dev_parallel.c, Makefile, Kconfig for reworking on the code.
3) Using "make" command I was able to compile the driver with no errors.
4) Using "make modules" command I was able to generate a .o file.
5) Using "make modules_install" command I was able to get the .ko file.
6) Using "modprobe" command I was able to successfully load the module without any kernel panics.
But I see that there is a DTS file for this driver located here. I know that dts files are compiled to dtb files which are read by the kernel during boot time and it automatically loads the module.
But is it necessary to have this DTS file or just modprobe command will do the job for me?
The driver which I am talking about is for an Electronic paper display (EPD).
So If I connect EPD and then do modprobe for loading the driver, will it work or do I need to have DTS file for making it work correctly?
It is not necessary to use DTS file in a driver but for some reasons like defining pins, setting configurations, etc. It should get parameters from DTS file to prevent user to modify the driver and recompile it.
It seems that your example doesn't get any parameters from the DTS file but on the other side, it hardcoded some pin definitions so you need to take care of them.
If you want to force it to read parameters from DTS file you should rewrite the driver. You can use this for driver and this for GPIO. Then you must include the new driver in your current DTS file and recompile it.
For the driver compilation, you can create a kernel module. You can use this tutorial for the basics.
I am using Ubuntu 18.04, woeUsb, 15 GB usb3 Stick, windows 10 64Bit ISO to create bootable device. I found few tutorials how to do it, but I still get error.
Installation failed!
Exit code: 256
Log:
WoeUSB v##WOEUSB_VERSION##
============================== Mounting source filesystem... Wiping all existing partition table and filesystem signatures in /dev/sda...
wipefs: error: /dev/sda: probing initialization failed: No medium
found The command "wipefs --all "${target_device}"" failed with exit
status "1", program is prematurely aborted Unmounting and removing
"/media/woeusb_source_1532252869_8362"... You may now safely detach
the target device
I tried to format my USB several times but nothing worked. I used FAT32 format. Should I first convert it to NTFS?
I have the same issue and found the solution by unmounting USB drive in this way,
Go to the Disks and select your USB drive from the left side menu, and click on the icon shown in the below image to unmount USB.
The command line version of the tool works better in my experience:
woeusb --device Win10_1909_English_x64.iso /dev/sdX --target-filesystem NTFS
/dev/sdX might be different on your system such as sda sdb ..., make sure to check the device path using gparted or fdisk.
Make sure to set the filesystem to NTFS with --target-filesystem NTFS as FAT32 doesn't support large files.
I found that you have to run the software with sudo because it requires the use of gparted. If you don't do this it won't succeed and exit. I suspect this is your problem. I had a similar problem.
I had the same problem but after surfing internet I found something like this: **
sudo woeusb --device image.iso /dev/sdb --tgt-fs NTFS --verbose
**. So in the command image.iso is the OS you downloaded(or the path to it), while the /dev... is the USB device and type of format(NTFS). Just copy the command, change image.iso to the path of your image.iso and change the /dev/sdb to the name of your USB device and make sure you are connected to internet because when I ran the command it seems it communicated with GitHub. Good luck I hope this will help if you haven't found any answer.
There is no need to use any third party tool in the Windows operating system to create a bootable USB. Follow the below commands:
1. Plug your USB drive
2. Open Command Prompt
3. Type: diskpart .
4. Type list volume (this will show your drives)
5. Type sel vol h (h can be replaced with ur usb volume, can be anything g, h, i)
6. Type active
7. It will make your USB active, copy and paste windows files inside it.
I am following the below link to make a bootable sdcard for beaglebone black. The only change is I am trying to build a 3.14 version of the kernel instead of the 4.4 version.
When I push the boot button before powering on the BBB, I get "CCCCCCCCC..." output on the serial terminal suggesting something wrong with the bootloader on the sdcard. Without pushing the boot button, the uboot on the BBB eMMC gets invoked and then it successfully boots the kernel off of the sdcard.
What changes, if any, do I need to make to the uEnv.txt to make this work ?
https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-LinuxKernel
If you see 'C' characters on the terminal (while the button was pressed on power up) it means that the CPU ROM code didn't found valid loader (MLO) on microSD. ROM code searches for loader over several addresses (0x0, 0x20000, 0x40000 and 0x60000), you can read about it here. Try to write MLO copies at addresses 0x0 and 0x40000:
sudo dd if=./u-boot/MLO of=${DISK} count=1 bs=128k
sudo dd if=./u-boot/MLO of=${DISK} count=1 seek=2 bs=128k
Check if your MLO is less than 128Kbytes.
You can also format microSD card as FAT and put MLO and u-boot.img there, it also works.