I have created a custom kernel 4.1.5(latest) on the **odroid xu3** device as mentioned in Arm DS5 streamline configuration, Odroid has kernel 3.1.82-35 already,
after make menu config
during make
it gives a firmware error, i.e:-
make[1]: No rule to make target firmware/edid/1024x768.bin', needed byfirmware/edid/1024x768.bin.gen.o'. Stop.
make: [firmware] Error 2"
Can anyone tell me what should i do, I am new to this.
The firmware is missing. You should check whether this firmware is needed or not. If it is necessary, download it and place it in the proper place. Otherwise, you can delete the rules in the Makefile.
Related
I am trying to build a yocto demo-coreip-cli image for my custom risc-v SOC which only supports imafd instructions.
For the compilation of cross toolchain that is used by Bitbake, I tried changing cross-binutils.inc recipe and cross-gcc.inc recipe in openembedded-core layer by including “–with-arch=rv64imafd” in "EXTRA_OECONF " variable.
Is there anything else I am missing or doing wrong?
Thank You.
I was able to successfully port the image to RV64-imafd.
You can follow this link for the steps I followed.
Atlast I compiled all the changes into a separate layer and .bbappend files.
Let me know if I can help any further.
My knowledge on Linux is very poor, so don't go too hard on me, please.
I tried to create a bootable CD-ROM(ISO image) from memtest86's source code.
I followed the instruction in user manual, type "make iso", but I got the error message below:
=====================================
make[1]: Leaving directory `/home/chris/src'
./makeiso.sh
make: ./makeiso.sh: Command not found
make: *** [iso] Error 127
=====================================
I have searched error 127, and I found this Make, error 127
I think my path is correct, so is binary a problem?
My system is 64 bits.
The source code can be downloaded here link
Is there a particular reason you want to compile it yourself? You may save some hassle by downloading the prebuilt .iso files. Aside from that, there's a lot of confusion going on here to the point that I'm not sure what's going on. There's memtest86 and memtest86+, which are two different products with a common origin. Some of the references I found to memtest86 are actually for memtest86+, which makes this all the more murky. There's also a memtest86++, which doesn't do much to make my head stop spinning.
Memtest86 has a downloadable .iso image available which includes the source code, and at a quick glance it appears to be the source code you also have so I think this is the one you've got. The Makefile references makeiso.sh, but it isn't included in the source at all. I have no explanation for why this would be or how to resolve it. You might try copying the file from one of the other forked projects, but I couldn't guess whether that will actually work or if there are other files that might be missing as well. I'd suggest you contact their support for help.
Memtest86+ appears to have a much more complete source code repository; for example the makeiso.sh file is included here. If memtest86 isn't working for you, you may wish to consider memtest86+ (I have no idea of the differences between the two or merits of each; I'm just proposing an alternative since the first isn't compiling for you).
In summary, I think your best options are (1) contact support for help, (2) use the prebuilt .iso file instead of compiling yourself, or (3) try an alternative program.
Hey is there anybody who works with SDCC to make projects for 8051 microcontroller series on Macbook. If yes then can you please post the working make file, specially the part which loads the program in the device. I am confused what to write specifically with the program tag in the Makefile.
It is not necessarily the case that a makefile include loading the code to the part, so just any old example will not help. Makefiles are very simple in essence; you have a target, and its dependencies - if the target does not exist, or any dependency is newer than the target, the target is rebuilt by executing the commands.
In your case you need a phony target (one that never exists), that is dependent on the binary image or hex-file (or whatever format you load file is), the the command to execute would be to launch whatever flash-programming or bootloader tool your toolchain uses to load the image:
.PHONY loadimage
loadimage : myprogram.hex
loader.exe myprogram.hex
I'm attempting to setup the avr toolchain while still utilizing the upstream binutils and gcc recipes. For example, the base recipe for binutils is in yocto/poky/meta/recipes-devtools/binutils/. I have my custom avr-flavored recipe in yocto/meta-avr/recipes-devtools/avr-binutils/.
Inside the custom avr recipe are a few environment variable changes (TARGET_PREFIX, TARGET_SYS, etc), and then a "require recipes-devtools/binutils/binutils-cross_2.23.2.bb". This lets me depend on the upstream binutils recipe without having to replicate everything manually.
Now, the problem I'm having is that the upstream recipe has a bunch of patches that get applied. I can't figure out how to have my custom recipe point to a filepath outside its layer so I can use the patches that already exist. I've tried using FILESEXTRAPATHS_prepend with no luck.
I think you're looking for a .bbappend file, which will inherit the existing recipe and allow you to override some parts of it.
I'm new in writing Linux device driver, and I'm wondering how the kernel Makefile magically knows what to compile. To illustrate what I don't understand, consider the following case:
I did a #include <linux/irq.h> in my driver code and I'm able to find the header file irq.h in the kernel directory KDIR/include/linux. However, this is only the header file, so I thought the irq.c source code must be out there somewhere. Hence, I looked into the KDIR/arch/arm searching for irq.c (since I'm using the ARM architecture). My confusion begins here when I found really many irq.c inside KDIR/arch/arm. To simply list a few, I got:
KDIR/arch/arm/mach-at91/irq.c
KDIR/arch/arm/mach-davinci/irq.c
KDIR/arch/arm/mach-omap1/irq.c
KDIR/arch/arm/mach-orion5x/irq.c
many more...
In my Makefile, I have a line like this:
$(MAKE) -C $(KDIR) M=$(PWD) CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm modules
So I understand that the kernel Makefile knows that I'm using the ARM architecture, but under KDIR/arch/arm/, there are so many irq.c with the same name. I'm guessing that the mach-davinci/irq.c is compiled since davinci is the cpu name I'm using. But then, how can the kernel Makefile knows this is the one to compile? Or if I would like to have a look for the irq.c that I'm actually using, which one should I refer to?
I believe there must be a way to know this besides reading the long kernel Makefile. Thanks for any help!
Beyond the ARCH variable, you can also choose the system type (mach) from the configuration menu (there is actually a sub-menu called "System type" when you type make menuconfig for instance). This selection will include and compile all files under linux2.6/arch/$ARCH/mach-$MACH, and in your case this is how only one irq.c gets compiled.
That aside, it is interesting to understand how the kernel chooses which files to compile. The mechanism behind this is called Kconfig, and it is what allows you to precisely configure your kernel using make menuconfig and others, to compile a module from the outside like you are doing, and to select the right files to compile from simple Makefiles. While it is simple to use, its internals are rather complex - but this article, although rather old, explains it rather well:
http://www.linuxjournal.com/article/6568
To make a very long story short, there's a target make config, which you can trace. That one generates .config, that is your main guideline to making dependencies and controlling what will be compiled, what not, what as module and what will be compiled into the kernel.
This guide should give you a basic understanding of building a kernel module (and I assume that's where you want to start with your driver).