Boot issue with ti-linux-4.1.y + TFTP + NFS

181 views
Skip to first unread message

gnu gnu

unread,
Nov 24, 2015, 9:07:21 AM11/24/15
to BeagleBoard
I was using vanilla 4.1.0 kernel with minimal busybox as rootfs. I built the kernel with omap2plus_defconfig and was successfully able to boot.
Below is my setup:
1. UBOOT on EMMC: U-Boot 2013.10 (Nov 28 2013 - 06:36:11)
2. kernel image via TFTP
3. Rootfs over NFS
Below were command which worked fine:
   setenv bootargs root=/dev/nfs ip=192.168.0.100 console=ttyO0 nfsroot=192.168.0.1:/home/xxx/nfsroot
   tftp 0x81000000 uImage
   tftp 0x82000000 am335x-boneblack.dtb
   bootm 0x81000000 - 0x82000000

But since I want to have PM(s2ram) support, I was suggested to move to TI BSP.
I followed the guide by Robert here : https://eewiki.net/display/linuxonarm/BeagleBone+Black
Only exception was I did not switch my UBOOT, its remains U-Boot 2013.10.
After build was over I copied the zImage and am335x-boneblack.dtb to /var/lib/tftpboot as I was doing with Vanilla kernel case.
But I am not going beyond "Starting kernel ..." which is printed by UBOOT.
Am I missing something ? Can someone help me ....

Bootup Logs:

U-Boot SPL 2013.10 (Nov 28 2013 - 06:36:11)
reading args
spl
: error reading image args, err - -1
reading u
-boot.img
reading u
-boot.img




U
-Boot 2013.10 (Nov 28 2013 - 06:36:11)


I2C
:   ready
DRAM
:  512 MiB
WARNING
: Caches not enabled
MMC
:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Net:   cpsw, usb_ether
Hit any key to stop autoboot:  0
U
-Boot#
U
-Boot#
U
-Boot# tftp 0x82000000 zImage
link up on port
0, speed 100, full duplex
Using cpsw device
TFTP
from server 192.168.0.1; our IP address is 192.168.0.100
Filename 'zImage'.
Load address: 0x82000000
Loading: #################################################################
     
#################################################################
     
#################################################################
     
#################################################################
     
#################################################################
     
#################################################################
     
#################################################################
     
#################################################################
     
############################################
     
1.3 MiB/s
done
Bytes transferred = 8272712 (7e3b48 hex)
U
-Boot# tftp 0x88000000 am335x-boneblack.dtb
link up on port
0, speed 100, full duplex
Using cpsw device
TFTP
from server 192.168.0.1; our IP address is 192.168.0.100
Filename 'am335x-boneblack.dtb'.
Load address: 0x88000000
Loading: #####
     
1.2 MiB/s
done
Bytes transferred = 59295 (e79f hex)
U
-Boot# setenv bootargs root=/dev/nfs rw ip=192.168.0.100 console=ttyO0 nfsroot=192.168.0.1:/home/xxx/nfsroot
U
-Boot# bootz 0x82000000 - 0x88000000
Kernel image @ 0x82000000 [ 0x000000 - 0x7e3b48 ]
## Flattened Device Tree blob at 88000000
   
Booting using the fdt blob at 0x88000000
   
Using Device Tree in place at 88000000, end 8801179e


Starting kernel ...

It hangs at this point.


I tried changing console=ttyS0 also, that too did not help.

Regards
nagla

gnu gnu

unread,
Nov 25, 2015, 1:37:57 PM11/25/15
to BeagleBoard
okay... so I got it partially resolved. The board was booting earlier as well, but since console was not there, I thought its not booting at all.
Error was that I forgot to make change in /etc/inittab from ttyO0 to ttyS0. in addition to the bootargs

So now I am able to get serial console.

But I need to enable the bootup console logs. Can someone help how to do it ?

I tried comparing .config of TI BSP and that of omap2plus_defconfig generated by vanilla kernel.
Looks like TI BSP uses
CONFIG_SERIAL_8250_OMAP=y
CONFIG_SERIAL_8250_OMAP_TTYO_FIXUP=y

while omap2plus_defconfig uses:

CONFIG_SERIAL_OMAP=y
CONFIG_SERIAL_OMAP_CONSOLE=y

Cheers
nagla

Robert Nelson

unread,
Nov 25, 2015, 1:44:16 PM11/25/15
to Beagle Board
On Wed, Nov 25, 2015 at 12:37 PM, gnu gnu <nagla...@gmail.com> wrote:
> okay... so I got it partially resolved. The board was booting earlier as
> well, but since console was not there, I thought its not booting at all.
> Error was that I forgot to make change in /etc/inittab from ttyO0 to ttyS0.
> in addition to the bootargs
>
> So now I am able to get serial console.
>
> But I need to enable the bootup console logs. Can someone help how to do it
> ?

