I have a u-boot which copies a multiimage (Linux kernel+rootfs+dts) from a serial FLASH to the DDR. The device is remotely powered. The device requires fail safe remote firmware upgrade which survives power failure. I always keep two images on the FLASH. While I write a new firmware to the FLASH there is always another, older, firmware image on the FLASH. U-boot after power up shall boot the most recent firmware.
Boot time is important, but not critical. For example, I thought to let u-boot to boot the first "valid" image. A Linux application would decide if a reboot is required and modify u-boot environment.
I can patch u-boot - add a command which finds the most recent firmware on the FLASH. I would expect that somebody somewhere already solved this problem and likely better than me. Is there a patch/script for u-boot which allows to automatically choose the latest firmware based on some metadata?
Any other approaches to the problem?
Yes.
Use Uboot's bootcount feature.
It increments every boot retry. and is supposed to be cleared by an application on the filesystem after the kernel was booted.
If it reached a a threshold. you can then boot another image from uboot.
Related
I have an external serial peripheral that needs to be setup on Linux boot, on an embedded system.
What I need is sending a short configuration string as early as possible during system boot, so my procedure is simply
Set port to 115200 bps
Send a string, like "ABCDE\r\n"
I see that recent kernels support an early-on serial console, but what I need is not a console (my peripheral can also send meaningless data in that phase, plus I'll be showing a splash screen in graphic mode), just a fast initialization for the the peripheral.
How can it be done?
The answer to this will be subjective depending on what you mean by as early as possible. I will provide few possibilities I am aware of which might help you
In case your embedded platform uses any form of bootloader (ex: U-Boot) then you can do the serial(UART) initialization as part of the bootloader (Usually this will be done for the target platform alone so that we can see how far the boot is happening). You can try initializing your external serial peripheral in bootloader itself. As bootloader will execute before the linux kernel gets loaded you can achieve this easily.
If your platform doesn't use any form of bootloader then the possibility of initializing the external serial peripheral is via kernel driver (or) system init process.
I have been using PSplash program which uses the basic frame buffer driver for the boot progress. If interested check the following repo
PSplash
I want to make a bootable emergency USB-stick that automatically repartitions my system and unpacks a rootfs to the hard disk, installs the bootloader, etc.
I compiled my own kernel and created my own initrd with various scripts.
this works very well. only booting from an USB-stick causes problems when secureboot is active.
to work around the problem I took an official Ubuntu livecd and copied all the content like isolinux/ EFI/* and so on, I changed all grub-configuration-boot-entrys to my kernel and my initrd. So I think the bootloader should be secureboot capable.
i set the following parameters in grub.cfg and built a new iso:
set check_signatures=no
if secureboot is disabled, the system boots correctly.
if secureboot is active, the bootloader can be loaded. so the secureboot is done? but then the process aborts with the following error:
invalid signature: /boot/bzImage
although set check_signatures=no is set.
Does anyone have an idea?
Is there no other way than to sign my kernel and distribute the keys across all systems? - can I distribute the key via ssh without direct access to the hardware?
problem solved with signed-shim bootloader, free to download
I am compiling my own Linux kernel and userland tools for a PXE environment meant for cloning and reimaging. Right now, I'm sticking to a specific kernel version and using preconfigured .config's for building the Linux kernel.
I need to change from using preconfigured .config's to automatically generating the default configuration for the specified architecture, and then enabling all ethernet, ATA, SATA, and SCSI drivers.
The reason I want to do this is:
Updating the kernel means updating the preconfigured .config's, which takes too much time to manually do. The way I'm doing it now is using menuconfig, enabling the options I need, and saving the resulting .config to my repository.
I know the kernel I'm building is missing some drivers because I've encountered some PC's that were not able to mount the NFS share because Linux could not find an ethernet device (which I've verified by booting an Ubuntu CD, which did find the ethernet device). I want an automated way of building any Linux kernel version that will guarantee that ALL drivers I need are pulled in.
Using a distribution's configuration pulls in too many unnecessary drivers and features for my purposes. It lengthens the kernel build time from 10-15 mintues to an hour or more, and the resulting image is too big.
Does anyone know how to write a Bash script to accomplish this?
Have you considered using a text editor to modify the .config file.
Then you can modify it using search and replace.
Plus, there are other choices for configuring the kernel than the menu-driven "menuconfig".
This might seem like a stupid question but...
After using a USB to install Ubuntu, is it possible to use it as a regular USB again or is it like a CD install and the USB is now only good for installing Ubuntu?
Thanks.
Yes you can.
Infact you can keep the Ubuntu setup as it is and use the remaining free space to store other things, just incase you need Ubuntu installation in future.
You can use it normally, just be sure you have cleaned up the MBR for the case you leave the device plugged in at restart (when USB boot is still enabled).
Easiest is to format the whole partition (or use a partition manager to clean up the whole device). GParted should be able to do this for you.
Some (sketchy!) technical background:
The USB device is a flash device, where bits are stored non-volatile, but eraseable and changeable. Bits at a normal CD-ROM will really be "burned" in as the reflection capacity will be permanently changed when creating a CD. When booting up your computer, there is small memory ROM that contains a bootloader, that is looking up for devices containing a MBR at the first 512 bytes, that will be executed and load the OS (or in your case the first steps of the Ubuntu installation process).
So if you want to use the USB device as normal data storage again, you should also clear up these first 512 Bytes, as the bootloader from the USB could be loaded otherwise when leaving the device plugged in at reboot. Then the bootloader could throw an exception, as it would normally expect the Ubuntu installation files to be present onto this device.
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.