[andyolivares]

Just a follow up… yesterday I made my own BB linux image based on the instructions provided and it booted just fine. Although, the problem of Kernel Panic when shutting down (“sudo poweroff” or “sudo shutdown -h now”) persists. I observed that the problem does not occur when halting the system (“sudo halt”). Maybe the PMIC is not really powered off on that mode?

Other thing I noted is that I populated the 1M Ohm resistor on my RTC crystal circuit (https://www.dropbox.com/s/vzud4fzz26zgozi/rtc_clock.PNG?dl=0) but it is not being populated on the RED board. When I first saw this problem and I checked RTC oscillations with a scope, I got a 32KHz sine wave but didn’t payed much attention to the amplitude of the signal. Do you think that might be the cause? Maybe the clock is oscillating at the right frequency but not strong enough.

Will check the clock levels later today on a RED board I have and compare that with my own board to see if there’s any difference.

I’m posting all my process here just in case it will help somebody else in the future 🙂

[andyolivares]

Hi Neeraj:

I’m revisiting this issue now that I have some more free time but still with no luck. I suspected that my problem was due to a failed RTC initialization due to my u-boot being patched to avoid the EEPROM check.

I programmed EEPROM with proper value to be recognized as a OSD3358-SM-RED reference board (as my board is pretty similar to that board except for a few missing peripherals) and I can confirm that the EEPROM had successfuly programmed those bytes. A power up after programming the EEPROM confirmed that the memory was intact. This confirms that a) the I2C bus is working just fine and b) the EEPROM memory works and retains its data.

I then booted lastest BB IoT image with success. I had to modify the uEnv.txt file to set my “dtb” file with my board’s Flattened Device Tree binary and I can see that my board is recognized as a RED board and initialized as such.

The OS seems to work fine but I’m still receiveing the same kernel panic on shutdown. If I keep the uEnv.txt unmodified (as it comes on the BB image), what DTB file is being loaded?

Can you give me some feedback on the contents of that DTB file? I’m suspecting there is something I’m not including in mine. My DTB source file is based on this one: https://github.com/octavosystems/OSD335x-Device-Tree/blob/master/OSD3358-SM-RED/osd3358-bsm-refdesign.dts but I’m not sure if that is up to date, or what’s really included on the BB image.

My actual DTB source can be seen here: https://github.com/andyolivares/dtb-rebuilder/blob/swms-ltb/src/arm/swms-ltb.dts

I want to make sure there is no configuration mistake before trying something more “advanced” like recompiling the kernel and building my own Linux image with more log entries as you previously adviced.

Thank you in advance for any help.

[andyolivares]

Thanks for the valuable info again. I was indeed designing a board with KSZ8081 from Microchip/Micrel in RMII mode but read on other sites and TI forums that they had some problems with that chip. I don’t know if they ever solved those problems but I thought I better go with a proven design for now.

[andyolivares]

Easy BGA layout is definitely one of the best features of current Octavo System’s offering. Where I live, it is very difficult to find high-end PCB houses and using Octavo System products has enabled us to make some products that we didn’t have any chance to do a couple of years ago.

Relaxed BGA ball spacing and optimized ball layout allow people like me (with no experience in high speed layouts) to tackle projects I didn’t think of.

So keep the easy BGA routing… it’s definitely a must! 🙂

[andyolivares]

Will check that out but I’m not very familiar with the whole kernel re-build process so bear with me. If you have some guidance on how to accomplish these tasks, it will be greatly appreciated. Also, to make sure I’m on the same page, you are pointing me to a specific file on kernel “4.14.y”… should I compile that specific kernel or the version present on the IoT image I’m using?

BTW, I applied Robert C Nelson patches on U-Boot to avoid EEPROM check on my board. I understand that these patches make U-Boot to assume a certain board ID and hence its configuration… maybe this configuration is not initializing RTC clock as expected?

Do you recommend on keeping this patches applied or should I program my EEPROM memory somehow with my own board ID (or compatible board ID)?

Thanks again for all the help!

[andyolivares]

I’ve compared both schematics and they look fine to me. This is my schematic:

https://www.dropbox.com/s/vdrj9qy9sjym0p4/pmic_i2c.png?dl=0

Also, I can confirm that I have a pretty stable 32 kHz oscillation on OSC1.

Thank you!

• This reply was modified 6 years, 2 months ago by andyolivares.

[andyolivares]

Hi Neeraj:

Today I tried with latest IoT image from beagleboard.org, but I’m having the same kernel panic error message:

[ 138.699523] reboot: Power down [ 141.186025] rtc_power_off failed, bailing out. [ 141.200515] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000 [ 141.200515] [ 141.209724] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 4.14.67-ti-r73 #1 [ 141.216897] Hardware name: Generic AM33XX (Flattened Device Tree) [ 141.223079] [] (unwind_backtrace) from [] (show_stack+0x20/0x24) [ 141.230882] [] (show_stack) from [] (dump_stack+0x80/0x94) [ 141.238172] [] (dump_stack) from [] (panic+0x100/0x284) [ 141.245189] [] (panic) from [] (complete_and_exit+0x0/0x2c) [ 141.252552] [] (complete_and_exit) from [] (SyS_reboot+0x1c8/0x238) [ 141.260618] [] (SyS_reboot) from [] (ret_fast_syscall+0x0/0x54) [ 141.268349] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000 [ 141.268349]

1 2 3 4 5 6 7 8 9 10 11 12 13 14

[  138.699523] reboot: Power down [  141.186025] rtc_power_off failed, bailing out. [  141.200515] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000 [  141.200515] [  141.209724] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 4.14.67-ti-r73 #1 [  141.216897] Hardware name: Generic AM33XX (Flattened Device Tree) [  141.223079] [] (unwind_backtrace) from [] (show_stack+0x20/0x24) [  141.230882] [] (show_stack) from [] (dump_stack+0x80/0x94) [  141.238172] [] (dump_stack) from [] (panic+0x100/0x284) [  141.245189] [] (panic) from [] (complete_and_exit+0x0/0x2c) [  141.252552] [] (complete_and_exit) from [] (SyS_reboot+0x1c8/0x238) [  141.260618] [] (SyS_reboot) from [] (ret_fast_syscall+0x0/0x54) [  141.268349] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000 [  141.268349]

I don’t know what could be wrong. Any ideas?

Thank you very much.

[andyolivares]

Hey Neeraj, thank you for the info! Can you share what specific USB audio IC did you use in your project?

Thanks again.

[andyolivares]

There’s nothing particularly special about that MPU except its price. My humble opinion is that a cost effective SiP for (power-)constrained IoT applications could contain:

– CPU @ 400 Mhz or more (with good Linux support)
– RAM (256 MB seems acceptable)
– microSD interface
– Ethernet interface
– 2+ x SPI
– 1+ x I2C
– 1+ x I2S or similar
– 1 x USB device
– 1 x USB host
– Some GPIOs
– (Optional) Flash memory (4GB+)
– (Optional) LCD interface & touch controller

That’s on top of my mind for now.

I’ve been looking for other possible MPU options on that leagle and NXP i.MX28 (ARM926) series looks like a good candidate. Also, NXP has low-cost Cortex-A options like the i.MX 6ULZ or 6ULL series. Although, I don’t know about NXP’s Linux support and community.

I assume you’re aware that Microchip has their own SiP offering based on their ATSAMA5D27 Cortex-A5 MPU (ATSAMA5D27C-D1G-CU) at about ~$15 @ 100pcs, but its 0.8mm ball spacing and pin layout is still hard for cost-effective PCB design.

A price around $20 @ 100pcs seems reasonable to me, but of course that’s just my wish 🙂

[andyolivares]

I also see some potential on lower-end MPUs also. Even though having a good Cortex-A processor at 1 GHz speeds is very nice, I see some other markets where that is just unneeded/overkill, and a simpler MPU at lower speeds, could solve many problems and be more cost effective. OSD335x-SM at current price tag is somewhat prohibitive for some projects that would greatly benefit from an MCU with Linux.

For example, take the AT91SAM9G25 (ARM926 at 400 MHz) for example; it would be nice to have a SiP with integrated RAM, power management and above all, a friendly pin distribution and spacing for accesible 4-Layer PCBs like the current offering. Atmel MPUs (now Microchip’s) have also an active community and good Linux support AFAIK.

Maybe you can consider a lower-end & lower-cost option, specially for those making the transition from an MCU to an MPU for industrial and IoT applications.

My two cents 🙂

[andyolivares]

Hi Neeraj, I will try with a recent image and see if that solves the problem. I’ll get back to you with my findings. Thank you!

[andyolivares]

Yesterday, after a lot of testing, I decided to go all the way up again, so I performed the following tasks:

1- Compiled u-Boot with Robert Nelson patches to assume board is BB (https://octavosystems.com/forums/topic/osd3358-boot/#post-4733)
2- Downloaded latest SM-RED Debian image just in case (I was using latest official BeagleBoard image in my previous tests)
3- Put image into uSD card using Etcher
4- DD MLO and u-Boot from 1
5- Compiled & installed Robert Nelson’s “dtc” tool (https://github.com/RobertCNelson/dtc). This was needed as I’m using CentOS.
6- Cloned Robert Nelson’s dtb-rebuilder repository (https://github.com/RobertCNelson/dtb-rebuilder)
7- Created a custom Device Tree file (dtb-rebuilder/src/arm/myboard.dts) based on SM-RED Device Tree but fitted exactly to my custom board
8- Compiled the Device Tree to get a Device Tree Binary (dtb-rebuilder$ make src/arm/myboard.dtb)
9- Copied new DTB to my uSD card (/boot/dtbs/[kernel_version]/)
10- Modified “dtb” variable in /boot/uEnv.txt from uSD card (3) to point to my newly created DTB
11- Put the uSD on my board and power it up

I now observed almost no errors and it all went very smooth up to the point of seeing the “Starting Linux…” where I saw a couple of warnings and it stopped with an error saying that it didn’t find my /dev/mmcblk0p1 device (very similar to https://octavosystems.com/forums/topic/custom-board-gave-up-waiting-for-root-device/).

After some investigation, I noticed that I had removed “mmc1” declaration from my Device Tree thinking it wasn’t neccessary (due to the fact that it was “mmc1” and my uSD is tied to “mmc0”), but it seems like the Device Tree numbers the MMC interfaces from 1, so “mmc1” is actually “mm0” on the processor.

Once I fixed that and rebuilt my DTB (steps 8-11) it worked just fine and I was presented with Linux login prompt.

I thought on documenting my process if that helps anybody. I will test the same process with my custom DTB but with BeagleBoard official releases to see if that works as it seems like BeagleBoard releases are more up-to-date than the SM-RED image.

Best regards!

[andyolivares]

I have almost the same problem. I did a custom board with microSD card connector on MMC0.
All voltages on test points are within expected values. When I power on the board with no microSD in place, I don’t see the “C” character coming from the serial interface (115200N1). But if I power the board with the microSD inserted, it “boots” and I can see all u-Boot messages up to the point:

unable to find [dtb=am335x-boneblack-emmc-overlay.dtb] did you name it correctly? …

FAILSAFE: U-Boot UMS (USB Mass Storage) enabled, media now available over the usb slave port …
Unknown command ‘ums’ – try ‘help’
loading /boot/initrd.img-4.14.49-ti-r54 …
4034122 bytes read in 365 ms (10.5 MiB/s)
debug: [console=ttyO0,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet] …
debug: [bootz 0x82000000 0x88080000:3d8e4a 0x88000000] …
ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree
** Invalid partition 2 **
** Invalid partition 3 **
** Invalid partition 4 **
** Invalid partition 5 **
** Invalid partition 6 **
** Invalid partition 7 **
Card did not respond to voltage select!
mmc_init: -95, time 12
gpio: pin 56 (gpio 56) value is 0
gpio: pin 55 (gpio 55) value is 0
gpio: pin 54 (gpio 54) value is 0
gpio: pin 53 (gpio 53) value is 1
Card did not respond to voltage select!
mmc_init: -95, time 12
gpio: pin 54 (gpio 54) value is 1
Card did not respond to voltage select!
mmc_init: -95, time 13
** Bad device mmc 1 **

And it stays there and won’t boot the microSD image. I did this image following instructions from https://octavosystems.com/forums/topic/osd3358-boot/#post-4733 to avoid EEPROM checking.

I assume that after the message “ERROR: Did not find a cmdline Flattened Device Tree” it tries to boot from MMC1 as I can see some messages trying to initialize a card on that interface. And after, it seems to try a USB device with no luck also (no USB device connected).

Tinkering with u-Boot console, I can see contents on the microSD card (MMC0), so I assume it is working properly. I can also see messages saying that it loaded Linux kernel (vmlinuz) and initrd.img from /boot with no aparent problems.

Any ideas?

PS: Attached my boot log for your reference.

• This reply was modified 6 years, 3 months ago by andyolivares. Reason: Additional information added

Attachments:

1. bootlog.txt

[Author]

Posts