Early boot late attach question (for DRA726)

Hi Michel,

Your question has been forwarded to an expert for comments.

Best regards
Lucy

What is the GLSDK release version you are using ?

Regards

Ravi

Hi,

We used FAT partiton for validating early boot in our test environment. This is not a requirement. You can place the IPU binary in eMMC or NOR as long as you replace the function that loads the binary for FAT partition with appropriate functions.

Regards,

Venkat

I was thinking of using the latest one but I see that it is marked as Alpha which sort of scared me. The list of bugs is huge, do you have any idea when it will be considered stable?

It looks like I have to stick to GLSDK 7.04.00.03, the failing boot bug on quad spi is frightening.

So far I have been using the TMDSEVM572X for testing software. Our hardware won't be ready until sometimes in October.

Since there is no support for this in the GLSDK I have been using an SDK created according to the instructions on the TI website.  You changed it recently so that is when I assumed that we should use the one with systemd, that until I read the bug report on the GLSDK 3.0

We had to buy a few of those for the proof of concept to see if it was acceptable to switch from NXP to TI. The automotive EVM were a little pricy. Hard to justify buying 4 or 5 of those.

I see that there are still a few issues in the 7.04 release.

I am not planning on using HDMI at all so that doesn't affect my code.

One that bothers me a lot if the Weston crash. Our current customer has a battery disconnect so it is likely that some customers will decide to use this instead of taking the time to do a clean shutdown. So were are planning to have a early warning and then I would issue a quick shutdown. I am thinking about using halt. 

We use embedded wizard which runs on wayland. Do I need weston on or can I run embedded wizard directly using the wayland library?

We have no plan to use QT or xorg

Is it safe to do the halt for a quick shutdown? (The processor is DRA726)

If not do you have a suggestion that would get us to support the requirement. The customer is not willing to pay for the price of a battery backup.

I plan to have the filesystem readonly except when we write stuff which is not going to be often and I will have a warning message as not to disconnect the battery until it is safe to do so.

We need to shutdown in less than half a second. 

Our customer has an interesting requirement which has to be done very early and this is why I was looking at the early boot.

Unfortunately I don't think that it would be possible to do this with the early boot, correct me if I am wrong.

We need to respond to a proprietary CAN message within less than a second after the power is turned on.

I would hate to have to put can support in u-boot, is it possible? if so can I respond that fast if I put that support in u-boot?

One option which our project manager is willing to accept is to turn one GPIO on in u-boot within the same time, that would take a lot less time to do.

Any problem with that? Can it be done in such a quick time, if not, how fast?

It is a safety requirement to do this, it is on a boat.

Michel

Ravi,

Do you have a new kernel that would work with GLSDK? kernel 3.14 end of life is listed as August 2016.

Michel

Michel

The late attach feature is not supported in Processor SDK Linux Automotive 3.0 release (kernel 4.4). This feature will be available in next october-2016 release.  

Regards

Ravi

Michel,

I would recommend moving to our latest SDK - Processor SDK Linux Automotive 3.00 on K4.4. This version is under active development and addresses many of the issues you had noted such as Weston crash.

The main feature in K4.4 for Graphics is improved synchronization between GPU and Display. Fundamentally, we required atomic mode setting feature in DRM which was available only in K4.1 onwards.

The quality mentioned is Alpha but it is definitely worthy of starting development. If you are looking at starting on prototyping, developing, we will recommend 3.00 release. The K4.4 release will go through productization and hardening through next 2 quarters for a production worthy release in Feb'17. At that point, it will be ready for customers to take to production.

Regards,
Anand

Thank you but I have allready found this using google. I was looking for a pdf document for the libary. It is only available in html and I didn't see a way to have the TI website convert it to a pdf file as done on many of their info sites. I find it easier for my search than using google or the site search.

Michel

Michel,

In general is better to use the link, as you will always have the latest version.

Wiki page in pdf attached if this is what you need.

processors_wiki_ti_com_index_php_CMEM_Overview.pdf

Best regards

Lucy

That was not the overview that I could not get a pdf file but the library functions page.

I need some information on the early boot. How soon does the Cortex M4 (IPU1) will boot in this condition?

The reason we are looking at early boot is that a customer has a joystick connected to a CAN port (MCP25625). We need to turn on an output when a particular message comes up to tell us to do so. Normally the power is off on the DRA726 and it is powered on when a CAN interrupt is on the co-processor.
The Microchip device is on stanby when the DRA726 is turned off.
The output in question has to be turned on within half a second to one second.

