Skip to first unread message

Dave

unread,
Jan 12, 2019, 8:32:53 PM1/12/19
to BeagleBoard
I am working to bring up a BBB "clone". 

There are two significant differences that are/may be causing problems. 

1). UART0 is not accessible. 
2). The device does not have the BeagleBoard 32K I2C eeprom. 

Anyone have pointers for building a U-Boot that Uses any other UART besides 0 ?

Is U-Boot going to have an issue because of the missing eeprom ?
Linux ?


Do I just need to change uEnv.txt to force a specific device tree ?

Thank you





gra...@flex-radio.com

unread,
Jan 13, 2019, 9:40:54 AM1/13/19
to BeagleBoard
Well, Dave, you might have to consult the experts who know a whole lot more about the low level details of how the BBB boots, but I think you need to understand the following:

1.) UART0 is not required for the BBB to boot, but when the BBB does not boot, UART0 is the place that has the information about why it is not booting. So not a good idea to try to bring up a new piece of hardware without access to the debug port.

2.) You might note that the same software distribution runs on five or six very different pieces of hardware. Multiple variants of the BeagleBone and PocketBeagle with different hardware sets and capabilities.  The information that UBoot and probably the kernel, too, needs to figure out what they are dealing with, is in the EEPROM. So, if you are not going to provide that information, you are in for some rewriting and recompiling of probably both uBoot and maybe the kernel, so you can hard code the information somewhere that they expected to get from the EEPROM.  It is not as simple as providing a new device tree.

--- Graham

==

Robert Nelson

unread,
Jan 13, 2019, 11:12:56 AM1/13/19
to Beagle Board, m...@dlasys.net
Let's talk about this BBB "clone"... Did you copy the DDR and TPS*
specs from the BeagleBone Black, the original White board, or did you
use an Octavo SIP? I ask, because in u-boot the eeprom is used to
setup a whole bunch of voltage rails and ddr timing requirements.

Regards,

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

Dave

unread,
Jan 13, 2019, 10:44:14 PM1/13/19
to BeagleBoard
I did not do the hardware. 
I did not have much input to the hardware or UART0 would have been brought out
I will forward that question. 

But I beleive the board is using the Octavio SIP.

Further that makes sense with what I am seeing. 
Power up - power LED comes up, no other LED's. 

I have not looked through u-boot to see when it flashes USR0-3 LEDs - but I am not seeing them so I am guessing if anything is being loaded from SD it is dying fast. 

My next step would be to hook up a JTAG, but there is a deadline, and the prototype will get finished on a BBBW and I will come back to the production board later. 

Regardless, eventually this problem needs solved. 

I would like to hear that if I build u-boot differently everything will be honky dory. 





I have alot of embedded Linux experience - but less with the BBB. 
I was unaware that there was u-boot in eeprom in a BBB. 

Is the primary loader in the am335x or Octavio SIP capable of loading u-boot from the SDcard ?

If so is it possible to build u-boot to do the initialization that is not being done here ? 


















































Dave

unread,
Jan 13, 2019, 10:49:30 PM1/13/19
to BeagleBoard
Thank you. 

I know UART0 is not absolutely necescary. But unless the board "just works perfectly" or I connect up a JTAG to trace things tediously,  UART0 is conveninet. 
And I know that I can rebuild u-boot to use a different uart. 

I did not design the board.  I did not get hired until the board was into production. 
I do not have direct access to the hardware designer. 

I guess I am looking at a custom variant of u-boot. 

I was just hoping for something easier.  

Dave

unread,
Jan 14, 2019, 6:06:21 PM1/14/19
to BeagleBoard
I have been searching arround all day and gathering more information. 

The "Clone" board appears to be an Octavo SIP and is partly patterned after an PocketBeagle. 
There is also a display similar to that of the BB 4.3 Cape. 
The SIP eeprom is unlikely programmed, there is no eeprom to tell linux about the display. UART0 is not accessible, and there is no networking - beyond g_ether.

Even if I resolve the SIP eeprom - the display is not going to come up, and I am not going to have a serial console and I am not going to have network access to the board. 

And at this point I do not actually know that the board is good. 

To me that means I really need to rebuild u-boot - and assign the console to one of the other uarts. 
I might as well at the same time address the SIP eeprom. 

This board has a USB A and a USB B connector, so I can for development purposes attach a USB NIC to gain network access to the board. 
But I still probably need the serial console until I have the net fully configured. 

