0

I am using Buildroot to build an initramfs image for my IMX Board. On the board, I run a custom Linux 4.19.35 Linux kernel (4.19.35-gexxxxxx) and a custom U-Boot bootloader. Hence, do not require these from Buildroot. My use case is only the rootfs.cpio (initramfs) image that gets built.

I am able to load the above initramfs into memory and execute my custom init and post-init scripts. However, I am unable to spawn an interactive shell. On reaching the command /bin/sh in the init script, I am greeted with a shell prompt but it seems that the serial console is not registering any keyboard inputs. Note that all other shell utilities and commands are executed just fine, but only when they are run in a script. Since one of my objectives is to have a minimal image, I am using busybox (1.32.0).

This gets even more confusing when I run the same initramfs along with the kernel image that is generated by buildroot. In this case, I do get an interactive shell prompt and I am able to enter my input like in a regular terminal.

I am suspecting that this might happen because of the different kernels. The buildroot kernel image is 4.19.35 but the kernel I use is 4.19.35-gexxxxx. However, I am not sure how the initramfs might be dependent on the kernel version string.

Any directions on what might be going wrong would be very helpful.

Edit 1: Below is my init code:

#!/bin/sh
/bin/mount -t devtmpfs devtmpfs /dev

export PATH=/sbin:/usr/sbin:/bin:/usr/bin

[ -d /dev ] || mkdir -m 0755 /dev
[ -d /root ] || mkdir -m 0700 /root
[ -d /sys ] || mkdir /sys
[ -d /proc ] || mkdir /proc
[ -d /tmp ] || mkdir /tmp
[ -d /run ] || mkdir /run

mkdir -p /dev/pts
mkdir -p /var/lock
/bin/mount -t sysfs -o nodev,noexec,nosuid sysfs /sys
/bin/mount -t proc -o nodev,noexec,nosuid proc /proc

/bin/mknod -m 666 /dev/ttyS0 c 4 64
/bin/mknod -m 666 /dev/ttyS0 c 4 64
/bin/mknod -m 622 /dev/console c 5 1
/bin/mknod -m 666 /dev/null  c 1 3
/bin/mknod -m 666 /dev/tty c 5 0
/bin/mknod -m 666 /dev/zero c 1 5
/bin/mknod -m 666 /dev/ttymxc3 c 5 1

/bin/sh # --------------------> Spawning a shell
Harsh
  • 7
  • 4
  • 1
    Your post is missing numerous salient details. Your *"IMX board"* has an ARM processor, so there's one or more Device Tree blobs involved but not mentioned. No mention of the boot logs. Have you scrutinized and compared the boot logs, especially in regards to the serial console driver? – sawdust Oct 07 '20 at 04:19
  • Yes, I should have mentioned, I am using a non-buildroot generated DTB, which seems to work well with both the kernels. I did go through the Bootlogs for both kernels. There were no differences in the console initialization. In both cases, the ttymxc3 console gets enabled (which is specified via U-Boot kernel args). – Harsh Oct 07 '20 at 06:29
  • Other than loadable modules, I think there is no dependency *"on the kernel version string"*. You neglect to mention the toolchain(s) and libc involved, what is different between these kernels, what init code does seem to work (e.g. is networking up?, can you telnet in?), is receive on the serial console really the sole issue, what level of system functionality do you end-up with??? – sawdust Oct 07 '20 at 08:59
  • I have configured Buildroot to use the exact same toolchains: GCC Linaro 6.3.1-2017.05-x86_64_aarch-linux-gnu. The Glibc version is also the same 6.x. I have included my init code in the description as well. This init works, i.e. I get an interactive shell with the Buildroot generated kernel. When run with my custom kernel, I get a non-interactive shell prompt. I have tried Getty (with ttymxc3, ttyS0) and a couple of other shells as well, but no success. In case on non-interactive shell, I am forced to physically reboot the device. However, every other command in init works as expected. – Harsh Oct 07 '20 at 09:09
  • 1
    you are creating the dev directory after mounting it, that is confusing ... since code runs from top to bottom – Got To Figure Aug 01 '22 at 11:17

1 Answers1

0

Try using a 5v serial adapter instead of 3.3v - with the lower voltage, you can still see what it's sending, but your adapter doesn't get heard by the device.