The Cortex M4 handles the CAN (both local and 3 Microchip devices)
How long before the Cortex M4 can communicate with Linux. If it takes too long I have to have a check for a particular NMEA2000 message in the Cortex M4. I prefer to have my Linux BSP app take care of the NMEA2000 protocol. I would like to use the same Cortex M4 code for misc customers.

Michel

Hi Michel,

>> I need some information on the early boot. How soon does the Cortex
M4 (IPU1) will boot in this condition?

This is dependent on the size of the M4 binary. You would normally use
QSPI as the boot medium when trying to use early boot with tight boot
time constraints. QSPI data transfer rate is around 20-22 MBps. The
setup time for the 1st stage boot loader running on A15 is around 50
ms from PORZ. You should be able to load M4 binary and take it out of
reset in 0.05 seconds +(M4 binary size in MB/20) seconds. The
initialization time on M4 is dependent on the binary that was loaded.

>> The output in question has to be turned on within half a second to
one second.

Is the output referred to here just a GPIO?


>> The Cortex M4 handles the CAN (both local and 3 Microchip devices) How long
before the Cortex M4 can communicate with Linux. If it takes too long I have to
have a check for a particular NMEA2000 message in the Cortex M4. I prefer to
have my Linux BSP app take care of the NMEA2000 protocol. I would like to use
the same Cortex M4 code for misc customers.

The time for the Linux kernel boot is usecase specific and dependent
on functionality built into the kernel and where the rootfs is
stored.What is the time constraint for this usecase? Can you provide
information on the peripherals required for this usecase and size of
the BSP app + runtime dependencies?

regards,
Venkat

The output is a relay that turns a buzzer on. Basically the customer push on a button and wants the buzzer to turn on. The device sends NMEA2000 messages that can wake the co-processor on which will turn on the DRA726. At that point the DRA726 processor needs to check what message it is and decides whether or not the DRA726 should stay on. Normal boot timing is not an issue but the buzzer has to be turned on within half a second to one second, no later.

One quick question, for backlight, it the Linux kernel controls that? I need to have the Cortex M4 being able fake being off by turning the backlight off. The LCD is 12 inch custom design, we can turn the backlight on or off with a GPIO.

Michel

Michel,

I need to check if this is possible. Are you OK with the backlight being controlled exclusively from M4 or do you need backlight control from Linux as well?

regards,
Venkat

After checking out the device used I noticed that the message I need to look at is J1939 and not NMEA2000, not that it makes that much difference. The NMEA2000 messages are on a different CAN port where we do not require wakeup on.

As for the backlight we have two ways to control it, thru an I2C message or binary. I haven't seen the schematic yet from the manufacturer so I am not sure if one overrides the other one or if it is just an "or" condition.

As to who should control it I would say either one but Linux should not mess with it on boot until it has communicated with the Cortex M4. I want Linux in charge most of the time but on boot that has to be the one who boots the fastest.

Michel

I finally got some more information on the backlight. Unlike what I was told before we have direct control to the backlight thru a PWM port. So that won't be as big issue as first thought. I don't want some flashing on power up with Linux interfering with the Cortex M4 but do want Linux in full control for normal operation. That may not be an issue if Linux doesn't turn the LCD on until it has confirmation from the Cortex M4 that it is OK.

This means that I have to modify the Linux system boot up sequence to not attempt to display anything until it is considered acceptable to do so.

The system comes up with the LCD turned off by default.

One note on the lates automotive SDK.

Most of the time weston doesn't load on power up. But if I restart the systemd service it works, and it works every time.
It looks to me like perhaps the attempt to start weston is too early in the boot process, does my theory make sense? or is there a bug in the wayland libraries that would cause it to crash on startup?

If you have a fix for this, when can we expect an update?

Michel

Michel,

I have created an issue in the internal tracker for the weston issue. We will get back to you.

regards,

Venkat

Venkat,

This weekend I saw the same issue with the SDK for the Beaglebone Black . Before I went to the movies I turned the monitor off. I use the HDMI on the beaglebone. When I came back I turned the monitor back on and found the message on the screen, twice this time. It looks like weston had crashed. I had the same thing happening this morning when I turned the monitor back on, I had it on all night.
Why would it crash when the monitor is turned off or is it just a coincidence? So far the only time I see it crash is on power up or when I turn the monitor off. On the EVM board it would be kind of hard since I use the LCD on it. I haven't seen it crash yet in other condition ...

Michel

Michel,

I have not seen this behaviour on the DRA7xx EVM. We will keep an eye out for it.

This thread is diverging from the original question of early boot/late attach. Could you please post weston related questions in a separate thread?

regards,
Venkat