I have a board from a no name manufacturer with a tpm 2.0 device LetsTrust but I am getting an error while trying to load the TPM.
The board has Ubuntu arm64 installed, the kernel version is 4.9.170.
I have added the following modules to be loaded on boot:
tpm_tis_spi
tpm_tis_core
tpm
but I still can't see the tpm on /dev, when I check the boot logs with dmesg I only see **fly error: tpm_tis_remove ** I am not sure what it means exactly but it seems the kernel couldn't recognize the TPM for some reason.
There is a way where I could get more information to understand why this is happening? we have no manual from the manufacturer so I can't ask them for help.
I have tried to compile a new kernel with TPM support to already load those drivers as modules but the OS disk is somehow embedded in the board and I couldn't find any bootloader to be able to tell it to boot from the new kernel.
Related
Helo All,
I am trying to learn embedded linux.
Please provide clarity on below:
As DTB provides Board and SOC related information will it be sufficient to make sure correct drivers will be enabled?
How a correct driver will get selected and will it happen during build time or kernel runtime based on the DTB?
How are drivers for platform devices(UART, SPI, I2C etc) handled in Linux? I mean as different SOC's have different implementations(register and bit fields will be different) of these peripherals how a single driver will be able to handle both SOC's?
Is it sufficient to have well defined DTB about board and kernel to make Linux up and running on any platform.
Thanks,
Suraj
I use and build a kernel 4.14 which is already running on a ARM processor.
Now I would include the MCP23S08 driver (pinctrl-mcp23s08.c)
For that, I use make menuconfig to enable the driver. Unfortunately, I could not find an entry for the Pin Control subsystem in which the driver should be.
For testing, I checked out the kernel 4.17 in which the entry Device Driver->Pin Controlls exist. According to the entry in LKDD I think something changed in the configuration method between kernel 4.14 and 4.15.
Does someone now, how to activate the Pin Control subsystem in kernel 4.14? Thank you for any hint!
Ok, I found a way to enable the Pin control subsystem:
At least in that kernel version (4.14) the pin control subsystem is a machine configuration. I activated it in the /arch/arm/mach-*/Kconfig file. After that, the entry was shown in the kernel menuconfig.
I built a new yocto image for a custom board. I flashed it to an SD card and tried booting it, but freezes while booting Kernel.
The image has SYSTEMD feature enabled. If I disable SYSTEMD, it boots fine. Do i need to configure anything ? like in fstab? I am stuck at this point for a long time, so please advice.
I was able to resolve this error. I enabled CONFIG_CGROUPS related features as mentioned in (link) in my machine's defconfig and the Kernel boots fine :)
I'm looking for either a kernel mode call that I can make from a driver, a userland utility, or a system call that will ask the Kernel to look at the PCI bus and either completely re-run its initialization, or initialize a specific device. Specifically, I need the Kernel to recognize a device that was added to the bus after boot and then configure its address space, interrupt, and other configuration parameters, and finally enable the device so that I can load the driver for it (unless this all happens as part of the driver load).
I'm stuck on the 2.4.x series Kernel for this, and am currently working with 2.4.20, but will be moving to 2.4.37 if it matters. The distro is a stripped down Red Hat 7.3 running in a ram disk, but I can add in whatever tools are needed to get this working (as long as they play nice with 2.4 series).
If some background would help clarify what I'm trying to do: From a cold boot, once in Linux I use GPIO to program an FPGA. Part of the FPGA, once programmed, implements a simple PCI device. Currently, after programming the FPGA, I reboot the system and Linux recognizes the device after coming up and loads the driver for it.
Instead of needing that reboot, I'd like to simply ask the Kernel to do whatever it does during boot up to find PCI devices (I have the Kernel configured to find PCI devices on its own, instead of asking the BIOS for that information, so the BIOS won't need to know about this device (I hope)).
I believe that Linux is capable of seeing the device after it is programmed but before a reboot, because scanpci will show the device after I program it, as will lspci -H 1. I just need a way to get it into /proc/pci, configured and enabled.
This below command will help the user to rescan it complete root hub.
echo "1" > /sys/class/pci_bus/0000\:00/rescan
You could speed up the reboot with kexec, if you don't figure out how to get the PCI scan redone. You could ask this on the LKML, if you haven't already.
unloading/reloading the module doesn't help, does it?
http://www.linuxjournal.com/article/5633 suggests you should be able to do it with 2.4 kernels using pcihpfs.
If that isn't working, maybe the driver doesn't support hotplug?
It would probably crash the system if you reconfigured the addresses of other PCI devices while they are in use.
A better way would be to just configure the new card. If your kernel has support for Cardus devices, it already knows how to configure a newly-inserted PCI device (which is what Cardbus is). You just need to figure out how to get the kernel to do it...
It should be possible for a kernel module to do this. Even if you can't get built-in hotplug code, you should be able to set the pci resources using calls to pci_bus_write_config_dword() and friends. There is probably some IRQ routing setup to do as well.
I have an ARM kit beside me and a Linux kernel source code patched with Xenomai on my machine. I understand I can send data to the kit through an USB cable and a (windows-based, of course) software, but I'm stumped as to exactly what I should be sending that would make the kit run Linux.
(clarifications from comments: It is an Atmel AT91SAM9260-EK kit. It uses SAM-BA and SAM-PROG for the loading and unloading of data through either a serial or USB cable.)
I'd start with the ATM91SAM9 Linux software package from Atmel and follow the instructions.
Linky:
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4335
Otherwise, you need to get GCC setup with an ARM back end on a Linux box, build a Linux binary and then figure out how to load it on the devt board.
You might want to check out some cross compiler like OpenEmbedded which will help you compile the kernel for the ARM architecture.
i would suggest jtag and openOCD, then you just use the JTAG to place your filesystem and kernal image in the flash memory, in a place wear our bootloader can find it. you might have to change your bootloader.
another option is you might start up your micro, then insert a bootloading program into the RAM of the program then change the program counter to point at it.
that bootloading program can init the UART/USB then you have a host side program that transers the files. this method is very complicated and generally only good if you don't want to spend 100$ on a jtag (hint, buy a jtag they are useful)