U-Boot# setenv bootargs root=/dev/nfs rw ip=192.168.0.100
console=ttyO0 nfsroot=192.168.0.1:/home/xxx/nfsroot

Well, if you want a serial boot log, you should add it:

U-Boot# setenv bootargs console=ttyO0,115200n8 root=/dev/nfs rw
ip=192.168.0.100 console=ttyO0 nfsroot=192.168.0.1:/home/xxx/nfsroot


>
> I tried comparing .config of TI BSP and that of omap2plus_defconfig
> generated by vanilla kernel.
> Looks like TI BSP uses
> CONFIG_SERIAL_8250_OMAP=y
> CONFIG_SERIAL_8250_OMAP_TTYO_FIXUP=y
>
> while omap2plus_defconfig uses:
>
> CONFIG_SERIAL_OMAP=y
> CONFIG_SERIAL_OMAP_CONSOLE=y

"CONFIG_SERIAL_OMAP" is on it's way out being replaced by
"CONFIG_SERIAL_8250_OMAP"..

Regards,

--
Robert Nelson
https://rcn-ee.com/

gnu gnu

unread,
Nov 25, 2015, 1:53:15 PM11/25/15
to BeagleBoard
Thanks Robert.

But I do not quite follow it. You mean I should switch back my bootargs to ttyO0 while /etc/inittab should be ttyS0 ?
While in omap2plus_defconfig case I had ttyO0 at both places(bootargs and inittab). Why this has to be this way ?

Regards
nagla

Robert Nelson

unread,
Nov 25, 2015, 2:00:52 PM11/25/15
to Beagle Board
On Wed, Nov 25, 2015 at 12:53 PM, gnu gnu <nagla...@gmail.com> wrote:
> Thanks Robert.
>
> But I do not quite follow it. You mean I should switch back my bootargs to
> ttyO0 while /etc/inittab should be ttyS0 ?
> While in omap2plus_defconfig case I had ttyO0 at both places(bootargs and
> inittab). Why this has to be this way ?

Ah crap, sorry:

U-Boot# setenv bootargs console=ttyS0,115200n8 root=/dev/nfs rw
ip=192.168.0.100 nfsroot=192.168.0.1:/home/xxx/nfsroot

( i had to deal with the 2.6.33: ttyS2 -> ttyO2 migration so my head
will never be sane again with omap serial drivers... )


CONFIG_SERIAL_8250_OMAP=y needs "ttyS0,115200n8"
CONFIG_SERIAL_8250_OMAP_TTYO_FIXUP=y replaces old u-boot/bootloaders
"ttyO0,115200n8" -> automatically to "ttyS0,115200n8"

CONFIG_SERIAL_OMAP=y needs "ttyO0,115200n8"
CONFIG_SERIAL_OMAP_CONSOLE=y (this just special for
CONFIG_SERIAL_OMAP=y as CONFIG_SERIAL_8250_xyz just assumes)

systemd will span a console based on /proc/cmdline

non-systemd/udev will need this rule:
https://github.com/rcn-ee/repos/blob/master/bb-customizations/suite/jessie/debian/60-omap-tty.rules

which will automatically create /dev/ttyOx based on /dev/ttySx for
compatibility:

gnu gnu

unread,
Nov 25, 2015, 2:34:59 PM11/25/15
to BeagleBoard
I guess I have already tried out this yesterday, with no bootup logs printed on console. Although at later stage after logging into buildroot, I can use dmesg.

Below was the bootargs, I tried:

setenv bootargs root=/dev/nfs rw ip=192.168.0.100 console=ttyS0 nfsroot=192.168.0.1:/home/xxx/nfsroot

I've triggered a build to recheck it.

BTW, I'm on a slow machine(almost biblical era... 1GB ram) and a single change starts 1 hr of module building. Which I do not use anyway :-(
Is there anyway I can avoid and just build the kernel. A small defconfig like omap2plus_defconfig.

Cheers
nagla

Robert Nelson

unread,
Nov 25, 2015, 2:40:41 PM11/25/15
to Beagle Board
On Wed, Nov 25, 2015 at 1:34 PM, gnu gnu <nagla...@gmail.com> wrote:
> I guess I have already tried out this yesterday, with no bootup logs printed
> on console. Although at later stage after logging into buildroot, I can use
> dmesg.
>
> Below was the bootargs, I tried:
>
> setenv bootargs root=/dev/nfs rw ip=192.168.0.100 console=ttyS0
> nfsroot=192.168.0.1:/home/xxx/nfsroot

add the baud rate: (don't remember what it's default is)
,115200n8

