BBB Clone change UART0 to UART4

[Dave]

The BBB Clone board I am trying to get working has had sufficient work that it is now trying to load Linux. 

I have u-boot patched to use UART4 as the console.  I have tried to make changes to pass UART4 to linux as the console, without success. 

I still get 

debug: [console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0] ...

from uboot on UART4 just before starting the kernel when I lose output 

Where is the console getting set to ttyO0 ? 

[Yiling Cao]

code in uboot? uEnv.txt? kernel cmdline?

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/204cfe7f-c2ed-432d-ae33-1763ab214c46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Yiling Cao

http://ariaboard.com/

http://shanghainovotech.com/

[Charles Steinkuehler]

Probably the U-Boot default environment.

Hit a key at the U-Boot "countdown" prompt and dump the environment:

> printenv

You can follow along from the "boot" entry until you get to the point
where the kernel command line is being set. Edit that entry (editenv)
to use UART4 and then boot from the prompt.

Depending on your U-Boot, the default environment may be compiled in,
stored raw on the uSD, or in something like the uEnv.txt file.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Robert Nelson]

In this "init_console" function, in the shell environment...

https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2018.09/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch#L695-L702

Regards,

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

[Dave]

Thank you. 

I still can't figure out where it is being set incorrectly but I was able to use printenv and editenv and saveenv to correct it and I am now booting with the correct UART as console. 

On to the next obstacle !!

[Dave]

Thank you;

Changing init_console did the trick. 

I am now getting console output while booting into linux - For a while. 

Unfortunately instantly after the Linux eqep Linux Printk's  console IO ceases. 

It appears the board is still doing something - as the USR0 and USR2 LED's are active, 

I tried installing a significantly more minimalist kernel in the event that it was stalled dealing with some sub critical hardware. 

Is it possible that a setting in the Device Tree is re-directing the console ?

Is there an absolute bare minimum BBB Linux configuration that has pretty close to nothing critical except the console enabled ?

I can add things back in until I figure out what is failing. 

[Charles Steinkuehler]

On 1/28/2019 12:33 PM, Dave wrote:
> Thank you;
>
> Changing init_console did the trick.
>
> I am now getting console output while booting into linux - For a while.
>
> Unfortunately instantly after the Linux eqep Linux Printk's console IO
> ceases.
>
> It appears the board is still doing something - as the USR0 and USR2 LED's
> are active,
>
> I tried installing a significantly more minimalist kernel in the event that
> it was stalled dealing with some sub critical hardware.
>
> Is it possible that a setting in the Device Tree is re-directing the
> console ?

The device-tree doesn't affect the kernel console settings AFAIK.

