How I can get /proc/cpu/alignment to be arrived?
I need to check application for misaligned memory access.
According to https://www.kernel.org/doc/Documentation/arm/mem_alignment I need to set 3 into /proc/cpu/alignment but this file exists nat at all my os (only armv7 raspberry kernel has this file, armv8 and x64 kernels does not)
alignment trap is not available on any arm64 kernel
https://github.com/raspberrypi/linux/issues/2283
Related
So I've been gifted 2x gen 1 Galileos that I want to try to do something with before I throw them in the garbage.
It's my understanding that they wont run most i386 kernels from most distros as they need to be Pentium II compile flags.
So this guy shared his kernel configs https://twitter.com/kerneldave/status/1359178557570732032 and I have compiled the kernels using a standard GCC stack on ubuntu.
I cannot get the resulting kernel to boot. After Grub loads the kernel there is no activity on the console (via the serial cable)
Will mainline kernels work on Gen 1?
Does it need to be compiled with some special toolchain or will gcc be fine?
Any special boot params need to be used, APIC/ACPI, console options?
Thanks
This is an OSX linker question. I don't think OSX (BSD or Mach layers) cares how large the zero page is or indeed whether it even exists. I think this is a tools thing. But that's my opinion and that's why I'm asking.
-pagezero_size size: By default the linker creates an unreadable segment starting at address zero named __PAGEZERO. Its existence will cause a bus error if a NULL pointer is dereferenced.
This is clear; it's for trapping NULL ptrs. On a 32b OSX system, the size of the segment is 4KB which is the system pagesize. But on current 64b system, the size of this segment increases to 4GB. Why doesn't it remain at the system pagesize 4KB or the architecture's maximum pagesize, 2MB? This means I can't use 32b absolute addressing at all.
Are there any problems with using this flag and overriding the default? Apple Store rules, ...?
(This feature is specific to the OSX ld64 linker. The feature dates at least to ld64-47.2 March 2006. Address Space Layout Randomization and 64b support start with Leopard in October 2007.)
The -pagezero_size option is a linker option, not a compiler option. So, when you use the compiler to drive linking, you need to pass it as -Wl,-pagezero_size,0x1000 (or whatever size you want). This works fine. The Wine project, to which I'm a contributor, relies on this for compatibility of its 64-bit build.
My understanding as to why the default page-zero size is 4GB for 64-bit is to catch cases where a pointer was inadvertently stored in a 32-bit variable and thus truncated. When it's eventually cast back to a pointer, it will be in the low 4GB and therefore invalid. Any attempt to dereference it will cause an access violation.
Update:
It seems that -pagezero_size is recognized as a compiler option, too, and works just fine in my testing. Either way, I get a functioning executable and otool shows a __PAGEZERO segment of the desired size.
What versions of the tools are you using? I'm using Xcode 8 on Sierra (10.12.6):
$ cc --version
Apple LLVM version 8.1.0 (clang-802.0.41)
...
I compiled 32-bit kernel on a 64-bit ubuntu and installed it. But when I tried to boot from it , it gave me an error:
Failed to execute /init
Kernel panic - not syncing: No init found
And also the Caps Lock light kept on blinking.
But when I tried to boot from the original 64-bit kernel it booted successfully. Please tell me reason behind this and a solution to this.
You can't do much with just a kernel. As soon as the kernel is done booting, it calls an external process (called init) which begins starting other services and processes from user space, in order to arrive at a functional system. This includes mounting filesystems, configuring some hot-pluggable devices, launching network services, and, of course, providing a login screen.
A 64-bit operating system can run both 64-bit and 32-bit binaries. A 32-bit operating system can only run 32-bit binaries. And it appears that your system (including init) is a 64-bit system. Therefore, your 32-bit kernel will be unable to do anything after booting, since all the necessary system utilities are compiled in 64-bit mode.
I can't think of any reason one would want to "downgrade" to a 32-bit kernel on a 64-bit distribution, even if it were possible.
We have built a simple instruction set simulator for the sparc v8 processor. The model consists of a v8 processor, a main memory and a character input and a character output device. Currently I am able to run simple user-level programs on this simulator which are built using a cross compiler and placed in the modeled main memory directly.
I am trying to get a linux kernel to run on this simulator by building a simplest bootloader. (I'm considering uClinux which is made for mmu-less systems). The uncompressed kernel and the filesystem are both assumed to be present in the main memory itself, and all that my bootloader has to do is pass the relevant information to the kernel and make a jump to the start of the kernel code. I have no experience in OS development or porting linux.
I have the following questions :
What is this bare minimum information that a bootloader has to supply to the kernel ?
How to pass this information?
How to point the kernel to use my custom input/output devices?
There is some documentation available for porting linux to ARM boards, and from this documentation, it seems that the bootloader passes information about the size of RAM etc
via a data structure called ATAGS. How is it done in the case of a Sparc processor? I could not find much documentation for Sparc on the internet. There exists a linux bootloader for the Leon3 implementation of Sparc v8, but I could not find the specific information I was looking for in its code.
I will be grateful for any links that explain the bare minimum information to be passed to a kernel and how to pass it.
Thanks,
-neha
I am having issues in loading my root fs and after inspecting the Kernel Log it says some thing like
"INITRD: 0x1f8ca000+0x0028ac63 is not a memory region - disabling initrd"
What does this mean?
Background
I am running linux on one core of an ARM Cortex A9 and trying to run another baremetal application on another core. I have changed the device tree to reflect this and i am reserving part of the SDRAM for Linux and part for the bare-metal application. I am using Uboot. Is this something to do with the uboot?
Cheers,
S
As you are NOT dedicating the entire RAM to the Linux kernel on the main core, you will need to ensure that the intrd load address specified in the bootargs is accesible from the main core.
Next, this info is usually passed to the Linux kernel in bootargs passed from u-boot as
initrd=<initrd-start-addr>,<initrd-size>
Modify it according to your custom memory-map
Finally in u-boot, load the initrd at the new proper address you just specified and boot the Linux kernel.