>
> I've triggered a build to recheck it.
>
> BTW, I'm on a slow machine(almost biblical era... 1GB ram) and a single
> change starts 1 hr of module building. Which I do not use anyway :-(
> Is there anyway I can avoid and just build the kernel. A small defconfig
> like omap2plus_defconfig.

gnu gnu

unread,
Nov 25, 2015, 3:34:13 PM11/25/15
to BeagleBoard
ohhh yes.... ,115200n8 did the trick.

I every time missed it because the older driver CONFIG_SERIAL_OMAP worked just with console=ttyO0.
Looks default baud is not 115200n8 in CONFIG_SERIAL_8250_OMAP. However, other TI driver CONFIG_SERIAL_OMAP seem to have default set to 115200n8.

Thanks for help.

Last question to complele this post:
In case of CONFIG_DEBUG_LL which config option should I use  out of below for BBB:
CONFIG_DEBUG_OMAP2UART1
DEBUG_AM33XXUART1
CONFIG_DEBUG_LL_UART_8250


Cheers
Nagla

Robert Nelson

unread,
Nov 25, 2015, 3:38:20 PM11/25/15
to Beagle Board
On Wed, Nov 25, 2015 at 2:34 PM, gnu gnu <nagla...@gmail.com> wrote:
> ohhh yes.... ,115200n8 did the trick.
>
> I every time missed it because the older driver CONFIG_SERIAL_OMAP worked
> just with console=ttyO0.
> Looks default baud is not 115200n8 in CONFIG_SERIAL_8250_OMAP. However,
> other TI driver CONFIG_SERIAL_OMAP seem to have default set to 115200n8.
>
> Thanks for help.
>
> Last question to complele this post:
> In case of CONFIG_DEBUG_LL which config option should I use out of below
> for BBB:
> CONFIG_DEBUG_OMAP2UART1
> DEBUG_AM33XXUART1
> CONFIG_DEBUG_LL_UART_8250

I usually leave it disabled..

https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/ti-linux-4.1.y/patches/defconfig#L6203

with the transition to multi-platform, it's more pain when you have 2+
target's (am335x/am43xx/am57xx)

gnu gnu

unread,
Nov 25, 2015, 4:52:41 PM11/25/15
to BeagleBoard
sorry, but I do not seem to understand your point here.

Do you mean I can not use earlyprintk and low level bootup messages on BBB?
Or since the kernel is multiplatform, so you can not possibly decide which platform it'll be used and enable that particular early console.

But as a user should not I have option ? I just want to know which uart port option I can use for BBB. Possibly : DEBUG_AM33XXUART1 ?

Regards
Nagla

Robert Nelson

unread,
Nov 25, 2015, 4:59:37 PM11/25/15
to Beagle Board
On Wed, Nov 25, 2015 at 3:52 PM, gnu gnu <nagla...@gmail.com> wrote:
> sorry, but I do not seem to understand your point here.
>
> Do you mean I can not use earlyprintk and low level bootup messages on BBB?
> Or since the kernel is multiplatform, so you can not possibly decide which
> platform it'll be used and enable that particular early console.
>
> But as a user should not I have option ? I just want to know which uart port
> option I can use for BBB. Possibly : DEBUG_AM33XXUART1 ?

Sure give that config a shot..

gnu gnu

unread,
Nov 27, 2015, 3:45:38 PM11/27/15
to BeagleBoard
yes it does ....
thanks for help.

regards
nagla

coli...@gmail.com

unread,
Dec 11, 2015, 6:03:10 AM12/11/15
to BeagleBoard
Hi Robert,

Can you elaborate on your statement:
"CONFIG_SERIAL_OMAP" is on it's way out being replaced by 
"CONFIG_SERIAL_8250_OMAP".. 

Is there active development to have the 8250 emulation support all the OAMP serial port features ?

I am trying to get RS485 to work with the serial cape, and the 8250_omap driver does not support the RS485 ioctl. The old omap-serial does.
Do you know if anyone is working on this ?

Thanks,

Colin..



djk...@vt.edu

unread,
Nov 7, 2016, 10:54:16 AM11/7/16
to BeagleBoard
Colin,

Did you get resolution to this? I've been trying for a couple of days to get an example python script to work. When it first runs I see the entire message transmitted while transmit enable is high. Subsequent attempts show transmit enable going low after the first byte is written.

Thanks,
Jay

Colin Whittaker

unread,
Nov 7, 2016, 1:43:29 PM11/7/16
to beagl...@googlegroups.com
Hi Jay,
The quick answer is no.
If I remember correctly, I hacked the device tree fragment to set the GPIOs correctly, but found that cape would not work for my application. Using RTS to set the transmit enable is very slow for turn around. I needed to receive right away.

My solution was to use a USB RS-485 that supports HW transmit enable and get rid of the serial cape.

Colin..


--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/IaFR3VueUrk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/d80fb1ea-e01f-4923-b75f-1fc5ac5bec2d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages