Where is the initial system time defined for a yocto system without reliable time source? - yocto

I try to figure out, where a yocto based OS gets its initial system time set, when there are no other sources available (no [synced] rtc, no ntp). The board here starts with something in October 2020, but I can't find that time stamp anywhere in the sources.
So where do I have to look to find or set the default bootup system time?

Related

IMX8MM Linux: Change Shutdown behavior

I have just started to work in a project where the product uses a imx8m mini module together with Yocto Linux (Zeus).
Currently we have a problem related to the shutdown behavior of the product, and we need to modify what happens during a shutdown.
As today when we shutdown or a thermal emergency happens, the PMIC_ON_REQ(That controls the external power regulator) goes low, but we need to change this behavior that it keeps the current value on PMIC_ON_REQ, as we have other diagnostic devices that needs to talk to the PMIC after that the imx8mm has turned off. In other words: I want to keep the value of the gpio as long as possible, until the control is out of reach.
But my current problem is that I don't know where to start, or what kernel module I shall look into.
Does any one have any clue where I shall start to look to be able to find the code for patching?
I have tried commands in devtool like "devtool modify power/thermal/soc" but without finding the needed code..
Please observe that this is my first Yocto project ever, so if I write something strange, bare with me

Simulink Real-Time Desktop model: why does it rebuild on every run?

I have a Simulink Real-Time Desktop model that launches from a GUIDE application in External mode. My problem is how to run the model without Matlab rebuilding it every single time.
In the _OpeningFcn I included a 'rtwrebuild' command with the expectation that this would rebuild the code only if the model had been changed since the last run. However, when I start the real-time simulation using set_param(MODEL, 'SimulationCommand', 'start', ...), it invariably rebuilds the code regardless of what 'rtwrebuild' did. How can I keep the start command from causing all these unnecessary builds?
Since I don't have reputation enough for posting a comment request for clarification, I'll ask it here; did you check the rebuild option setting in the configuration set?
From my own experience it take a long time even if set to only rebuild if changes detected because it still opens every single file in the model tree to check that nothing was changed. Also I think some parameter changes counts as cause for rebuild. If you don't want that you need to set "Never" rebuild and control this yourself.

Command line arguments for Scratch 1.4

I'm using Scratch 1.4 for preparing a course for children.
The course is about controlling real devices (self built traffic lights, modified toys having motors, sensors, etc.)
For interfacing the hardware I'm using the Remote Sensor Protocol and the control-lines of a RS232 interface (3-in/3-out, all digital).
Everything works great, except small inconveniences:
The children have to do many steps manually:
start scratch first,
load a template project which enables remote sensor protocol and defines variables
accept the warning message notifying, that remote sensor protocol is enabled
start RSP-RS232 proxy
I'd like to simplify it by starting scratch from my tool, ask Scratch to perform steps 2,3 by command-line arguments and finally connect to the RSP port.
Is it possible?
If not, is it hard to implement these parameters in Smalltalk for someone with no Smalltalk experience (but other languages like C++)?
Thank you!
Ok, after some readings I could answer my question.
Bad news is: there is obviously no command line argument in Scratch passing a project-file as a start-project.
However good news is, it is not difficult to change the scratch for own needs. Several projects do it, e.g.:
Scratch 4 Arduino
Scratch GPIO
How to do it is described here:
http://wiki.scratch.mit.edu/wiki/Scratch_1.4_Source_Code
Scratch and Squeak
...
To get started, first copy the Scratch application ("Scratch.exe" or
"Scratch.app") from your normal Scratch folder into the Scratch source
code folder. (The Scratch application is actually just a Squeak
virtual machine, so any recent Squeak virtual machine should also
work.) Also, put copy of the Squeak source code file in that folder if
needed (this file is included in the zip file starting with the 1.4
source release). Finally, drop the file "ScratchSourceCode1.4.image"
onto the Scratch application. The Squeak programming environment will
start up, allowing you to view and modify the Scratch source code.
I was able to disable the dialogue notifying that remote sensors protocol is enabled
and to enable remote sensors at start by default. Took me 2 hours.
P.S.:
For those interested, I host my project here: https://github.com/vheinitz/Qratzfest
As I've found out, my Idea was not new (I've looked for this possibility about 3 years ago, but there was nothing). What is different, the proxy-tool is for PC, and is intended to use any hardware, not dedicated only to a specially firmwared Arduino or PI. Currently only control-pins of a serial interface are supported and linked to fixed names.
Soon it will provide the possibility to map any pin to any Scratch-variable.

Bootloader countdown timer stuck at 4 seconds

I seem to have a problem for one the servers that i am handling, i have reinstalled CentOS for nth times, and formated everything, edited the grub.conf time out = 0, but all still the same, the grub timer wont move, always stuck.
Did you end up finding a solution to this? I just had a server with this exact issue right after a fresh install of CentOS 6.x. Even though the system seemed to be keeping correct time, replacing the CMOS battery resolved the issue for me. This was either due to a faulty battery, or the CMOS settings getting reset when I replaced the battery.
Here are the sites that led me to that solution:
https://serverfault.com/questions/42877/grub-hangs-after-x-2-seconds
http://www.tomshardware.com/answers/id-1809044/centos-grub-countdown-stops.html
A user on one of those sites said that clearing the "System Event Log" fixed the issue for them. Here are some guides on accessing and clearing the SEL/BMC log:
http://download.intel.com/support/motherboards/server/s7000fc4ur/sb/sel_viewer_ug_e1246101.pdf
http://www-947.ibm.com/support/entry/portal/docdisplay?lndocid=MIGR-59226
The issue could also be related to Grub's recordfail logic. More info here:
https://askubuntu.com/questions/202309/cannot-get-grub-menu-to-timeout-or-go-away?newreg=dc178d813fbb4f0d803644799bb89c5e
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/872244
Try adding this to /etc/default/grub
GRUB_TIMEOUT=10
GRUB_RECORDFAIL_TIMEOUT=$GRUB_TIMEOUT
Then run sudo update-grub
Support for GRUB_RECORDFAIL_TIMEOUT was added in the middle of the 12.04 cycle, starting from version 1.99-21ubuntu3.3
Check the date/time setup of your server. After I changed the CMOS battery, server's (HP Proliant) clock was 4 days behind and had same issue, the problem was fixed after setting it up correctly.

how to suppress the enoying dialog boxes when developing xPages?

Anyone know how to remove or supress the enoying dialog boxes when developing xPages
If you are just making small xpages application you might not see these very often, but the more complex your xPages get you see these all the time. specially when you navigate your xpage using the outline view or during build
I click the x several times every day to get rid of it, Not sure if the operation quits when I click the x or if it continues in the background.
I would like a setting to get rid of it once and for all
Well, in your designer, you should disable Build automatically in the Project menu. This will remove the constant build, but also means that you have to build manually, when needed.
You could also take a look at Nathan T. Freeman's post on the matter # Making Domino Designer work like you want
Are you using any java libraries added to the webinf/lib dir in your nsf? I noticed that when adding any jar files to the lib dir rebuilding your application can take ages..
I had 2 external jar files used in my project (contained within the database). It used to take around 5-10 minutes to compile the project. Any changes to the XPages/Custom Control/Java files needs a recompile. And you can imagine the frustration I had with the compilation time. Later I detached the jar files and put under the jvm\lib\ext folder. The compilation time drastically reduced to 1 minute. Still not happy.
As a next step, took a local replica of the database and started making the changes and recompilation on the local replica. Once done, replicated the databases and always previewed the changes on the server version. The compilation time is hardly 10 seconds. So 10 minutes to 10 seconds :)
Switch off build automatically, it will solve most of these.
There is also a known issue SPR SODY8Q9KNA where Java Design elements (new feature in 8.5.3) keep getting rebuilt on designer start up. That brings up the same pop-up.
There should be a fix for that in 8.5.3FP1 but I am not in an official position to say it will be in FP1 until it actually ships. You can check in the release notes as they are updated.
http://www-10.lotus.com/ldd/r5fixlist.nsf/(Progress)/853%20FP1