I pulled your "Bootloader-Builder" Github repository as there was a patch there to address the eeprom issue. 

But just running build.sh ran for hours, failed, and is probably not what I wanted. 

I commented out most of the builds at the end of build.sh. 

I am guessing that I want am335x_bone_flasher enabled. 
But I also want to enable a patch to assume a pocketbeagle 
as well as to change UART0.  
















 










Charles Steinkuehler

unread,
Jan 14, 2019, 10:45:32 PM1/14/19
to beagl...@googlegroups.com
I design hardware for a living.

You need to throw this back at the hardware designer and have him/her
present you with a workable board.

They took a SIP designed to take all the hard work out of making a
BeagleBoard clone and managed to mess things up enough so that it
won't boot and you can't even tell how.

At the very least, I would insist on having them wire up UART0 so you
can have a console. Unless they royally f**ked up the PCB layout,
this should be possible by soldering a few "flying wires" to some via
pads. If they didn't fanout all the SIP pads to vias, you have my
permission to shoot them! :) <just kidding>

Best of luck!

...and if you don't want to get confrontational with the HW guys, you
should be able to fairly easily compile U-Boot to use a different
serial port. That ought to get you any console info printed except
for the character(s) printed by the actual ROM boot loader. And once
you have console output, debugging gets a *LOT* easier. :)
--
Charles Steinkuehler
cha...@steinkuehler.net

Dave

unread,
Jan 15, 2019, 1:01:46 AM1/15/19
to BeagleBoard
Thanks;

I would love to get confrontational with the hardware designers, but I am two levels removed in different companies 
It is possible that UART0.TX and UART0.RX have been brought out to VIA's - but they are not labeled, and I do not have a PDF or gerber of the board layout. 

There have been a number of errors on this already - either the masking or pick and place screwed up and delayed the boards almost a month. 

My problem is that there is a deadline for a prototype in Early Feb. 

No matter whose fault it is, if the deadline is blown it will be bad for all. 

I design hardware for fun - though nothing I can not build myself with 60 year old eyes - that rules out SMT

I write software that works with hardware for a living.  Mostly linux. 

I have done board bring up on boards with no linux support at all so I can work my way through this the hard way if I have to. 

Yes, it is really mean not to bring out UART0. 
The debug UART is absolutely critical for board bring up, and near useless afterwards. 
Just two pads that is all I want. 


As I think of it I am going to have fun with UART1-4 too.  They have level shifters, so my TTL USB serial cable wont work. 
I am going to have to find my old RS232 level cables. 






Dave

unread,
Jan 15, 2019, 3:34:48 AM1/15/19
to BeagleBoard

I followed these instructions 

and additionally set 
CONFIG_CONS_INDEX=4 in the defconfig.

Held the boot button and cycled the power. 

The USR0 LED did not come up. 

Can I presume there is a more significant issue than that the eeprom is blank ?

 

Charles Steinkuehler

unread,
Jan 15, 2019, 9:38:19 AM1/15/19
to beagl...@googlegroups.com
I don't know enough about the BBB U-Boot to say for sure, but given
the issues you're having, I'd try to isolate what's wrong as early as
possible:

1) Verify your boot loader is actually running by toggling a GPIO or
perform some other externally visible activity *IMMEDIATELY* after the
boot loader code is launched. In other words, in the MLO code, before
things like SDRAM are available.

2) Once you know you can actually run code, verify the SDRAM is being
properly initialized and can be successfully accessed. You can likely
use one of the other UART ports for some diagnostics here, but
toggling GPIO pins or LEDs for status is always a fall-back.

3) Make sure the interface to whatever storage you're using (uSD
card?) is actually working.

4) At this point, you should be able to proceed with development
mostly as normal until you get the boot loader working properly and/or
figure out what's wrong with the board (other than the missing EEPROM).

...or you could just try debugging from reset using JTAG, but I'm a
hardware guy so I tend to shy away from most of the SW debugging
tools. Unless I'm really desperate, they tend to take more time for
me to setup than they save in debugging. But if you're already
working in an environment that supports the JTAG debugger, this might
be easier for you.

Also, if you've got schematics, double-check the settings on the boot
pins, both in the schematic and on the physical board. There should
be pull-up and/or pull-down resistors to set the mode. If there were
issues populating the board, that could be messing with your intended
boot mode and you'll never get anything to work.

Good luck!

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

Dave

unread,
Jan 17, 2019, 12:55:49 AM1/17/19
to BeagleBoard
Would you know where there is a minimalist example of setting GPIO for USR0 on that assumes nothing. 

i.e. if necescary sets the pin mux or whatever else might be needed ?

Basically some BBB GPIO bare metal example. 

Mark Lazarewicz

unread,
Jan 17, 2019, 5:35:10 AM1/17/19
to beagl...@googlegroups.com



--
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/0213a2e6-7604-4863-bd83-98008865330b%40googlegroups.com.

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


I'm a retired low level SW engineer mostly for RTOS and barebones. If you are low level capable/board bring up SW  in the interview alarm bells would be screaming. From your last question I'm confused BBB minimal example why? You said they expect you to get work done on BB white.
This deadline story smells like you were setup I hope this is a $100 hour contract not some 2 month permanent job.
Don't fight the HW guy but if he isn't willing to help you get correct DDR timing values for HW if the bonehead didn't use exact HW as reference  you may be working 80 hrs a week free if its not a contract job.

In the year since I last used this on omap 17x 
Its been deprecated.


good luck
I have no idea what you plan on doing with this.You say you have extensive linux experience in what apps? If so I'd plan an exit plan 










Charles Steinkuehler

unread,
Jan 17, 2019, 8:10:06 AM1/17/19
to beagl...@googlegroups.com
On 1/17/2019 4:34 AM, 'Mark Lazarewicz' via BeagleBoard wrote:
> I'm a retired low level SW engineer mostly for RTOS and barebones. If you are low level capable/board bring up SW  in the interview alarm bells would be screaming. From your last question I'm confused BBB minimal example why? You said they expect you to get work done on BB white.This deadline story smells like you were setup I hope this is a $100 hour contract not some 2 month permanent job.Don't fight the HW guy but if he isn't willing to help you get correct DDR timing values for HW if the bonehead didn't use exact HW as reference  you may be working 80 hrs a week free if its not a contract job.
> In the year since I last used this on omap 17x Its been deprecated.
> http://www.ti.com/tool/STARTERWARE-SITARA
>
> good luckI have no idea what you plan on doing with this.You say you have extensive linux experience in what apps? If so I'd plan an exit plan 

+1 on using starter-ware as a reference for low-level configuration,
but with any luck you won't have to dig that deep into the guts of things.

The U-Boot code is already doing low-level hardware configuration, you
just need to tweak things a bit. There are already functions
available to setup the various UARTs and I2C. I think you should be
able to modify the SPL code (which is trying to read the EEPROM and
properly setup the SDRAM, among other things) to provide some
externally visible output.

NOTE: Since your board is based on the Octavio part, at least you
don't have to worry about the DRAM bus timings or trace routes being
messed up. I think if you can get your code running (double-check all
boot mode pins) and hard-code the EEPROM auto-detect, you should be
able to get running. #FingersCrossed

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

Mark Lazarewicz

unread,
Jan 17, 2019, 4:52:04 PM1/17/19
to beagl...@googlegroups.com
--
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/e713d993-e083-8f85-de4f-cc85e0ae7d2c%40steinkuehler.net.

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

Hey said he wasn't sure which parts were used he had no input on hardware which is bad news.
All my comments are based on if the HW guy rolled his own board trying to keep things cheap that's the worst case.If he used standard parts he could fake out the boot code. The problem is it sounded like there is no eeprom if that's true the HW guy is cutting corners. I've yet to see a HW guy worry about software porting issues after all they say SW is free. I've also never saw a manager who was behind schedule Not minimize the board support and bring up he's gonna say what's the problem. Hopefully I'm wrong. I always ask these questions in an interview. If I'm right he's gonna be the scape goat for the schedule and that's O.K. if your 80 hours a week is paid😊

Dave

unread,
Jan 20, 2019, 2:11:22 AM1/20/19
to BeagleBoard
Thank You. 

My advice to all of my clients - including this one is that - Unless you are GM and making a million of something, the hardware design should deviate the least possible from whatever reference design or development system you are using. 

It is just not possible to save enough money on production runs of 100, or 1000 to justify the software costs to support changes to hardware that are not very important.  Additionally software takes time and lengthens the critical path - increasing your time to market. 

My advice is pay a small amount more if necescary for hardware - a few dollars a piece on 100 boards is cheap. 
Or you will spend alot more on software. 

Do not get me wrong - I am an embedded developer - nothing makes me happier that a successful struggle to get that first LED to light on a new board. 
When you take my advice - I make less, the task is not as rewarding - pluging an SD card into a board and having it just boot right up, is really good for the client - but it does nto pay my mortgage and warring with a recalcitrant hardware and winning is intellectually rewarding. 


In several instances this client DID change their design to reflect exactly that advice.
In some they did not. 

After a full day with the client - it is my view that the boards are sufficiently Fubar that they can not be fixed by software. 
I eventually had to JTAG the board and the JTAG is reporting the processor is halted, and that it can not get it to run. 

Though there might be some design issues - like not bringing out UART0 pins making debugging much harder, 
I beleive the most fundimental problem is with the board assembly.  Several parts were installed 90 or 180 degrees off. Or not quite on their pads. 

This is outside my scope. I am old enough and my eyes are just not good enough to find and fix placement and soldering errors on SMT boards. 

The client is currently working with the hardware engineer on the boards. 

I beleive they are trying to either remove everything non-essential, or build a new board with the barest minimum of hardware. 















I spent a whole day with the client working on the board. 

Dave

unread,
Jan 20, 2019, 2:17:18 AM1/20/19
to BeagleBoard
Thank you. 

I have pretty much done what you suggested - I built a custom u-boot, using patches from Mr. Nelson that assumes a BBB, 
I also moved the Debug Uart to Uart 4. 

Still no joy.  Do not get to USR0 lighting up. 

I fired up CCS 7.4 and my Segger JLink and the CCS instructions - I Beleive for Starter-Ware, and could not get the Segger to execute code in the processor. 
It told me the processor was Halted, and refused to start. 

IF I were to continue with this board I would be putting a Scope or Logic Analyzer on the sdcard lines to see if anything at all is happening. 

But I spent a day at the clients with the board - and kept finding more and more assembly errors on the boards. 

Hopefully the guy who built the hardware is now fixing it. 





 

Mark Lazarewicz

unread,
Jan 20, 2019, 7:15:58 AM1/20/19
to beagl...@googlegroups.com
Good job glad you were able to convince the client. I've been in situations like this where they wouldn't change the hardware its a goldmine if your a consultant. I'm also encouraged you were smart enough to use a jtag its folly to do board bring up without it unless you want it to take longer = big $$$
Jtag is your friend
Mark

--
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/368fc622-c7d6-4dfb-b425-4167a7ae7a46%40googlegroups.com.

Dave

unread,
Jan 23, 2019, 4:02:50 AM1/23/19
to BeagleBoard
I do not have a problem with JTAG, and I have a large collection of JTAG and similar debug probes. 

But I rarely use them. 

My work is inconsistent. I move from BBB's to Opi's to Freescale K70's to STM32's to PIC32's to PPC405's to RISC-V's to TI CC1310's .....

It is difficult to become expert with a specific tool when that tool is unique to the current project and you have not worked with that tool for a couple of years and when the current project is over you may not again for a long time. 

I brought up the JTAG to add a bit more evidence to what I was close to certain of already - the Processor was not running. 

The JTAG confirmed that - at the same time I was/am not entirely convinced that the JTAG was hooked up properly, the software accurately reported results. 

One thing I have learned in decades of this work is to be very careful about assumptions. It is OK and often the best evidence you can get to say - the JTAG says the CPU is halted and will not start and that result is more than 50% likely to be correct.  It is altogether different to say with certainty something that the evidence only supports probabilistic. 

I would like to say I have never been certain and also been wrong. But that would not be true. 
I am happy to say that many times I have resisted being certain about something that was merely likely and avoided going down a wrong path by waiting for more evidence or looking more carefully. 

As noted I have been doing this for a long time. More than a decade ago I write JTAG software for a PCMCIA device that had its own Custom JTAG internal to the device - that is starting to become common today.  I have done bare metal linux board bring up on devices that were so radically different form the development systems as to make the existing support near useless. 

Today it is increasingly rare that the product is not so damn near identical to the development system that you put an SD card in and the first boards just boot right up.  I do more of what I would call Linux embedded systems administration than actual systems software. 

BTW after stripping half the components from the board, I am told the board finally booted.  I will be receiving a purportedly working board tomorow. 

I am not going to trash another engineer by name, but I have not seen a new board with this many errors in years.  Though I think all of them were assembly errors. 

Anyway I have JTAG's and USB TTL Serial cables, and  I typically use them for about 5 minutes on a new project. Once the board boots, I ssh into it and work that way.  Further most of the time I write and test software on an x86 linux desktop and build and run it on the target only toward the end. 


















Reply all
Reply to author
Forward
0 new messages