Did you change the getty login console in your root filesystem as well
as the kernel console setting in U-Boot? You may just be seeing the
end of the kernel output and no login prompt (if you're really lucky).

> Is there an absolute bare minimum BBB Linux configuration that has pretty
> close to nothing critical except the console enabled ?
> I can add things back in until I figure out what is failing.

I'm not sure if there's a pre-existing config file floating around,
but you can definitely disable most of the AM335x specific drivers if
you think they're causing problems.

Can you provide the whole serial console boot log? Other eyes might
spot something wrong.

Also, any chance you can try booting your custom uSD on known good
hardware (eg: some other Octavo based board)? That might help isolate
what's going wrong.

...and then there's always the JTAG cable! :)

--
Charles Steinkuehler
cha...@steinkuehler.net

[Mark Lazarewicz]

..and then there's always the JTAG cable!  :)

Another option Dave There was a guy in here who consistently talks about toggling GPIOs and LESs. I'D ask him where to place these to shed light on what's going

Sent from Yahoo Mail on Android

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/3a950a18-1a3c-6fcb-660c-414b929cc4f6%40steinkuehler.net.

[Dave]

The snippet below is in the common dtsi for all am335x boards. 

What I am asking is if that snippet is meaningless, or if it has the actual effect of switching standard out at some point to uart0 ?

Also what is the simplest way to rebuild the am335x-bone-uboot-univ.dtb ?

I am not familiar with compiling dtb's in the linux kernel tree. 

Those have an assortment of includes. 

I am used to compiling standalone dts/dtb's 

Is there a 

make dtb

that will build the dtb for the current .config device ?

chosen {

stdout-path = &uart0;

};

[Dave]

I have made no changes to the root filesystem EXCEPT using bb-kernel/build_deb.sh  to build a relatively stripped kernel and installing that when the immage is booted on a BBB before switching to the target board.  

I have not messed with init, inittab, or systemd or getty. 

That may be something I look at next. 

I know UART4 is working.  If I setup /init /etc/inittab to run getty on it MAYBE I can get a login prompt - if linux boots far enough to spawn init. 

[Dave]

I am trapping serial output on BOTH the target board and a BBB booting the SAME SD card, with the only difference being the setting of init_console. 

After each has run as far as it will - in the case of the BBB I get a login prompt. 

I vimdiff the serial output captures. 

On the BBB I get alot of console output from the end of all the eqep driver setup through the login prompt. 

On the target all serial output stops with the eqep output - but the LEDS continue to be active. 

As they are soft - something is still executing

[Dave]

Serial capture files attached. 

I used vim to change the timestamps to #### to allow ignoring timestamp differences when comparing the files. 

mts.txt is the boot on the target board.

bbb.txt is the boot on a BBB

If you diff the two files there are very very few differences - none of which are consequential, prior to completing loading the eqep driver. 

After than the target board goes silent - though the leds flash. 

and the bbb continues and eventually shows a login prompt. 

[Dave]

I am booting my "custom" SD card in a BBB for reference purposes. 

My "process" is start u-boot, use editenv to chang the console as appropriate for the current board - ttyO0 on the bbb and ttyO4 on the target. 

saveenv. 

reset the board with serial capture turned on .

Do the above with both the BBB and the target board. 

Then vimdiff the captures looking for meaningfull differences. 

So I know the SD card is good.  And that aside from the console it works on a BBB.  

 

[Dave]

I KNOW this is a problem that I can ultimately defeat. 

I know I can attach a JTAG or I can add code to LINUX to flash LED's or something like that to place sentinels and divide and conquer until I find the offending problem. 

But that could be a very long tedious process possibily taking weeks. 

It is my beleif that this board is pretty close to working. 

I am looking for ideas to avoid the long and tedious approach I am already well aware of. 

I have done Linux board bringup on a completely new board - one that there were no existing reference boards for.

I am trying to avoid having to get that deep into things and hoping that the knowledge in this group can help shortcut the process. 

And I appreciate the help. 

 

[Dave]

I am trying to avoid using toggling GPIO's to trace.  I know how to do it.  But that could take weeks to find the problem. 

[Charles Steinkuehler]

On 1/29/2019 12:58 AM, Dave wrote:
> I am trapping serial output on BOTH the target board and a BBB booting the
> SAME SD card, with the only difference being the setting of init_console.
> After each has run as far as it will - in the case of the BBB I get a login
> prompt.

I don't think this is an "apples to apples" test. I haven't crawled
into the low-level differences between the BBB and the Octavo SIP, but
I _think_ at least the DRAM settings are different. Do you have a
Pocket Beagle or one of the other Octavo boards handy for testing?

Are you sure U-Boot is patched to handle your EEPROM-less board?

That said, if you were having SDRAM timing issues I'd expect the
kernel to crash and I wouldn't expect the failure to be so consistent
with USR LEDs still blinking. So I wouldn't chase SDRAM issues right
away, but just keep in mind that might be part of your problems.

> I vimdiff the serial output captures.
>
> On the BBB I get alot of console output from the end of all the eqep driver
> setup through the login prompt.
> On the target all serial output stops with the eqep output - but the LEDS
> continue to be active.
> As they are soft - something is still executing

See if adding a getty for UART4 gets you a login prompt. You don't
really need the kernel console if you can login, and with the USR LEDs
blinking it sounds like the system is probably still running.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Charles Steinkuehler]

It's "make dtbs", or you can specify the specific dtb you want to build:

https://www.lynxbee.com/how-to-compile-dts-to-dtb-from-linux-kernel-and-manually/

> chosen {
> stdout-path = &uart0;
> };

That could be causing your problems, and it almost certainly wouldn't
hurt to change it:

https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt

--
Charles Steinkuehler
cha...@steinkuehler.net