Rockpro64 nfs root, no shell and devtmpfs question [solved]

tenspd1370 · Tux's lil' helper Joined: 14 Dec 2017 Posts: 120

Hi all.

I am having some problems getting a shell prompt. The serial output shows that the rootfs is mounted and that devtmpfs is mounted. But when I pass init=/bin/sh, no prompt comes up. I am using busybox, so my inderstanding is that a busybox shell should come up.

The suspicious stuff I see is:
1. No device nodes appearing in the rootfs /dev directory on the nfs server
2. After the serial messages say it is running /bin/sh, nothing happens, then it appears to print messages saying it is looking for the nfs server again. It eventually finds it, but nothing happens

My console parameter is console=ttyS2,1500000 (strange baud rate) but it works for the early console parameter.

I have verified that nfs works on the server and with this board using the ubuntu distribution that you can obtain from this board's website.

I can get more info tonight, any other debugging suggestions are, as always, appreciated.

NeddySeagoon · Posted: Tue Dec 11, 2018 4:50 pm Post subject:

tenspd1370,

A couple of things,

tenspd1370 · Tux's lil' helper Joined: 14 Dec 2017 Posts: 120

Neddy -

Thanks for confirming the /dev part for me. I didn't think to check where the /bin/sh link was to - I thought because I had busy box installed, that was already done. Turns out it actually points to bash, so I will fix that when I get a chance. I will also look into the baud rate - so far everywhere I have seen it published, it is something along the lines of:

UART is accessible on pin 6 (GND),8 (TX) and 10 (RX) and with unusual speed: 1500000

which is what I am using. Of course I am probably missing something, I am just comparing to my own experience with a reference distro where I am hooked up to these pins and I can get a log in prompt. I do agree though - I kinda went "huh?" when I saw that as well.

I am also going to review the AMD64 handbook as well. I imagine the process is basically the same except that I am cross compiling everything and I will have to make some adjustments for how I do things like add to openrc, etc. I want to make sure there isn't something general that I missed.

One thing I did try was to grab the experimental arm64 stage 3, but when I plopped that into the build root (/usr/aarch64-unknown-linux-gnu), it broke aarch64-unknown-linux-gnu-emerge, so I am guessing that isn't the right thing to do. I did think about trying to somehow leverage catalyst, but from what I can tell, it doesn't work well with cross compilation. So I figured I would try to take step back and just get a busybox prompt for starters.

Thanks for putting up with my naivety with all this. I am trying to put the pieces together by observing how system builds that already work work (Armbian, ayufan, etc), slightly outdated but useful info from the Linux Embedded Primer book, and what I can find on the web. I am fairly proficient on the desktop, but embedded is a whole new ballgame.

Much appreciation....

tenspd1370 · Tux's lil' helper Joined: 14 Dec 2017 Posts: 120

So - I don't see anywhere to do anything with the baud rate. I removed the console=ttyS2,1500000 and just left in the early console parameter. I basically see the same thing happening.

NeddySeagoon · Posted: Wed Dec 12, 2018 6:51 pm Post subject:

tenspd1370,

You can use the stage3 in /usr/aarch64-unknown-linux-gnu but you will need to preserve the make.conf from crossdev as you want the cross compile make.conf, not a native one.
You will also need to restore the profile symlink as I recall that its a relative path in the native stage3. Worfh a check anyway.

With a little inginuity you can chroot into /usr/aarch64-unknown-linux-gnu on your build host too :)

tenspd1370 · Tux's lil' helper Joined: 14 Dec 2017 Posts: 120

Neddy -

chroot - That is a great idea! Just last night I think I accidentally mangled something in my host /etc instead of /usr/aarch64-unknown-linux-gnu/etc - long story short, I grabbed a rescue USB today and need to fix it tonight.

I think you are right - I need to figure out what is going on with ttyS2. My theory I would like to test is that it is still going, the console is messed up. I can ping the board when it is in the state above (at least that is what I recall from last night) and I wonder if I get the base set up and sshd started I could ssh into it to see if it does anything. My understanding of the nfsroot is that if you supply the information, the kernel knows to take <ip>.:/export/sysroot and make it /.

Thanks for the links. At work now, but can't wait to go over them. I'll keep coming back with updates when I get something new.

Much appreciated!

tenspd1370 · Tux's lil' helper Joined: 14 Dec 2017 Posts: 120

Neddy,

Sorry it has taken me a few days, but I tried out a patched mainline 4.20-rc6 vs the mainline from kernel.org via git-sources. The current rockpro64 support at kernel.org must still be a little behind. With the patched version (https://github.com/ayufan-rock64/linux-mainline-kernel.git) I can get a busybox shell up and running without any difficulty. I think the next step is to look at the difference between the patched version and kernel.org version. That will tell me what is missing. Or I could just use the patched version (depends on how I feel).

Either way, thanks for your help and the resource links you provided. I really appreciate it.