https://elinux.org/index.php?title=Special:NewPages&feed=atom&hideredirs=1&limit=50&offset=&namespace=0&username=&tagfilter=eLinux.org - New pages [en]2024-03-19T06:22:46ZFrom eLinux.orgMediaWiki 1.31.0https://elinux.org/Jetson/L4T/r35.5.x_patchesJetson/L4T/r35.5.x patches2024-03-06T06:29:23Z<p>Jerry: </p>
<hr />
<div>'''Multimedia'''<br />
[gstreamer] memory leak in nv3dsink<br />
https://forums.developer.nvidia.com/t/gstreamer-nv3dsink-memory-gstcaps-leaks/283056/19<br />
<br />
'''Security'''<br />
[EKS] please re-generate a new EKS image by flashing JP-5.1.3 with security enabled. <br />
https://forums.developer.nvidia.com/t/284400/8<br />
<br />
'''Misc'''<br />
<br />
'''Boot'''<br />
<br />
'''Camera'''<br />
[RCE][t194][t234] JetPack-5.1.3/l4t-r35.5.0 camera firmware (rce-fw) with debug flag enabled.<br />
https://forums.developer.nvidia.com/t/285027/8<br />
<br />
[Argus] pre-built update to enable infinite timeout property <br />
https://forums.developer.nvidia.com/t/284939/3</div>Daveyhttps://elinux.org/TensorRT/Polygraphy_UsageTensorRT/Polygraphy Usage2024-02-29T10:30:21Z<p>Lynettez: /* Advanced Usage */</p>
<hr />
<div>Polygraphy is an open-source toolkit designed for debugging issues related to TensorRT during its build or runtime phase as well as modifications of the ONNX model. More detailed introduction and usages can be found here: [https://github.com/NVIDIA/TensorRT/tree/main/tools/Polygraphy TensorRT_OSS/Polygraphy]<br />
<br />
This page will summarize the most frequently used command lines during the debugging process.<br />
=== Install & Setup ===<br />
Prerequisite:<br><br />
* CUDA, cuDNN and TensorRT should be installed correctly<br />
* TensorRT-python is must to be installed '''sudo apt install -y python3-libnvinfer python3-libnvinfer-dev'''<br />
* Other dependencies:<br><br />
sudo apt install -y onnx-graphsurgeon python3-pip<br />
pip3 install onnx onnxruntime'''<br />
Quick Install:<br><br />
<pre><br />
python -m pip install colored polygraphy --extra-index-url https://pypi.ngc.nvidia.com<br />
export PATH=${HOME}/.local/bin:$PATH<br />
</pre><br />
Build From Source: <br />
<pre><br />
git clone https://github.com/NVIDIA/TensorRT.git<br />
cd TensorRT/tools/Polygraphy<br />
python setup.py bdist_wheel<br />
pip3 uninstall -y polygraphy<br />
cd .. <br />
python -m pip install Polygraphy/dist/polygraphy-0.47.1-py2.py3-none-any.whl<br />
export PATH=${HOME}/.local/bin:$PATH<br />
</pre><br />
<br><br />
<br />
=== Onnx Model Modification ===<br />
==== Constant-fold ====<br />
<pre><br />
polygraphy surgeon sanitize model.onnx -o model_sim.onnx --fold-constants<br />
</pre><br />
==== Extract a Subgraph ====<br />
<pre><br />
polygraphy surgeon extract model.onnx -o subgraph.onnx \<br />
--inputs x1:[1,3,224,224]:float32 \ # --inputs x1:auto:auto<br />
--outputs add_out:float32 # --outputs add_out:auto<br />
</pre><br />
==== Modify Input shape ====<br />
<pre><br />
polygraphy surgeon sanitize model.onnx -o model_new.onnx --override-input-shapes image:[1,3,224,224] other_input:[10]<br />
</pre><br />
<br><br />
<br />
=== Debugging Accuracy Issue===<br />
==== Using '''debug precision''' Tool ====<br />
If the inference results of TensorRT is unacceptable only when FP16 or INT8 mode is enabled, we can use '''polygraphy debug precision''' to reduce the precision for some layer. By setting higher precision for partial layers, we can locate to a specific layer that producing unexpected outputs in lower precision.<br><br />
<pre><br />
Step 1. Generate input and golden output data from onnxrt:<br />
<br />
$ polygraphy run model.onnx --onnxrt --save-inputs=inputs.json --save-outputs golden_outputs.json<br />
<br />
Step 2. Verify that inference results in higher precision mode is good:<br />
e.g. check the results in FP16 mode comparing with onnxrt outputs<br />
<br />
$ polygraphy run model.onnx --trt --fp16 --load-inputs inputs.json --load-outputs golden_outputs.json --atol 0.5 --rtol 0.3<br />
<br />
Step 3. Reproduce the accuracy issue in lower precision mode:<br />
e.g. check the results in Int8 mode comparing with onnxrt outputs<br />
<br />
$ polygraphy run model.onnx --trt --int8 --calibration-cache calibtable --load-inputs inputs.json --load-outputs golden_outputs.json --atol 0.5 --rtol 0.3<br />
<br />
Step 4. Try to mark some layers running on high precision and check the accuracy with `polygraphy debug precision`<br />
e.g. Set the higher precision to float16 using '''-p''', set the mode to '''bisect''' and the direction to '''forward'''<br />
<br />
$ polygraphy debug precision model.onnx --int8 --fp16 --calibration-cache calibtable \<br />
--mode bisect --dir forward -p float16 \<br />
--check polygraphy run polygraphy_debug.engine --trt --load-inputs inputs.json \<br />
--load-outputs golden_outputs.json --atol 0.5 --rtol 0.3<br />
…<br />
[I] To achieve acceptable accuracy, try running the first 5 layer(s) in higher precision<br />
[I] Finished 4 iteration(s) | Passed: 2/4 | Pass Rate: 50.0%<br />
[I] PASSED | Runtime: 33.551s | Command: …<br />
<br />
Tips: Try different options with --mode bisect/linear --dir forward/reverse if it failed in some cases.<br />
<br />
</pre><br />
<br><br />
<br />
<br />
==== Using '''debug reduce''' Tool ====<br />
If the inference results of TensorRT is unacceptable only when DLA or sparsiry is enabled, we're able to debug such an accuracy issue using '''polygraphy debug reduce''' to find the smallest onnx subgraph that still fails in accuracy checking.<br />
<pre><br />
Step 1. Generate input and golden output data from onnxrt:<br />
<br />
$ polygraphy run spasity_qat_model.onnx --onnxrt --save-inputs=inputs.json --save-outputs golden_outputs.json<br />
<br />
Step 2. Verify that inference results in normal case is good:<br />
e.g. check the GPU Int8 results comparing with onnxrt outputs<br />
<br />
$ polygraphy run model.onnx --trt --int8 --calibration-cache calibtable --load-inputs=inputs.json --load-outputs=golden_outputs.json --atol 0.1 --rtol 0.05<br />
[I] PASSED | Output: 'output' | Difference is within tolerance (rel=0.05, abs=0.1)<br />
[I] PASSED | All outputs matched | Outputs: ['output']<br />
<br />
Step 3. Reproduce the accuracy drop:<br />
e.g. check the sparsity inference results comparing with onnxrt outputs<br />
<br />
$ polygraphy run model.onnx --trt --int8 --calibration-cache calibtable --load-inputs=inputs.json --load-outputs=golden_outputs.json --atol 0.1 --rtol 0.05 --sparse-weights<br />
[E] FAILED | Output: 'output' | Difference exceeds tolerance (rel=0.05, abs=0.1)<br />
<br />
e.g. check the DLA Int8 inference results comparing with onnxrt outputs<br />
<br />
$ polygraphy run model.onnx --trt --int8 --calibration-cache calibtable --load-inputs=inputs.json --load-outputs=golden_outputs.json --atol 0.3 --rtol 0.05 --use-dla --allow-gpu-fallback<br />
[E] Accuracy Summary | trt-runner-N0-12/13/23-05:15:21 vs. trt-runner-N0-12/13/23-05:07:53 | Passed: 0/1 iterations | Pass Rate: 0.0%<br />
<br />
Step 4. Generate layer-wise input and output data:<br />
<br />
$ polygraphy run debug.onnx --onnxrt --save-inputs=inputs.json --save-outputs=golden_lw_results.json \<br />
--onnx-outputs mark all<br />
$ polygraphy data to-input inputs.json golden_lw_results.json -o layerwise_inputs.json<br />
<br />
Step 5. Debug with `reduce` subtool, find the minimum bad model, the last layer of initial_reduced.onnx is the culprit:<br />
<br />
$ polygraphy debug reduce model.onnx --no-reduce-inputs -o initial_reduced.onnx --mode=bisect \<br />
--check polygraphy run polygraphy_debug.onnx --trt --int8 --calibration-cache calibtable \<br />
--load-inputs layerwise_inputs.json --load-outputs golden_lw_results.json --atol 0.3 --rtol 0.05 \<br />
--use-dla --allow-gpu-fallback OR --sparse-weights<br />
<br />
[I] Saving ONNX model to: initial_reduced.onnx<br />
<br />
Tips: Try different options with --mode bisect/linear --no-reduce-inputs/--no-reduce-outputs if it failed in some cases.<br />
<br />
</pre><br />
<br><br />
<br />
==== By Saving and Loading Tactics ====<br />
If the inference results of the same mode in the same precision are unacceptable after upgrading the TensorRT version, we can check if the inference results are good or not with the same tatics.<br><br />
<pre><br />
Step 1. Save the tactics, and output data in the envrienment you used before<br />
<br />
$ polygraphy run model.onnx --trt --fp16 --save-outputs=85_results.json --save-tactics=85_tactics.json --data-loader-script data_loader.py<br />
<br />
Step 2. Load the tactics in the envrienment you used for now, to see if the output data is the consistent.<br />
<br />
$ polygraphy run model.onnx --trt --fp16 --load-outputs=85_results.json --load-tactics=85_tactics.json --data-loader-script data_loader.py<br />
<br />
</pre><br />
<br><br />
Feel free to file bug to NV once you find a bad tactic.<br />
<br />
==== Limitation ====<br />
Can't work properly with the model that includes Q/DQ nodes.<br />
<br />
=== Advanced Usage ===<br />
Generate a netron-viewable network structure:<br><br />
'''polygraphy convert model.onnx --convert-to onnx-like-trt-network -o network.pb'''<br><br />
<br><br />
Convert ONNX models to FP16: --fp-to-fp16, Useful for checking if TRT’s FP16 error is same:<br><br />
'''polygraphy convert model.onnx --fp-to-fp16 -o model_fp16.onnx'''<br><br />
<br><br />
Convert run command to script with --gen/--gen-script:<br><br />
'''polygraphy run model.onnx --trt --fp16 --load-outputs=golden_outputs.json --gen -'''</div>Lynettezhttps://elinux.org/ELC_2024_Technical_ShowcaseELC 2024 Technical Showcase2024-02-21T20:38:37Z<p>Tim Bird: /* Summary Details */ adjust setup time</p>
<hr />
<div>[[image:elc2006-showcase1.jpg|Embedded Linux Conference 2006 Technical Showcase]]<br />
<br />
= Embedded Linux Conference 2024 Technical Showcase =<br />
<br />
We are happy to be planning a technical showcase again this year at Embedded Linux Conference.<br />
ELC 2024 will be held as part of the Embedded Open Source Summit in Seattle, Washington, USA on April 16-18.<br />
<br />
This Wiki page will guide you in giving your demonstration. For conference details, please follow<br />
this link to the overall multi-conference event (of which ELC is a part), is here:<br />
* https://events.linuxfoundation.org/embedded-open-source-summit/<br />
<br />
Here is what the showcase has looked like at previous events:<br />
<br />
[[image:elc2006-showcase2.jpg|Embedded Linux Conference 2006 Technical Showcase]]<br />
[[image:elc2006-showcase3.jpg|Embedded Linux Conference 2006 Technical Showcase]]<br />
[[image:elc-2015-dublin-technical-showcase.jpg|ELCE 2015 Technical Showcase]]<br />
<br />
== Summary Details ==<br />
Application for a showcase slot is due by '''March 15, 2024''', and is done by e-mailing the coordinator.<br /><br />
''Please follow the instructions in the section below "How to Apply"!!''<br />
<br />
PDF files for the posters are due by '''March 20, 2024'''.<br />
<br />
The technical showcase (demo session) will be held in the conference venue on '''Tuesday, April 16''', starting at '''5:00 pm'''<br />
<br />
The demo area will be available for demo setup starting at '' '''4:00 pm''' ''.<br />
<br />
== Objective ==<br />
"Seeing is believing!" Unlike in Desktop or Server applications of Linux, in embedded systems Linux technology is usually unseen. Although it is a challenge, we want to expose Linux software and techniques so that other developers who are interested in this technology can learn, and become potential contributors themselves. We hope that through opening up technical details and projects (in the way of Open Source development), these demonstrations will provide insights that are helpful to developers.<br />
<br />
The technical showcase is a place where you can talk about an open source project, drivers, techniques, or just about anything<br />
else that ELC attendees might be interested in. This is different from a sponsor booth in a number of ways. It is only for 1.5 hours.<br />
It is a single table-top poster, along with an optional demo. It should not be used to promote a commercial product, though it<br />
may include one. Sponsor booths are available for presenting commercial offerings. This is not that.<br />
<br />
== Criteria ==<br />
* No ''purely'' commercial demonstrations.<br />
* The Embedded Linux Conference should not be used for a pure sales pitch.<br />
* You can show off a product, if there are features or aspects of the product you are displaying that are open source.<br />
* Demonstrations should be of software that is available under an open source license.<br />
<br />
== Coordinator ==<br />
Tim Bird<br />
* e-Mail : tim (dot) bird (a) sony (dot) com<br />
* Please replace (a) to "@" and (dot) to "."<br />
<br />
= What will be prepared by the Linux Foundation =<br />
<br />
The Linux Foundation will provide the following '''FREE OF CHARGE''' :<br />
* A Demonstration desk, which is either half of a table or a full table<br /><br />
If you need special arrangements, please contact the coordinator.<br />
[[image:elc2006-showcase-desksample.jpg|Desk sample from ELC 2006]]<br />
* Power supply: possibly shared with another demo on table - assume no more than 2 plugs available, which you may split further if needed.<br />
* Assume the power is less than 750W. If your demonstration will exceed that, please consult the coordinator.<br />
* A large-format printed poster, based on the file you submit.<br />
* Please note that a dedicated (wired) Internet connection will '''NOT''' be prepared. However, wireless Internet may be available via the conference venue wireless network. We cannot, however, guarantee Internet access.<br />
* Logistics support<br />
* Details will be given to the demonstrators<br />
<br />
== Dimension of the desk ==<br />
* Please refer to the attached photo.<br />
<br />
== Poster ==<br />
All demonstrators are requested to prepare a poster to explain the technical outline of the demonstration. You can download the template from this page.<br />
The Linux Foundation will print them out on large size paper (22 x 28" format). The document should be sent edited, removing the sample page, and sent '''IN PDF FORMAT''' to the coordinator by '''Tuesday February 9th'''.<br />
<br />
Here are some poster format details:<br />
* Size: 28in W x 22in H, printed one-sided<br />
* File type: PDF, include .3 cm (3mm) bleed & crop marks<br />
<br />
* Technical Specs:<br />
** CMYK color (PMS for exact color matching)<br />
** Ideal bitmap resolution is 100-120 DPI in final size<br />
** Individual files sizes smaller than 2GB<br />
<br />
Here are some sample presentation files for Poster creation:<br />
<br />
* [[Media:ELC_PosterForm.odp|ELC_PosterForm.odp]]<br />
* [[Media:ELC_PosterForm.ppt.zip|ELC_PosterForm.ppt.zip]]<br />
<br />
'''Caution''': Do not change the paper size. It is intentionally set to a big size.<br />
<br />
To help you know what kind of posters we usually get, see [[Media:Elce-2012-showcase-posters.pdf|ELCE 2012 showcase posters]].<br />
<br />
Note that by submitting a poster, you authorize the coordinator and the Linux Foundation to publish the PDF on eLinux.org.<br />
<br />
== Some tips ==<br />
The demo consists of a poster (printed by the Linux Foundation), with<br />
a few sentences talking about your project, tool, technology or distribution<br />
and a table top where you can place anything from:<br />
<br />
# nothing at all, just have a person sitting there to talk to people about what's on the poster, or ...<br />
# something on a laptop - like a program running or a even a static chart showing some result<br />
# something running on a board or a device<br />
# something on an actual CE product<br />
<br />
You can also put some flyers there for people to grab, if you'd like.<br />
<br />
If you can put charts and graphs on the poster, that's nice<br />
but it is NOT required. Neither the poster nor the<br />
hardware (if any) needs to be elaborate or require lots of setup.<br />
One year I showed up with a camcorder and just talked to<br />
people about its bootup time (which I had worked on).<br />
<br />
If you are a presenter, the demo session is a good chance to talk to people<br />
one-on-one about your session topic. This gives you more time for interactive<br />
Q&A, and a chance to show something hands-on, if that applies to your subject.<br />
<br />
= How to apply =<br />
# Send an e-mail to the coordinator with the following information:<br />
## '''The contact person'''<br />
## '''The company name or the project name''', and<br />
## '''An outline of the demonstration'''.<br />
# Send your application for the demo session no later than '''March 15th'''.<br />
# The coordinator will acknowledge your application by e-mail.<br />
# Prepare the poster and send the file (in PDF format) to the demonstration coordinator by '''March 20th'''. It will be printed out by the conference organizers on big size paper.<br />
# Prepare the demonstration equipment<br />
## You can bring the equipment yourself, or ship it.<br />
## If you do not have a consignee which will be convenient for you, ask Tim for an address you can ship something to separately.<br />
<br />
= FAQ =<br />
* '''Q''': Is this opportunity limited to Linux Foundation members?'''<br />
* '''A''': No. You do not have to be a forum member to have a demo at the conference. However, each demo should be associated with a paid conference attendee.<br />
* '''Q''': Is the demonstrator required to make a presentation at the conference?'''<br />
* '''A''': No, this is not required. However, demos related to presentations are a good way to extend the reach of your session, if you have a presentation at the event.<br />
* '''Q''': Should I assign some dedicated staff to carry on the demonstration?'''<br />
* '''A''': No, this is not necessary. The time slot for the technical showcase is separate from the other technical sessions. So there will be no conflict between the demo session and the other technical sessions.<br />
* '''Q''': Is there any fee to demo something in this session?'''<br />
* '''A''': No, the demo session is completely free.<br />
* '''Q''': Can a non-attendee help present the demo?<br />
* '''A''': If you have someone coming who will ONLY run or assist with your demo, and not attend any sessions, then that person may be admitted for free, for just the demo session (and setup and take down). However, each demo should be associated with at least one registered attendee. Contact the coordinator if you are in this situation.<br />
* '''Q''': Can a sponsor have a showcase entry?<br />
* '''A''': Yes. Even if a sponsoring organization has a booth, they may want to do a demo of something they are working on, and extend their outreach to attendees with another live demo during the showcase.<br />
<br />
[[Category:ELC]]<br />
[[Category:2024]]<br />
[[Category:Events]]</div>Tim Birdhttps://elinux.org/ECE434_Project_-_IOT_Entry_Way_CameraECE434 Project - IOT Entry Way Camera2024-02-08T05:33:20Z<p>Senevirc: </p>
<hr />
<div>[[Category:ECE497 |PI]]<br />
{{YoderHead}}<br />
<br />
Team members: [[user:Senevirc| Rhian Seneviratne]] [[user:gawronja| Joey Gawron]]<br />
<br />
== Grading Template ==<br />
I'm using the following template to grade. Each slot is 10 points.<br />
0 = Missing, 5=OK, 10=Wow!<br />
<br />
<pre style="color:red"><br />
Add Extras<br />
<br />
09 Executive Summary<br />
09 Packaging<br />
09 Installation Instructions <br />
09 User Instructions<br />
09 Highlights<br />
09 Theory of Operation<br />
09 Work Breakdown<br />
09 Future Work/Conclusions<br />
09 Hackster.io<br />
09 Demo/Poster<br />
00 Not Late<br />
<br />
Score: 90/100<br />
</pre><br />
<br />
== Executive Summary ==<br />
<br />
*[https://www.hackster.io/seneviratner02/entry-way-camera-72b13d/ Hackster.io] link<br />
<br />
This project will be an IOT entry way camera that will monitor who enters or leaves a room.<br />
The hardware setup consists of: <br />
1. BeaglePlay<br />
2. USB Webcam<br />
3. Ethernet Cable (Not required but recommended)<br />
<br />
Using OpenCV, SMPT messaging, and FFmpeg we have successfully made a system that can monitor who is in a room. The BeaglePlay is set up to continually upload to a Twitch livestream with the camera feed using FFmpeg. During the script, every two minutes (customizable), a frame will be captured and will run through some image processing to be fed to the OpenCV HOG person detector. If a person is detected in the image, using SMPT, a message will be sent to the designated phone number that there may be an individual in the room. It will also email a picture of the room at the time a person was detected.<br />
<br />
Hardware Connections<br />
[[File:BeagleConnections.jpg|600px]]<br />
<br />
<br />
Camera Setup<br />
[[File:Camera.jpg|600px]]<br />
<br />
<br />
== Packaging ==<br />
<br />
There is no complex hardware here at all, only the BeaglePlay and a compatible USB webcam.<br />
<br />
== Installation Instructions ==<br />
<br />
* If the BeaglePlay is being used, download an image to flash to the eMMC from [https://www.beagleboard.org/distros/ here]. A convenient and brief [https://www.dummies.com/article/technology/computers/hardware/beaglebone/how-to-flash-the-beagleboards-onboard-emmc-144951/ guide] to flashing the eMMC. <br />
* The [https://github.com/rhit-gawronja/ECE434FinalProject/ repository] containing all the code necessary. <br />
* install.sh ensures that pip and opencv is installed, the other libraries are standard. systemd.sh enables the entrycam.service systemd service so that the program can always run on boot. Ensure that the paths are correct for the cloned distribution of the code. run.sh will run the program manually (entrycam.py). <br />
* The BeaglePlay needs to be connected to the network in some way, we went with an ethernet cable for simplicity. <br />
<br />
<br />
== User Instructions ==<br />
<br />
Once all the instructions from above are followed, the entrycam.service should be enabled as a systemd service to run at boot. It runs<br />
entrycam.py which is the main script to run. <br />
<br />
<br />
There are two major modifications that needs to be made to config.py: '''The stream key for the Twitch livestream must be changed to your own personal key''' in order for it to be correctly accessed. It can be found under settings in the creator dashboard in your twitch account. It is possible to use the current stream key, but it is only linked to one account. If using this, the livestream can be found by searching for ''apartment4022'' on twitch. The phone number associated must also be changed to a personal number to receive the alert. <br />
<br />
<br />
After this is done and the systemd service is activated, as long as the Beagle is connected to internet (we chose through ethernet), <br />
the programs should run when the Beagle boots up. It make take a minute or so for the stream to appear. It lags a fair amount, but given<br />
the maximum power we could achieve with the BeaglePlay, the stream should run at 15-20 FPS. This would be suitable enough for an individual<br />
to check if there is a person in the area. <br />
<br />
<br />
== Highlights ==<br />
<br />
The main highlights of this project lie within the connectivity of the system. Firstly, the ability to check the stream on Twitch at <br />
anytime. Below is a picture of what our stream looked like in testing:<br />
<br />
[[File:StreamImage.PNG|600px]]<br />
<br />
<br />
Another key factor is the image detection, below is an example of the HOG detector capturing an individual and drawing a box around them.<br />
<br />
[[File:HogDetect.png|600px]]<br />
<br />
<br />
The usage of messaging was a key factor to letting the owner know whether someone was in the room or not. Examples of messaging alert<br />
and email alert:<br />
<br />
[[File:emailSnip.png|600px]]<br />
<br />
<br />
== Theory of Operation ==<br />
<br />
A high level overview of the software: <br />
<br />
entrycam.py (Main program) ------> ffmpeg for streaming<br />
|-------------------------------> imageProcessing.py -----> messaging.py<br />
<br />
<br />
Breakdown of entrycam.py:<br />
* Use opencv to open USB webcam for video footage<br />
* Declare ffmpeg to encode the video to the correct parameters to stream to Twitch<br />
* Use a subprocess to run the ffmpeg command, and stream a buffer of frames at a time<br />
* Use a method in imageProcessing.py to check time since last image analysis<br />
* If it is time to check again, analyze image in imageProcessing.py<br />
<br />
Breakdown of imageProcessing.py: <br />
* Measures time since last run to determine if processing needs to be run again<br />
* For processing frame, resize the image and run the image through the HOG person detector<br />
* If a person was found, send a text using messaging.py<br />
<br />
Breakdown of messaging.py:<br />
* Holds variables for sender and receiver<br />
* Use SMTP library to send a message over text and email<br />
<br />
<br />
== Work Breakdown ==<br />
<br />
Rhian worked on image processing, utilized HOG detector and found ideal parameters for processing image Joey worked on messaging, and updated BeaglePlay to correct settings. Together we worked on using ffmpeg to stream video to Twitch. <br />
<br />
== Future Work/Conclusions ==<br />
<br />
One thing we would have really liked to get working was Tensorflow. We spent a lot of time diving deep into it to get it working, mainly because the object detection using Keras and pretrained models like YOLO are significantly more accurate and efficient than OpenCV's image detector. Tensorflow Lite was a very appealing option based on our restrictions for available computing power, but was annoying to get working because of how it was designed. Tensorflow Lite by default used a wheel file designed for the Raspberry Pi, and there needed to be modifications for it to work for the BeagleBoard devices. The AI-64 board was able to install tensorflow and even import some of the packages and train the model. However, as soon as it was time to predict based on the new picture the program would break. The AI-64 board also ran extremely hot. For time's sake, we decided to use the BeaglePlay and OpenCV rather than continuing tensorflow. <br />
<br />
Overall, this project was enjoyable and could be useful depending on the situation. The ffmpeg was interesting to work with because the parameters for the frame had to be just right otherwise the stream would be completely glitched. <br />
<br />
<br />
{{YoderFoot}}</div>Senevirchttps://elinux.org/ECE434_Project_LayerWatchECE434 Project LayerWatch2024-02-07T03:41:07Z<p>Jailen: /* Executive Summary */</p>
<hr />
<div>[[Category:ECE497 |PT]]<br />
[[Category:ECE434Winter2023 |PT]]<br />
{{YoderHead}}<br />
<br />
Team members: [[user:Jailen| Jailen Hobbs] [user:Sean| Sean Hyacinthe]<br />
<br />
== Grading Template ==<br />
I'm using the following template to grade. Each slot is 10 points.<br />
0 = Missing, 5=OK, 10=Wow!<br />
<br />
<pre style="color:red"><br />
Add Extras<br />
<br />
09 Executive Summary<br />
09 Packaging<br />
09 Installation Instructions <br />
09 User Instructions<br />
09 Highlights<br />
09 Theory of Operation<br />
09 Work Breakdown<br />
09 Future Work/Conclusions<br />
09 Hackster.io<br />
09 Demo/Poster<br />
00 Not Late<br />
<br />
Score: 94/100<br />
</pre><br />
<br />
== Executive Summary ==<br />
[[File:Layerwatch2.jpg]]<br><br />
LayerWatch in Action!<br />
<br />
The goal of the project was to develop a method to monitor 3D prints remotely. While also giving users the ability to stop prints while they are in progress. Currently, our project has complete functionality locally. You can gather images form the usb camera and upload them to the web server. Thus, giving you the abilty to turn off the printer or let the print resume. The LCD display connected to the BeagleBone also shows the web address for users to connect to monitor their setup. All the features we wanted are present with the exception of hosting the server on the campus Wi-Fi. We would like to have the web server hosted onto Wi-Fi to allow for user access on campus to watch prints anywhere in the buildings or through a vpn. Overall, LayerWatch is a great way to monitor your prints and keep your work stations safe from goopy nozzles.<br />
<br />
== Packaging ==<br />
<br />
For the LayerWatch we have used 3 three hardware components a LCD1602A, PowerSwitch Tail 2, and usb camera. <br><br />
For the PowerSwitch Tail2 follow this guide in the PNP Transistor Configuration. https://www.electronics-tutorials.ws/blog/relay-switch-circuit.html <br><br />
LCD1602A datasheet provided: https://www.sparkfun.com/datasheets/LCD/ADM1602K-NSW-FBS-3.3v.pdf <br><br />
Logitech Camera USB plug into USB of Beagle<br />
<br />
== Installation Instructions ==<br />
<br />
Git Link: https://github.com/hyacinsm/LayerWatch.git<br><br />
Download the repo on your beagle: git clone [github](git@github.com:hyacinsm/LayerWatch.git)<br />
Read the entire README.md<br />
<br />
<pre style="color:red"><br />
1. cd ~/LayerWatch<br />
2. sudo ./setup.sh<br />
3. sudo ./install.sh<br />
4. sudo ./LayerWatch.sh<br />
</pre><br />
<br />
'''Hardware purchases:<br>'''<br />
PowerSwitch Tail2 - https://www.adafruit.com/product/268<br><br />
<br />
LCD1602A - https://www.adafruit.com/product/181?gad_source=1&gclid=CjwKCAiA29auBhBxEiwAnKcSqs3DXMpFcsnJFSK6I2YUZZxlZerCTk3uuGesu9YE2hoEuPlMbzlCmxoCqsUQAvD_BwE<br><br />
<br />
USB Camera - https://www.logitech.com/en-us/products/webcams/c922-pro-stream-webcam.960-001087.html<br />
<br />
== User Instructions ==<br />
Once everything is installed. Power cycle the LCD display to ensure the setup is complete due to wiring being in 4-bit mode.<br />
Then sudo reboot your BeagleBone allow it to reconnect your device. Then check the LCD for the web address to go to. Once on the server check periodically on your print to ensure it is running correctly. If not, click stop print. <br><br />
[[File:status_photo.png]]<br><br />
In this image the stop print button was clicked and the print was cancelled.<br />
<br />
== Highlights ==<br />
<br />
* Developed driver for LCD16x2 (also scales to 40x2 LCD)<br />
* Developed a usb web cam driver that works on any usb web cam<br />
* Created a driver for the PowerSwitch Tail 2<br />
* Designed a modern looking UI for the flask web server<br />
* System starts up on boot up, using systemd<br />
<br />
Hackster.io <br />
[https://www.hackster.io/jailen/layerwatch-139a25 LayerWatch] <br><br />
[https://drive.google.com/file/d/1_KXh0uRqw8YAWBpBvL0yzgUjpRo9Gdby/view?usp=sharing LayerWatch Demo]</br><br />
<br />
== Theory of Operation ==<br />
[[File:Layerwatch.jpg]]<br />
<br />
This is the flow of work for the project<br />
<br>'''Directory Layout'''</br><br />
<br />
<pre style="color:black"><br />
LayerWatch/<br />
|-- relay/ (stores relay example code)<br />
|-- lcd16x2/ (stores lcd16x2 example code)<br />
|--- website/<br />
│ |--- static/ (stores images and css file for server)<br />
│ │ |--- images/ (stores images taken by web cam)<br />
│ |--- templates/ (stores html code for flask server)<br />
|--- webcam/ (stores web cam example code)<br />
</pre><br />
<br />
<br />
'''Summary of Main Files'''<br />
<br>app.py</br><br />
<pre style="color:black"><br />
Interfaces the flask web server and Beagle Bone Board. Also controls all peripheral devices (camera, relay, lcd)<br />
</pre><br />
<br>usbcam.py</br><br />
<pre style="color:black"><br />
Created supporting library/class to interface with USB camera<br />
</pre><br />
<br>relay.py</br><br />
<pre style="color:black"><br />
Created supporting library/class to control with PowerSwitch Tail 2 Relay<br />
</pre><br />
<br>lcd16x2.py</br><br />
<pre style="color:black"><br />
Created supporting library/class to display streaming text on 16x2 LCD Module (1602A)<br />
</pre><br />
<br>lcd16x2.py</br><br />
<pre style="color:black"><br />
Created supporting library/class to display streaming text on 16x2 LCD Module (1602A)<br />
</pre><br />
<br />
<br>index.html</br><br />
<pre style="color:black"><br />
The structure of the web server displayed for the user<br />
</pre><br />
<br />
<br>styles.css</br><br />
<pre style="color:black"><br />
Handles the graphics and modern visuals of the website<br />
</pre><br />
<br />
<br>app.js</br><br />
<pre style="color:black"><br />
Handles animation of the hamburger bar when the website is being displayed as mobile media<br />
</pre><br />
<br />
== Work Breakdown ==<br />
'''Distribution'''<br />
The project was split into half. Sean created the flask server and was in charge of using the camera to upload the images to the server to be seen. Jailen was in charge of creating the circuit for relay to work and be able to turn it on/off. He also created a driver for the lcd16x2 due to issues with using adafruit libraries.<br />
<br />
== Future Work ==<br />
<br />
'''Modularity'''<br />
Currently, the website and hardware are only capable of supporting one printer. For the website, allowing the user to add and remove monitor jobs would be a great addition. Considering the audience that would find this project most attractive would be those with print farms or generally multiple printers.<br />
On the hardware side, we want to create a many-to-one relationship between the printers and the monitoring webcam. In order to do this while maintaining high-quality photos, we need to create a rig for a camera to move between each printer to take photos. Alternatively, you could use a USB extender and attach it to the Beagle Bone Board, but then you would need a camera per printer.<br />
<br />
'''External Access/Authentication'''<br />
Since the aim of this project is to be able to monitor prints currently in progress, we want to make the Flask server, hosted on the Beagle, accessible externally. However, due to security concerns and time constraints, we opted not to do this in our first iteration of the project. The next step in this area is to develop an authentication process to log into the website. After adding login, there would be enough security for us to be comfortable making the server externally accessible.<br />
<br />
'''Video Streaming'''<br />
Lastly, adding a mode to live stream a print in progress would be beneficial. Some people may prefer this over periodic pictures, and we think this would be a worthwhile addition to the project if we had more time.<br />
<br />
== Conclusions ==<br />
<br />
Overall, the project was a great learning experience. We developed software at all levels, including firmware and web development. In addition, we created a script to facilitate quick startup times for the project and used systems to service our Flask web server when the Beagle Board is powered on.<br />
<br />
{{YoderHead}}</div>Jailenhttps://elinux.org/ECE497/ECE434_Project_MediaPlayerECE497/ECE434 Project MediaPlayer2024-02-06T20:29:55Z<p>Clarkr30: /* Executive Summary */</p>
<hr />
<div>[[Category:ECE497 |PT]]<br />
[[Category:ECE434Winter2023 |PT]]<br />
{{YoderHead}}<br />
<br />
Team members: [[user:Leeni|Noah Lee]], [[user:Renc|Clark Ren]]<br />
<br />
Project Title: '''MP3 Bone'''<br />
<br />
== Grading Template ==<br />
I'm using the following template to grade. Each slot is 10 points.<br />
0 = Missing, 5=OK, 10=Wow!<br />
<br />
<pre style="color:red"><br />
Add Extras<br />
<br />
00 Executive Summary<br />
00 Packaging<br />
00 Installation Instructions <br />
00 User Instructions<br />
00 Highlights<br />
00 Theory of Operation<br />
00 Work Breakdown<br />
00 Future Work/Conclusions<br />
00 Hackster.io<br />
00 Demo/Poster<br />
00 Not Late<br />
<br />
Score: 00/100<br />
</pre><br />
<br />
== Executive Summary ==<br />
This project aims to create a music player within pygame that will show mp3 metadata on the screen. Media controls are controlled using hardware interfaces like buttons, and can also be controlled using the optional flask webserver module. <br />
[[File:Mp3bonedemo.png|thumb|The mp3 bone in use]]<br />
Implemented Features:<br />
* Systemctl service to run on boot<br />
* Media controls through pushbuttons<br />
* Volume control through rotary encoder<br />
* MP3 playback<br />
* Playback metadata shown on display<br />
* Support for multiple mp3 file in a playlist<br />
* MP3 file upload and playback control on Flask webserver (separate module)<br />
<br />
The MP3 Bone is a simple but very much functional mp3 player. Once the user has uploaded any number of .mp3 files, the mp3 bone can cycle through all of these songs while providing all of the playback controls expected from a media player. <br />
'''LINKS'''<br />
'''GITHUB LINK:''' https://github.com/Navelwriter/ECE434-Music<br />
'''HACKSTER.IO LINK''' https://www.hackster.io/clarkr30/ece434-mp3-bone-788b78<br />
<br />
== Development Timeline ==<br />
02/08: A song plays from the USB Driver<br />
<br />
02/11: Simple data like title on screen<br />
<br />
02/12: Added Flask functionality, later scrapped due to version conflicts<br />
<br />
02/12: Supports Playlist of multiple songs<br />
<br />
02/12: Media Controls using pushbutton<br />
<br />
02/12: Volume Control using Rotary Encoder<br />
<br />
02/14: Launch on boot through systemd<br />
<br />
02/17: Added more info onto screen like song progress bar<br />
<br />
02/17: Fixed bugs<br />
<br />
02/19: Created install script<br />
<br />
02/19: Reintroduced Flask socket alongside systemctl player, added file transfer through flask server. <br />
<br />
<br />
== Packaging ==<br />
We decided to go for an intentionally crude packaging to emphasize the theme of "childlike simplicity" that we have while labeling all of the features such as button. <br />
Holes are cutout for display and rotary encoder wiring. Buttons are soldered onto a perfboard and connected to the bone. <br />
[[File:ECE434-Final.png|thumb|right|Packaging for MP3 Bone]]<br />
== Installation Instructions ==<br />
<br />
Install Directions:<br />
<br />
* Most of the required hardware is included in the ECE434 kit.<br />
* One additional audio adapter is needed and can be found at https://www.amazon.com/dp/B00IRVQ0F8.<br />
* Connect the TFT display as following: P9_21 -> MISO, P9_16 -> LED, P9_22 -> SCK, P9_18 -> MOSI, P9_19 -> D/C, P9_20 -> RESET, P9_17 -> CS, P9_2 -> GND, P9_4 -> VCC.<br />
* Connect the pushbuttons as the following: P8_16 -> Quit, P8_15 -> Next Song, P9_14 -> Play/Pause, P9_15 -> Previous.<br />
* Connect the rotary encoder as the following: P8_11 -> A, P8_12 -> B, GND -> GND.<br />
* Connect the audio device to the green aux port on the audio adapter.<br />
* Install the dependancies using '''sudo ./installDep.sh'''.<br />
* Add the player as a systemd service to launch on boot using '''sudo ./install.sh'''<br />
* Otherwise run '''sudo ./runner.sh''' to start through cli<br />
<br />
Flask Exclusive Directions:<br />
[[File:Mp3boneweb.png|thumb|right|Demo of the flask webserver]]<br />
* Rather than running runner.sh, run '''sudo ./server_runner.sh''' to run both the server and client in a tmux session.<br />
* The webpage at http://192.168.7.2:8081/ has a button to select a file, and to upload it. You can only upload .mp3 files, and you can refresh the playlist on the beaglebone by pressing ```refresh playlist```<br />
<br />
<br />
<br />
== User Instructions ==<br />
<br />
The display shows the following information:<br />
* The current song and its place in the playlist<br />
* The progress of the current song as a bar<br />
* The current timestamp and the song length<br />
* The current volume<br />
<br />
The volume starts at 70%.<br />
* To increase the volume, turn the rotary encoder clockwise<br />
* To decrease the volume, turn the rotary encoder counterclockwise<br />
<br />
The media controls behave like standard media controls<br />
* The previous button restarts the current song from the beginning if the current time is more than 3 seconds. Otherwise, the player plays the previous song in the playlist.<br />
* The pause/play button pauses or resumes the current song.<br />
* The next button plays the next song in the playlist<br />
* The quit button causes the player to exit. To relaunch the player, it must either be restarted manually or the entire system must be reset.<br />
<br />
Flask Exclusive Features:<br />
* All of the above features<br />
* Can also control all aspects of device in http://192.168.7.2:8081/<br />
* Can add .mp3 files through the web server<br />
<br />
== Highlights ==<br />
<br />
This project can:<br />
* Play your mp3 files<br />
* Display the status of the player<br />
* Use multimedia controls<br />
* Upload songs through Flask<br />
* Adjust volume through a knob<br />
And more!<br />
<br />
[https://youtu.be/o9yQ4n1NNyQ Demo Youtube Link]<br />
<br />
== Theory of Operation ==<br />
<br />
Give a high level overview of the structure of your software. Are you using GStreamer? Show a diagram of the pipeline. Are you running multiple tasks? Show what they do and how they interact.<br />
Launching on Boot:<br />
* For the primary program (ran through ./runner.sh), we have a systemctl service that is added to be launched on boot. Initially we had an issue where the process would immediately get killed, but this was due to the program ran in the service not having the correct context to use the display. The solution was having the service launch a separate script that calls our main player program.<br />
* Music playback and display were done through pygame. Specifically, msuic playback was done through the pygame.mixer.music functions, and the playlist was a simple array holding song file names to play. <br />
* Display features such as progress bar, current time and total length used mixer.music.getpos() for current time and mixer.music.getLength() for total length, and these two values were used to create the bar.<br />
* Rotary encoder was read using eQEP and buttons were read using gpiod.<br />
<br />
Flask server and client:<br />
* Unable to run this as a server due to limitations of flask that limited socketio servers specifically from running in background, functionally identical otherwise other than flask feature. <br />
* When ran through the '''./server_runner.sh''' script, opens a tmux session running the server first, and the client in another window after a delay. <br />
* Server runs a socketio server through flask and opens up a port, waiting for a connection from client. The client then connects using socketio.<br />
* Server runs the flask server, then uses socketio to get commands from the webpage and sends that command to the client, where it parses it and performs the action. <br />
* With a corresponding button for uploading files, we use @app.route('/upload', methods=['POST']) to request the file and save it into the music folder we want. <br />
<br />
<br />
== Work Breakdown ==<br />
<br />
Major Tasks: <br />
<br />
* '''SPI LCD Screen Output:''' Setup and arrange outputs onto display: Noah Lee<br />
<br />
* '''pygame.mixer playback:''' Initial working code for music playback: Noah Lee<br />
<br />
* '''Playlist Support:''' Treat and iterate through multiple songs in folder as array: Noah Lee<br />
<br />
* '''Audio Visualizer (NEVER IMPLEMENTED):''' Heavy investigation onto feasibility of audio visualizer, dropped due to requiring whole refactoring of code, compatibility issues, and missing functionalities (audio progress): Noah Lee<br />
<br />
* '''Flask Support (Separate Implementation):''' One of the first things implemented was a separate flask server that connected to the main program through a network socket and controlled playback. Dropped due to python dependency chain issues with Clark, inconsistent behavior, and an inability to run on boot due to flask services not being functional in background. Reimplemented near end, do to being unable to run flask without an active shell, the compromise of having two separate programs, one as a systemctl service and the flask client-server was decided: Noah Lee<br />
<br />
* '''Hardware Controls:''' Interfacing with buttons + dial for playback controls: Clark Ren<br />
<br />
* '''Systemctl service:''' Setup systemctl service to launch program from boot: Clark Ren<br />
<br />
* '''Install Script:''' Setup eqep, install systemctl, launch program script: Clark Ren<br />
<br />
* '''Packaging:''' The ingenious yet simplistic packaging was crafted by the artisan Clark Ren<br />
<br />
<br />
== Future Work ==<br />
<br />
Audio Visualizer support would be a huge bonus but there are a few roadblocks to go through before implementation. <br />
<br />
It's one thing to support audio visualization directly from an I2C or adc input, and gathering audio data in a currently streaming audio source. <br />
<br />
Different ways of Implementing:<br />
<br />
'''Pygame.mixer.sound():''' This was attempted<br />
* mixer.sound() does not support .mp3 files<br />
* It does not support the .getpos() function or any analogues that would return the current timestamp of the sound being played<br />
* mixer.sound seems to be more oriented towards a plethora of game audio samples to play back at a given time<br />
<br />
'''pyaudio():''' This was also attempted<br />
* Overall this is a much more in depth library than pygame.mixer<br />
* pyaudio does not support .mp3 files, though this is not the reason it was dropped<br />
* Once we had audio buffers outputting, it was clear that the bone could not support such large arrays and hanged after a few iterations, though this could definitely be mitigated through changing parameters.<br />
<br />
'''librosa():''' <br />
* Not supported natively with aarm64<br />
* attempts to get working faced python version dependency chains, maybe something like conda would work better<br />
<br />
Overall: pyaudio() seems to be the best suited, but would require a complete rewrite to accommodate for the different library used. <br />
<br />
== Conclusions ==<br />
<br />
Overall we believe we did a great job, though a bit simplistic, and have hit all of the basic functionalities we would desire. We did not anticipate packaging to be such a bottleneck and determined the best way forward was to take an "artistic" approach. Flask functionality was a big disappointment, there was functionality with playback controls working but lack of background flask servers as well as catastrophic python package version conflicts really hindered our ability to work on it together and add more features. We did end up including the work we did on flask through a separate launcher script with the added feature of uploading files to the appropriate folder. Working with different python libraries to interface with the music file information as well as interfacing with these controls using our hardware inputs is the core of our project and works flawlessly in practice. <br />
<br />
{{YoderFoot}}</div>Leenihttps://elinux.org/ECE434_Project_Arcade_MachineECE434 Project Arcade Machine2024-02-06T20:26:51Z<p>1100992288: </p>
<hr />
<div>[[Category:ECE497 |PT]]<br />
[[Category:ECE434Winter2324 |PA]]<br />
{{YoderHead}}<br />
<br />
Team members: [[user:1100992288|Jack Aldworth]], Theo Mitz<br />
== Grading Template ==<br />
I'm using the following template to grade. Each slot is 10 points.<br />
0 = Missing, 5=OK, 10=Wow!<br />
<br />
<pre style="color:red"><br />
Add Extras<br />
<br />
10 Executive Summary<br />
10 Packaging<br />
10 Installation Instructions <br />
10 User Instructions<br />
10 Highlights<br />
10 Theory of Operation<br />
10 Work Breakdown<br />
10 Future Work/Conclusions<br />
10 Hackster.io<br />
10 Demo/Poster<br />
00 Not Late<br />
<br />
Score: 100/100<br />
</pre><br />
<br />
== Executive Summary ==<br />
[[File:Cover.jpg|300px|https://github.com/geaz/simplyRetro-D8?tab=readme-ov-file]]<br />
<br />
Our goal was to create a desktop arcade machine that allowed people to play numerous arcade games all on one device. This device needed to be able to emulate the original games near there original speed while still being light enough that it could be moved from location to location.<br />
<br />
Our arcade machine currently allows for you to play many different classic arcade games using the MAME2003Plus emulator, with the ability to install many more emulators as well. It's also entirely self contained, so the device is relatively portable.<br />
<br />
Note that you will have to use an external USB soundcard to have working audio with the BeagleBone AI-64, as our hardware is not compatible with audio over displayport. In addition, if you are connecting the BeagleBone to an HDMI display, you will need to use an ACTIVE Mini Displayport adapter, otherwise the display out will not work.<br />
<br />
Our as of this moment our arcade machine is semi-functional. While it does provide it's core functions of both allowing for the play of retro games and being relatively portable it's till missing a number of desired functions and is quite rough around the edges.<br />
<br />
[https://www.hackster.io/jack-aldworth/desktop-retro-arcade-machine-6d39a3 Link to Hackster post]<br />
== Packaging ==<br />
We 3D printed the case for this project. If you would like the CAD files to print one for yourself, they can be found [https://github.com/geaz/simplyRetro-D8/tree/master/cad, here]<br />
<br />
== Installation Instructions ==<br />
<br />
Give step by step instructions on how to install your project.<br />
<br />
1. Flash the BB-AI 64's EMMC with the latest Debian image with a desktop environment using a micro SD card. For the current image as of writing, see [https://www.beagleboard.org/distros/bbai64-11-8-2023-10-07-10gb-emmc-xfce-flasher]<br />
<br />
2. Open a terminal, and install the following programs and their dependencies using "sudo apt install": retroarch and libretro-* You may want to also consider using a snap, ppa, flatpak, or building from source, as the debian package is quite outdated, and has several broken features, such as missing icons and not being able to download content from the internet.<br />
<br />
3. after installing retroarch and the libretro dependencies, you will want to pick out and download an emulation core from the Github repository linked here: [https://github.com/christianhaitian/retroarch-cores/tree/master/aarch64] For aracde emulation, we recommend MAME2003Plus, but you can choose any other emulators that you may like.<br />
<br />
4. Open Retroarch (either by using the GUI or typing "retroarch" into the terminal, and find where to place the core by navigating to "Settings->Path Options->Core Directory. Unzip the ".so" emulator core file that you downloaded, and place it in that directory.<br />
<br />
5. To make RetroArch automatically run on startup, you can use debian's autostart function. You can get help on how to set up autostart [https://faq.urveboard.com/books/operating-systems-os/page/debian-11-autostart here].<br />
<br />
6. Now you are ready to add your own ROMS and load them in retroarch - we will not be providing a source for these, however MAME2003+ ROMsets can easily be found with a quick google search. You will want to find a non-merged romset to keep things simple. Loading the ROMs is as simple as placing the files in a directory of your choice, and using "Load Content" in RetroArch to navigate to where they are stored and load them.<br />
<br />
Materials:<br />
* [https://www.amazon.com/Buttons-EG-STARTS-Joystick-Raspberry/dp/B01M2X88QP/ref=sr_1_7?crid=35MGFONJH6LNT&keywords=Arcade+Controller+Set&qid=1708046261&sprefix=arcade+controller+set+%2Caps%2C136&sr=8-7 Arcade Controller Set]<br />
* [https://www.amazon.com/VSDISPLAY-1024X768-HJ080IA-01E-Controller-Raspberry/dp/B07V7GGWMM/ref=sr_1_3?crid=CHGX2CGXPLHF&keywords=8+inch+HDMI+IPS+display&qid=1708045261&sprefix=8+inch+hdmi+ips+display%2Caps%2C146&sr=8-3&ufe=app_do%3Aamzn1.fos.006c50ae-5d4c-4777-9bc0-4513d670b6bc 8 inch HDMI IPS display]<br />
* [https://www.aliexpress.us/item/2251832266174146.html?spm=a2g0s.9042311.0.0.1df04c4dcQesbB&gatewayAdapt=deu2usa4itemAdapt PAM8043]<br />
* 2 x [https://www.amazon.com/Adafruit-Mini-Metal-Speaker-Wires/dp/B00N41FXC2/ref=sr_1_4?crid=3G2JD5X72GDQM&keywords=1+inch+speaker&qid=1708045394&sprefix=1+inch+speake%2Caps%2C111&sr=8-4 Speakers]<br />
* [https://www.amazon.com/Kework-2-pack-Stereo-Headphone-Single/dp/B07D1Z3SJS/ref=sr_1_5?crid=2PF8SNS6GOCUX&keywords=Audio%2BJack&qid=1708045475&refinements=p_n_feature_sixteen_browse-bin%3A119746478011&rnid=119746477011&s=aht&sprefix=audio%2Bjack%2Caps%2C108&sr=1-5&th=1 Audio Jack (male)]<br />
* [https://www.amazon.com/PowerBear-Braided-Connectors-Compatible-Monitor/dp/B08J8BJQLB/ref=sr_1_3?crid=Z6IB71R7XCBO&keywords=HDMI+cable&qid=1708045550&refinements=p_n_feature_sixteen_browse-bin%3A119746478011&rnid=119746477011&s=tv&sprefix=hdmi+cab%2Celectronics%2C114&sr=1-3 HDMI Cable (Small)]<br />
* [https://www.amazon.com/YCS-Basics-Black-Printer-Scanner/dp/B00B5HS7TI/ref=sr_1_5?crid=3R6UU9Z12A11A&keywords=usb%2Bto%2Busb%2BB&qid=1708045592&refinements=p_n_feature_sixteen_browse-bin%3A119746478011&rnid=119746477011&s=pc&sprefix=usb%2Bto%2Busb%2Bb%2Celectronics%2C131&sr=1-5&th=1 USB A to USB B type cable]<br />
* [https://www.amazon.com/Small-Extra-Round-Rubber-Bumpers/dp/B01AU0ISKI/ref=sr_1_8?crid=1B2N0WOABJ6GC&keywords=M3x8mm+rubber+feet&qid=1708045696&sprefix=m3x8mm+rubber+feet%2Caps%2C112&sr=8-8 Rubber Feet]<br />
* [https://www.amazon.com/Uxcell-a15121600ux0534-Stainless-Phillips-Machine/dp/B01BBOZGKC/ref=sr_1_4?keywords=M3x8mm+screws&qid=1708045634&sr=8-4 M3x8mm screws]<br />
* 2-sided tape<br />
* electrical tape<br />
== User Instructions ==<br />
<br />
Once everything is installed the Retroarch GUI should appear on boot. As mentioned in the instructions, you will need to source your own ROMs to play games - we will not be providing instructions on how to do this, but they are extremely easy to find. Once you've donwloaded ROMS, just use "Load Core -> MAME2003Plus" and "Load Content -> navigate to your ROM". You will likely have to bind your own controls if you are not using a keyboard - this will have to be done in both RetroArch and the MAME Emulator (the settings menu where you bind controls in MAME can be accessed by pressing "Tab" while running the emulator)<br />
<br />
Once everything is installed, how do you use the program? Give details here, so if you have a long user manual, link to it here.<br />
<br />
== Highlights ==<br />
<br />
Here is where you brag about what your project can do.<br />
<br />
Include a [http://www.youtube.com/ YouTube] demo the audio description.<br />
<br />
== Theory of Operation ==<br />
<br />
This project runs an emulation frontend called RetroArch, which as a piece of software that can emulate multiple video gaming systems. We have installed the "MAME2003 Plus" emulator, which allows us to emulate many kinds of old arcade machines. To play games with these emulators, you must download ROM files for each game, which include all of the code, files, etc. required for a game to run. To play a game, we launch RetroArch, load the emulator, and select a ROM that we would like to play.<br />
<br />
== Work Breakdown ==<br />
<br />
* Install RetroArch with MAME2003 Plus on Bone : Theo : Complete<br />
* Test Simple games over HDMI : Theo : Complete<br />
* Construct Case : Jack : Complete<br />
* Test Screen/Remote : Jack : Complete<br />
* Add additional Games : Theo + Jack : Complete<br />
* Install GUI to allow for quick switching of Games : Theo : Complete<br />
* Clean up build : Jack : Complete<br />
<br />
== Future Work ==<br />
<br />
Other then adding sound and getting a more recent and stable build of RetroArch working, we would like to add a bunch more games to the system. Since RetroArch allows the use of a ton of different emulators it would be cool to have it simulate some retro consoles such as the NES or the Sega Genesis.<br />
<br />
== Conclusions ==<br />
<br />
Give some concluding thoughts about the project. Suggest some future additions that could make it even more interesting.<br />
<br />
{{YoderFoot}}</div>1100992288https://elinux.org/ECE434_Project_-_Sound_ProjectECE434 Project - Sound Project2024-02-06T19:39:09Z<p>Manthelt: </p>
<hr />
<div>[[Category:ECE497 |PS]]<br />
[[Category:ECE434Winter2324 |PS]]<br />
{{YoderHead}}<br />
<br />
Team members: [[user:Krakorlr|Larissa Krakora]], [[user:Collinse|Ash Collins]], [[user:Manthelt|Logan Manthey]]<br />
<br />
== Grading Template ==<br />
I'm using the following template to grade. Each slot is 10 points.<br />
0 = Missing, 5=OK, 10=Wow!<br />
<br />
<pre style="color:red"><br />
Add Extras<br />
<br />
09 Executive Summary<br />
09 Packaging<br />
09 Installation Instructions <br />
09 User Instructions<br />
09 Highlights<br />
09 Theory of Operation<br />
09 Work Breakdown<br />
09 Future Work/Conclusions<br />
09 Hackster.io<br />
09 Demo/Poster<br />
00 Not Late<br />
<br />
Score: 90/100<br />
</pre><br />
<br />
== Executive Summary ==<br />
<br />
[[File:overall.png]]<br />
<br />
This project is centered around making a digital synth using a custom designed keyboard cape. The inspiration for this project came from the Stylophone, an analog synth which used a stylus keyboard. Our project currently has capability to play songs, navigate songs, take and play user input, record and play back user input, and has two octaves for that "manual mode". We also have a simple UI via Flask for the controls, and the display of the title of the current song. We wanted to add audio visualization on an LCD, but we were barely even able to get anything to display on the LCD. We gave that up as we sunk too many hours into it and would rather add new features. Our project has many different capabilities related to sound.<br />
<br />
== Packaging ==<br />
* Most of our product is standard wires, pots, switch buttons, etc. except for our custom "Keyboard Cape"<br />
* Our cape acts as a voltage divider, allowing us to read in analog values of voltage to differentiate between notes<br />
Hackster IO Link: https://www.hackster.io/larissa3/sound-project-77327a<br />
<br />
== Installation Instructions ==<br />
<br />
- Read-only GitHub: https://github.com/manthelt/ECE434FinalProject<br />
<br />
<br />
1. Clone the repo<br />
<br />
2. Run sudo ./install.sh<br />
<br />
3. Run sudo ./setup.sh<br />
<br />
4. Move .asoundrc to your home directory<br />
<br />
5. Use aplay -l to find out which card your USB Audio device is setup as<br />
<br />
6. Change <br />
pcm "hw:0,0" -> pcm "hw:[card #],0" <br />
and<br />
card 0 -> card [card #]<br />
in ~/.asoundrc<br />
<br />
<br />
* Custom PCB schematic in 'Schematic and PCB'<br />
* USB Surround Sound Adapter: https://sabrent.com/products/usb-sbcv<br />
<br />
== User Instructions ==<br />
<br />
1. Run ./recordServerNew.py<br />
<br />
2. Visit https://localhost:8081<br />
<br />
== Highlights ==<br />
<br />
* Play a variety of songs<br />
* Backward, pause/play, and skip functionalities<br />
* "Manual mode" that allows the user to play their own sequence of notes<br />
- Record a sequence of notes and play them back<br />
<br />
== Video Demo ==<br />
https://youtu.be/Gq4ZqvmgP8Y?si=p0Maj8yswmgwlebh<br />
<br />
== Theory of Operation ==<br />
<br />
* Input from buttons > navigate through songs > display via Flask<br />
* Input from cape while in manual mode > play various notes<br />
* Manual mode is navigated to the same way other songs are > input only taken in during manual mode > other songs do not play during manual mode<br />
<br />
== Hardware ==<br />
This section describes the hardware portion of the project and which parts and designs were used.<br />
<br />
<br />
'''BOM'''<br />
<br />
* 17 1206 Resistor of Varying Sizes<br />
* [Resistor List for Note Values](#resistor-list-for-note-values)<br />
* 1 Potentiometer<br />
* 2 2 Pin Male Connectors<br />
* 1 1 Pin Male Connector <br />
*Note for the connectors I used large ones that I cut down to size*<br />
<br />
<br />
'''Keyboard Section'''<br />
<br />
This section describes the keyboard section of the hardware and it's theory of operation <br />
<br />
[[File:RenderV4.png]]<br />
<br />
In short this keyboard acts as a form of potentiometer where connecting the 1.8 volt line to the different nets allows a different value to be read by the analog input as there is a different resistor connected to each one of the note nets.<br />
<br />
<br />
''Schematic and PCB''<br />
<br />
The keyboard cape was designed using KiCAD EDA software. KiCAD is an open source easy to use EDA software that allowed us to quickly design and then print out a PCB prototype on campus using the CNC mill. If we were going to redesign this for real manufacture we would add more headers to make it more stable. We would also add a spot for a pull down resistor to the board itself.<br />
<br />
<br />
[[File:Sch.png]]<br />
<br />
<br />
[[File:PCBView.png]]<br />
<br />
<br />
[[File:Printed.png]]<br />
<br />
<br />
<br />
''Resistor List for Note Values''<br />
<br />
These values were chosen to allow for a somewhat even distribution of values which will translate to a even distribution of values. We then added a pull down resistor to allow for a even larger distributing of notes. <br />
<br />
```<br />
Note Ohm<br />
0 47000<br />
1 33000<br />
2 22000<br />
3 15000<br />
4 10000<br />
5 6800<br />
6 4700<br />
7 3300<br />
8 2200<br />
9 1500<br />
10 1000<br />
11 680<br />
12 470<br />
13 330<br />
14 220<br />
15 150<br />
16 100<br />
17 0<br />
```<br />
<br />
<br />
'''Pot Section'''<br />
<br />
In addition to the keyboard acting as a potentiometer there is also a normal potentiometer that can act as a volume control or however you would like to program it. That potentiometer is located here.<br />
<br />
[[File:SecondaryPot.png]]<br />
<br />
<br />
== Software ==<br />
<br />
''Reading in the values''<br />
<br />
* Analog input via /sys/bus/iio<br />
* Button input via gpio<br />
<br />
<br />
''Creating Sound''<br />
<br />
* While in manual mode, user hits the keys with connected wire<br />
* Software reads in analog voltage input via /sys/bus/iio<br />
* That analog voltage value corresponds to a frequency that is then played<br />
<br />
<br />
''Storing Recorded Sound''<br />
<br />
* User hits keys<br />
* Notes are read in via /sys/bus/iio<br />
* Durations are determined based on the time the user started playing the note and when they stopped<br />
<br />
<br />
''Changing Octaves''<br />
<br />
* Take in input from potentiometer<br />
* Use that value as a boolean to determine offset for array index of frequencies<br />
<br />
<br />
''Switching Songs''<br />
<br />
* Buttons on Flask navigate to new page to control navigation through songs<br />
<br />
== Work Breakdown ==<br />
<br />
* PCB Design and Solder<br />
Logan<br />
<br />
* Sound Generation and USB Audio<br />
Logan, Ash, Larissa<br />
<br />
* LCD Visualization (not working - dropped)<br />
Ash, Larissa<br />
<br />
* Flask<br />
Ash, Larissa<br />
<br />
* Documentation<br />
Logan, Ash, Larissa<br />
<br />
== Future Work ==<br />
<br />
Future Additions<br />
* More features on the Flask App<br />
* More Synth Options and possbile Digital Signal Processing<br />
* Possible Second Pot Features<br />
* Pitch Bend<br />
* Wave Adjustment (Example: Sin Wave to Sawtooth to Square)<br />
* Being able to play over background songs and beats<br />
* This would let you solo with the keyboard over tunes like free bird<br />
* Adding a loop for recording playback would be able to allow for more intense soloing<br />
* LCD Screen<br />
* We attempted to get the LCD screen to work with the bone but this proved to be very<br />
difficult especially with a UI if we had LCD working with it we could make it into a<br />
smaller self contained package<br />
* Hardware<br />
* Adding buttons to the cape<br />
* Making the cape more stable on the bone<br />
* Printing the PCB at a PCB House<br />
<br />
== Conclusions ==<br />
<br />
Overall our group thinks our project was a success. Our approach of making something simple and<br />
adding features to it proved to be very useful and allowed us to pivot as needed. This also<br />
allowed us to always have something to demo at every stage of our project. We also thought<br />
the interactive nature of the project made this a really fun project to demo.<br />
<br />
Above in future work shows a few different features that we would like to add to the project.<br />
<br />
{{YoderFoot}}</div>Krakorlrhttps://elinux.org/ECE434_Project_-_Water_Sim_ToyECE434 Project - Water Sim Toy2024-01-23T21:29:18Z<p>Yoder: /* Executive Summary */</p>
<hr />
<div>[[Category:ECE497 |PT]]<br />
[[Category:ECE434Winter2023 |PT]]<br />
{{YoderHead}}<br />
<br />
Team members: [[user:Sappon|Owen Sapp]], [[user:Bejlovba|Bryce Bejlovec]]<br />
<br />
== Grading Template ==<br />
I'm using the following template to grade. Each slot is 10 points.<br />
0 = Missing, 5=OK, 10=Wow!<br />
<br />
<pre style="color:red"><br />
Add Extras<br />
<br />
09 Executive Summary<br />
09 Packaging<br />
09 Installation Instructions <br />
09 User Instructions<br />
09 Highlights<br />
09 Theory of Operation<br />
09 Work Breakdown<br />
09 Future Work/Conclusions<br />
09 Hackster.io<br />
09 Demo/Poster<br />
00 Not Late<br />
<br />
Score: 90/100<br />
</pre><br />
<br />
== Executive Summary ==<br />
<br />
[[File:Splash.jpg|thumb|splash project]]<br />
<br />
This project aims to create a fluid-like simulation that is displayed on an LCD screen and interacted with through an accelerometer. <br />
<br />
'''Currently Working Features:'''<br />
<br />
Fluid Simulation<br />
<br />
SPI LCD Screen Output<br />
<br />
Accelerometer Input<br />
<br />
Touch Screen Input<br />
<br />
<br />
This project creates an example application for a touch-screen input with the ILI9341 SPI LCD and a gyroscope. The application is reminiscent of a water simulation that is able to be played with to create ripples and depth. <br />
<br />
<br />
'''GITHUB LINK:''' https://github.com/rhit-sappon/EmbeddedLinuxFinalBejSapp<br />
<br />
'''HACKSTER LINK:''' https://www.hackster.io/rhit-sappon/splash-water-simulation-toy-fc002c<br />
<br />
== Development Timeline ==<br />
<br />
Fluid-Like Python Simulaiton: 2/2/24<br />
<br />
Interface with SPI LCD Screen: 2/2/24<br />
<br />
Accelerometer Input: 2/2/24<br />
<br />
Rewrite in C: 2/4/24<br />
<br />
Touch Screen Input: 2/15/24<br />
<br />
SystemD Daemon: 2/15/24<br />
<br />
== Packaging ==<br />
[[File:Splash pack1.JPG|thumb|splash packaging 1]]<br />
[[File:Splash pack2.JPG|thumb|splash packaging 2]]<br />
<br />
The packaging for this project consists of cutouts from foam-board to create a box around the Beagle Bone and a half-length breadboard. As visible in the images, the cutouts can be made with tabs to assist in positioning and securing the box in place. <br />
<br />
The LCD screen is positioned in a cutout to only let the screen through, and leave the PCB behind the foam board in the box. Screws are then tightened into the foam board to attach the LCD to the top of the box.<br />
<br />
== Installation Instructions ==<br />
<br />
Github Link: https://github.com/rhit-sappon/EmbeddedLinuxFinalBejSapp/settings<br />
<br />
Fritzing Wiring: <br />
<br />
LCD:<br />
<br />
* Lite <--> P9_16<br />
* Reset <--> P9_25<br />
* DC <--> P9_27<br />
* CS <--> P9_28<br />
* MISO <--> P9_29<br />
* MOSI <--> P9_30<br />
* CLK <--> P9_31<br />
<br />
Touch:<br />
<br />
* T_IRQ <--> P9_23<br />
* T_DO <--> P9_18<br />
* T_DIN <--> P9_21<br />
* T_CS <--> P9_17<br />
* T_CLK <--> P9_22<br />
<br />
Gyro:<br />
<br />
* CS <--> VCC (3.3V)<br />
* SDO <--> Ground<br />
* SDA <--> P9_20<br />
* SCL <--> P9_19<br />
<br />
<br />
'''Installation:'''<br />
<br />
Clone the git repo to a directory of your choosing. Then cd into the directory EmbeddedLinuxFinalBejSapp, and run ./install.sh This will clone the device trees, make, install, and set up uEnv.txt to properly initialize the devices. <br />
<br />
Note on systemd:<br />
<br />
We were unable to get systemd running splash on startup. This is due to two things, either the .system instructions execute out of sequence breaking requirements, or occasionally the splash command runs, creating a looping function that halts the bootup of the rest of Linux.<br />
<br />
== User Instructions ==<br />
<br />
When the software has been installed and the wiring completed correctly, you can start the program by running first setupgyro.sh in the /init subfolder and then running the splash executable in the /splash subfolder. <br />
<br />
This setupgyro only needs to be run once, and it is inconsistent on necessity between devices. Some test devices automatically detected i2c device address 0x53 (gyroscope), while others did not. Similarly, this changed per reboot, and as such this is not within the scope of a setup file. <br />
<br />
Running splash will cause a blue color to display on the LCD. <br />
<br />
To interact with the software, use either the stylus to input touch to the LCD causing a small ripple on the touched location, or use the gyroscope. The gyroscope will change the "depth" of the pool depending on tilt, and sudden movements will cause the simulator to have large "waves" appear in the direction of sudden movement.<br />
<br />
== Highlights ==<br />
<br />
Demo Video:<br />
https://www.youtube.com/watch?v=LNkLKK6UXgA<br />
<br />
Touch Screen Input - Ripples that track the touched location.<br />
<br />
Gyroscope Input - Controls depth, creates ripples with enough impact.<br />
<br />
== Theory of Operation ==<br />
<br />
Water Ripple Generation and Propagation: <br />
By taking in data from the gyroscope and touch screen in order to determine where the initial starting ripples are generated, forces can be added to an 80x60 array of X and Y axis motion vectors. This array is then iterated using a modified version of the [https://web.archive.org/web/20160116150939/http://freespace.virgin.net/hugo.elias/graphics/x_water.htm Hugo Elias algorithm]. As would be the case with real water, a visible ripple is only generated when a substantial amount of force is applied, so testing the delta of previous gyroscope input to the current reading against a threshold, the specific side of the motion vector array is given a line of forces based on the magnitude of the force past the threshold. As for the touch screen input, the ADS7846 driver relays information about the pressure being applied to the screen and that data is used to set the value at the location of the stylus in the motion vector array.<br />
<br />
<br />
Reading Touch Input:<br />
In order to utilize the XPT2046/ADS7846 SPI touch controller, a device tree overlay was needed that allowed the kernel driver for this device to be accessed. After compiling and installing the device tree overlay, the Linux input library was used to read the events of the device from <code>/dev/input/event1</code><br />
<br />
<br />
Modifying the Framebuffer:<br />
Based on the [https://gist.github.com/FredEckert/3425429 work by FredEckert on GitHub], we modify the framebuffer directly via mmap(). Each frame is stored locally with 24bit color but, because of the SPI display only supporting 16bit color, 5 bits for red and blue, 6 for green, we are limited to shift the bits of each channel accordingly.<br />
<br />
== Work Breakdown ==<br />
<br />
Major Tasks:<br />
<br />
Fluid Simulation - Set up and initialize a fluid-like simulation with example input and output functions.<br />
<br />
SPI LCD Screen Output - Modify the simulator to output on the ILI9341 SPI-LCD Screen. <br />
<br />
Accelerometer Input - Modify the simulator to take in input signals from a ADXL345 Accelerometer.<br />
<br />
Touch Screen Input - Modify the simulator and LCD connections to interface with the LCD's touch screen. <br />
<br />
Setup and Install - Creation of an installation script using RegEx and shell scripts.<br />
<br />
== Conclusions ==<br />
<br />
We believe that this project was successful in implementing a touch-screen application that is usable on the BeagleBoard. This project implements the touch screen feature of the SPI LCD screen and uses the input location to modify the state of a fluid-like simulation. In this process, we created a functional simulator using C, adapted it to output pixel values to the frame buffer, and used a Hugo-Alias algorithm to create ripples around the touch input. <br />
<br />
== Future Work ==<br />
<br />
Some potential additional work could be adding custom user input color schemes to utilize. This project went with blue to mimic water, but it is theoretically possible to modify the color as the user desires, possibly in real time. <br />
Rotary encoders or buttons could be used to set the RGB channel values. <br />
<br />
Another potential additional feature could be an efficient upscaling algorithm. Currently, we are transferring an 80x60 model to an 240x320 display.</div>Sapponhttps://elinux.org/R-Car/Boards/S4SK/Xen-Hypervisor/SDK-v3.16.2R-Car/Boards/S4SK/Xen-Hypervisor/SDK-v3.16.22024-01-10T08:52:36Z<p>Y.H.: /* Manual steps */ Fix branch name</p>
<hr />
<div>{{Template:R-Car-S4-Navbox}}<br />
{{TOC right}}<br />
[[Category:R-Car]]<br />
[[Category:R-Car Gen4]]<br />
<br />
== Software revisions ==<br />
<br />
{| class="wikitable"<br />
|-<br />
! Software !! Revision<br />
|-<br />
| R-Car SDK || v3.16.2<br />
|-<br />
| R-Car S4 Xen package || version 1.2.1<br />
|-<br />
| R-Car S4 Linux Yocto package || Based on version 5.24.2<br />
|-<br />
| Yocto Project || [http://git.yoctoproject.org/cgit/cgit.cgi/poky/tag/?id=yocto-3.1.16 3.1.16]<br />
|- <br />
| aarch64-poky-linux-gcc (GCC) || 9.3<br />
|- <br />
| Xen Hypervisor || 4.17-unstable<br />
|-<br />
| Dom0 (Linux kernel) || 5.10.41/rcar-5.1.7.rc12<br />
|- <br />
| DomD (Linux kernel) || v5.10.41/rcar-5.1.7.rc11.2-xt<br />
|- <br />
| DomU (Linux kernel) || v5.10.41/rcar-5.1.7.rc11.2-xt<br />
|-<br />
| Userland 64/32bit || 64<br />
|- <br />
| U-Boot || 2020.10<br />
|- <br />
|}<br />
<br />
== Host PC ==<br />
Ubuntu 20.04 LTS (64bit) is recommended as OS. 32bit version is not supported. <br/><br />
<br />
== How to build ==<br />
See also : https://github.com/renesas-rcar/meta-xt-prod-devel-rcar-gen4/blob/s4sk-mp-1.0/doc/building.md<br />
=== Installation of required tools and libraries ===<br />
Ubuntu is used as Linux Host PC since Yocto Project Quick Start specifies Ubuntu as one of the distributions. You need to install the required packages as follows.<br />
: <syntaxhighlight lang="bash"><br />
sudo apt-get install -y gawk wget diffstat texinfo chrpath socat \<br />
libsdl1.2-dev python-crypto checkpolicy python3-git python3-github \<br />
bzr pigz m4 lftp openjdk-8-jdk git-core gnupg flex \<br />
bison gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib \<br />
libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z-dev \<br />
ccache libgl1-mesa-dev libcap-ng-dev libxml2-utils xsltproc unzip \<br />
python-clang-6.0 gcc-7 g++-7 bc python3-pyelftools python3-pip \<br />
python3-crypto libpixman-1-dev libcap-dev device-tree-compiler libffi-dev \<br />
python-dev libgit2-dev ninja-build curl<br />
</syntaxhighlight><br />
<br />
<!--<br />
=== Install repo ===<br />
: <syntaxhighlight lang="bash"><br />
mkdir ~/bin<br />
PATH=~/bin:$PATH<br />
curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo<br />
chmod a+x ~/bin/repo<br />
</syntaxhighlight><br />
<br />
=== Confirm Python3 default version ===<br />
:<syntaxhighlight lang="bash"><br />
python3 --version<br />
Python 3.8.X<br />
</syntaxhighlight><br />
It is required to install Python version 3.7 or later.<br />
If your Python version is 3.6 or lower, please install the newer one as the below:<br />
:<syntaxhighlight lang="bash"><br />
sudo apt-get update<br />
sudo apt-get install -y python3.8 python3.8-distutils<br />
sudo update-alternatives --install /usr/bin/python3 python3 /usr/bin/python3.6 1<br />
sudo update-alternatives --install /usr/bin/python3 python3 /usr/bin/python3.8 2<br />
# Please Select Python3.8<br />
sudo update-alternatives --config python3<br />
</syntaxhighlight><br />
--><br />
=== Using build script ===<br />
# Build script(build.sh)<br />
#: <syntaxhighlight lang="bash"><br />
#!/bin/bash<br />
<br />
# Install moulin<br />
pip3 install --upgrade pip<br />
export PATH="$PATH:${HOME}/.local/bin"<br />
pip3 install --user git+https://github.com/xen-troops/moulin<br />
<br />
# build<br />
mkdir build-xen<br />
cd build-xen<br />
export WORK_XEN=`pwd`<br />
curl -O https://raw.githubusercontent.com/renesas-rcar/meta-xt-prod-devel-rcar-gen4/s4sk-1.2.1/prod-devel-rcar-s4sk.yaml<br />
moulin prod-devel-rcar-s4sk.yaml --ENABLE_DOMU=yes<br />
ninja<br />
</syntaxhighlight><br />
# build<br />
#: <syntaxhighlight lang="bash"><br />
./build.sh<br />
</syntaxhighlight><br />
<br />
=== Manual steps ===<br />
# Install moulin<br />
#: <syntaxhighlight lang="bash"><br />
pip3 install --upgrade pip<br />
export PATH="$PATH:${HOME}/.local/bin"<br />
pip3 install --user git+https://github.com/xen-troops/moulin<br />
</syntaxhighlight><br />
# Build<br />
#:<syntaxhighlight lang="bash"><br />
mkdir build-xen<br />
cd build-xen<br />
export WORK_XEN=`pwd`<br />
curl -O https://raw.githubusercontent.com/renesas-rcar/meta-xt-prod-devel-rcar-gen4/s4sk-1.2.1/prod-devel-rcar-s4sk.yaml<br />
moulin prod-devel-rcar-s4sk.yaml --ENABLE_DOMU=yes<br />
ninja<br />
</syntaxhighlight><br />
# Building image can take up to a few hours depending on your host system performance.<br>After the build has been completed successfully, you should see the output similar to:<br />
#: <syntaxhighlight lang="bash"><br />
NOTE: Tasks Summary: Attempted 2734 tasks of which 1752 didn't need to be rerun and all succeeded.<br />
</syntaxhighlight><br />
<br />
=== Generated images ===<br />
<!-- Waiting for update SDK v3.16.1<br />
:Dom0: [https://hydrochoerus.com/rcar/s4sk-xen/build-xen/yocto/build-dom0/tmp/deploy/images/generic-armv8-xt/ ${WORK_XEN}/yocto/build-dom0/tmp/deploy/images/generic-armv8-xt/] <br><br />
:DomD: [https://hydrochoerus.com/rcar/s4sk-xen/build-xen/yocto/build-domd/tmp/deploy/images/s4sk/ ${WORK_XEN}/yocto/build-domd/tmp/deploy/images/s4sk/] <br><br />
:DomU: [https://hydrochoerus.com/rcar/s4sk-xen/build-xen/yocto/build-domu/tmp/deploy/images/s4sk/ ${WORK_XEN}/yocto/build-domu/tmp/deploy/images/s4sk/] <br><br />
--><br />
:Dom0: ${WORK_XEN}/yocto/build-dom0/tmp/deploy/images/generic-armv8-xt/ <br><br />
:DomD: ${WORK_XEN}/yocto/build-domd/tmp/deploy/images/s4sk/ <br><br />
:DomU: ${WORK_XEN}/yocto/build-domu/tmp/deploy/images/s4sk/ <br><br />
:{| class="wikitable"<br />
|-<br />
! Domain<br />
! Expected output<br />
! Description<br />
|-<br />
| rowspan="2" | Dom0<br />
| Image<br />
| Dom0 Linux kernel image<br />
|-<br />
| uInitramfs<br />
| Dom0 ramfs((Included DomD/U Images and device trees))<br />
|-<br />
| rowspan="6" | DomD<br />
| rcar-image-minimal-s4sk.tar.bz2<br />
| DomD rootfs<br />
|-<br />
| r8a779f0-s4sk -xen.dtb<br />
| Xen device trees<br />
|-<br />
| xenpolicy-s4sk<br>xen-uImage<br />
| Xen image<br />
|-<br />
| u-boot-elf-s4sk.srec<br />
| U-Boot<br />
|-<br />
| bl31-s4sk.srec<br />
| Trusted Firmware-A (BL31)<br />
|-<br />
| tee-s4sk.srec<br />
| OP-TEE OS<br />
|-<br />
| rowspan="1" | DomU<br />
| rcar-image-minimal-s4sk.tar.bz2<br />
| DomU rootfs<br />
|-<br />
|}<br />
<br />
: Sample built Image is below.<br><br />
: https://hydrochoerus.com/rcar/s4sk-xen/build-xen/yocto/<br />
<br />
== How to flash/update the loader ==<br />
: <syntaxhighlight lang="bash"><br />
$ ls -1 ${WORK_XEN}/yocto/build-domd/tmp/deploy/images/s4sk/*.srec<br />
yocto/build-domd/tmp/deploy/images/s4sk/bl31-s4sk.srec<br />
yocto/build-domd/tmp/deploy/images/s4sk/tee-s4sk.srec<br />
yocto/build-domd/tmp/deploy/images/s4sk/u-boot-elf-s4sk-v2020.10+gitAUTOINC+616f05eb5a-r0.srec<br />
yocto/build-domd/tmp/deploy/images/s4sk/u-boot-elf-s4sk.srec<br />
yocto/build-domd/tmp/deploy/images/s4sk/u-boot-elf.srec<br />
</syntaxhighlight><br />
: Write the generated bl31-s4sk.srec, tee-s4sk.srec and u-boot-elf-s4sk.srec binaries to flash<br />
: See : [[R-Car/Boards/S4SK#How_to_flash.2Fupdate_the_loader]]<br />
<br />
<!--<br />
=== Loading kernel and rootfs via SD card ===<br />
<br />
This section describes steps that are necessary for preparing and booting from SD card.<br />
--><br />
<br />
== How to boot ==<br />
=== Micro SD card(32GB or more) boot ===<br />
<span style="color:#ff0000">'''WARNING!''' These steps will erase the SD card completely. In short, all files will be lost.</span><br/><br />
<br />
Follow these steps on the host machine:<br><br />
NOTE: probably you need to be a root user, hence use "sudo". And "mmcblk0" should be adapted to your environment (eg., sdb or sdc).<br />
# Delete all the partitions in the SD card. Below is an example for one partition, repeat the process for all the remaining partitions in the SD card if exists.<br />
#: <syntaxhighlight lang="bash"><br />
Ex)<br />
$ fdisk /dev/mmcblk0<br />
Command (m for help): d<br />
Partition number (2-4, default 1): 1 (number of the first partion)<br />
Partition 1 has been deleted.<br />
</syntaxhighlight><br />
# Divide the SD card into three partions and set ID=83(Linux) for each. <br />
#: <syntaxhighlight lang="bash"><br />
Ex)<br />
$ fdisk /dev/mmcblk0<br />
Command (m for help): n<br />
Partition type<br />
p primary (0 primary, 0 extended, 4 free)<br />
e extended (container for logical partitions)<br />
Select (default p): p<br />
Partition number (1-4, default 1): 1 (number of the first partion)<br />
First sector (2048-62333951, default 2048): <Hit Enter key><br />
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-62333951, default 62333951): +9G (Size of the<br />
first partion)<br />
Created a new partition 1 of type 'Linux' and of size 9 GiB.<br />
Partition #1 contains a ext4 signature.<br />
Do you want to remove the signature? [Y]es/[N]o: n<br />
Command (m for help): t<br />
Selected partition 1<br />
Hex code (type L to list all codes): 83<br />
Changed type of partition 'Linux' to 'Linux'.<br />
</syntaxhighlight><br />
#: Repeat the above commands for the second and third partitions by changing the partition number to 2 and 3.<br />
# Format each partition to ext4<br />
#: <syntaxhighlight lang="bash"><br />
$ mkfs.ext4 /dev/mmcblk0p1<br />
$ mkfs.ext4 /dev/mmcblk0p2<br />
$ mkfs.ext4 /dev/mmcblk0p3<br />
</syntaxhighlight><br />
# Write images to partitions of SD card<br />
#: <syntaxhighlight lang="bash"><br />
$ mount /dev/mmcblk0p1 /mnt<br />
$ cp ${WORK_XEN}/yocto/build-dom0/tmp/deploy/images/generic-armv8-xt/Image /mnt<br />
$ cp ${WORK_XEN}/yocto/build-dom0/tmp/deploy/images/generic-armv8-xt/uInitramfs /mnt<br />
$ cp ${WORK_XEN}/yocto/build-domd/tmp/deploy/images/s4sk/r8a779f0-s4sk-xen.dtb /mnt<br />
$ cp ${WORK_XEN}/yocto/build-domd/tmp/deploy/images/s4sk/xen-uImage /mnt/<br />
$ cp ${WORK_XEN}/yocto/build-domd/tmp/deploy/images/s4sk/xenpolicy-s4sk /mnt<br />
$ sync<br />
$ umount /mnt<br />
$ mount /dev/mmcblk0p2 /mnt<br />
$ tar jxf ${WORK_XEN}/yocto/build-domd/tmp/deploy/images/s4sk/rcar-image-minimal-s4sk.tar.bz -C /mnt<br />
$ sync<br />
$ umount /mnt<br />
$ mount /dev/mmcblk0p3 /mnt<br />
$ tar jxf ${WORK_XEN}/yocto/build-domu/tmp/deploy/images/s4sk/rcar-image-minimal-s4sk.tar.bz2 -C /mnt<br />
$ sync<br />
$ umount /mnt<br />
</syntaxhighlight><br />
# Set U-Boot environment variables<br />
#: <syntaxhighlight lang="text"><br />
setenv initrd_high 0xffffffffffffffff<br />
setenv bootargs<br />
setenv bootcmd 'run bootcmd_sdcard'<br />
setenv bootcmd_sdcard 'run sdcard_xen_load; run sdcard_dtb_load; run sdcard_kernel_load; run sdcard_xenpolicy_load; run sdcard_initramfs_load; bootm 0x48080000 0x84000000 0x48000000'<br />
setenv sdcard_dtb_load 'ext4load mmc 0:1 0x48000000 r8a779f0-s4sk-xen.dtb; fdt addr 0x48000000; fdt resize; fdt mknode / boot_dev; fdt set /boot_dev device mmcblk0'<br />
setenv sdcard_initramfs_load 'ext4load mmc 0:1 0x84000000 uInitramfs'<br />
setenv sdcard_kernel_load 'ext4load mmc 0:1 0x7a000000 Image'<br />
setenv sdcard_xen_load 'ext4load mmc 0:1 0x48080000 xen-uImage'<br />
setenv sdcard_xenpolicy_load 'ext4load mmc 0:1 0x7c000000 xenpolicy-s4sk'<br />
run bootcmd <br />
</syntaxhighlight><br />
<br />
==== Tips ====<br />
Writing an image to Micro SD using the dd command<br><br />
This frees you from confusing Micro SD partitioning, formatting, and other procedures.<br />
# build (See [[R-Car/Boards/S4SK/Xen-Hypervisor#How_to_build]])<br />
#: <syntaxhighlight lang="text"><br />
./build.sh<br />
</syntaxhighlight><br />
#: or<br />
#: <syntaxhighlight lang="text"><br />
ninja<br />
</syntaxhighlight><br />
# Generated the "full.img" file<br />
#: <syntaxhighlight lang="text"><br />
ninja image-full<br />
</syntaxhighlight><br />
#: <syntaxhighlight lang="text"><br />
ls<br />
build.ninja full.img prod-devel-rcar-s4sk.yaml yocto<br />
</syntaxhighlight><br />
# Writing the "full.imge" to Micro SD<br />
#: <syntaxhighlight lang="text"><br />
dd if=full.img of=/dev/mmcblk0 conv=sparse<br />
</syntaxhighlight><br />
# Boot<br />
#: <syntaxhighlight lang="text"><br />
setenv bootargs<br />
setenv bootcmd 'ext4load mmc 0:1 0x83000000 boot-emmc.uImage; source 0x83000000'<br />
run bootcmd<br />
</syntaxhighlight><br />
<br />
=== NFS boot ===<br />
# Install some packages for NFS boot on Host PC (See [[R-Car/Boards/Yocto-Gen3/v5.9.0#Loading_kernel_via_TFTP_and_rootfs_via_NFS]])<br />
# Copy and decompress the some files and rootfs on Host PC<br />
#: <syntaxhighlight lang="bash"><br />
Ex)<br />
$ mkdir -p /srv/tftp/s4/rootfs_xen/dom0 /srv/tftp/s4/rootfs_xen/domd /srv/tftp/s4/rootfs_xen/domu<br />
$ export NFS_ROOT=/srv/tftp/s4/rootfs_xen<br />
$ cp ${WORK_XEN}/yocto/build-dom0/tmp/deploy/images/generic-armv8-xt/Image ${NFS_ROOT}/dom0<br />
$ cp ${WORK_XEN}/yocto/build-dom0/tmp/deploy/images/generic-armv8-xt/uInitramfs ${NFS_ROOT}/dom0<br />
$ cp ${WORK_XEN}/yocto/build-domd/tmp/deploy/images/s4sk/r8a779f0-s4sk-xen.dtb ${NFS_ROOT}/dom0<br />
$ cp ${WORK_XEN}/yocto/build-domd/tmp/deploy/images/s4sk/xen-uImage ${NFS_ROOT}/dom0<br />
$ cp ${WORK_XEN}/yocto/build-domd/tmp/deploy/images/s4sk/xenpolicy-s4sk ${NFS_ROOT}/dom0<br />
$ tar jxf ${WORK_XEN}/yocto/build-domd/tmp/deploy/images/s4sk/rcar-image-minimal-s4sk.tar.bz -C ${NFS_ROOT}/domd<br />
$ tar jxf ${WORK_XEN}/yocto/build-domu/tmp/deploy/images/s4sk/rcar-image-minimal-s4sk.tar.bz2 -C ${NFS_ROOT}/domu<br />
</syntaxhighlight><br />
# Set U-Boot environment variables and boot<br />
#: <syntaxhighlight lang="bash"><br />
setenv bootargs<br />
setenv bootdelay 2<br />
setenv baudrate 921600<br />
setenv initrd_high 0xffffffffffffffff<br />
setenv serverip 192.168.10.111<br />
setenv ipaddr 192.168.10.100<br />
setenv tftp '/s4/rootfs_xen/dom0'<br />
setenv rfs '/srv/tftp/s4/rootfs_xen'<br />
setenv boot_dev nfs<br />
setenv bootcmd_tftp 'run tftp_xen_ld; run tftp_dtb_ld; run tftp_kernel_ld; run tftp_policy_ld; run tftp_ramfs_ld; bootm 0x48080000 0x84000000 0x48000000'<br />
setenv tftp_configure_nfs 'fdt set /boot_dev device ${boot_dev}; fdt set /boot_dev my_ip ${ipaddr}; fdt set /boot_dev nfs_server_ip ${serverip}; fdt set /boot_dev nfs_dir ${rfs}/domd; fdt set /boot_dev domu_nfs_dir ${rfs}/domu;'<br />
setenv tftp_dtb_ld 'tftp 0x48000000 ${tftp}/r8a779f0-s4sk-xen.dtb; fdt addr 0x48000000; fdt resize; fdt mknode / boot_dev; run tftp_configure_nfs;'<br />
setenv tftp_ramfs_ld 'tftp 0x84000000 ${tftp}/uInitramfs'<br />
setenv tftp_kernel_ld 'tftp 0x7a000000 ${tftp}/Image'<br />
setenv tftp_xen_ld 'tftp 0x48080000 ${tftp}/xen-uImage'<br />
setenv tftp_policy_ld 'tftp 0x7c000000 ${tftp}/xenpolicy-s4sk'<br />
setenv bootcmd 'run bootcmd_tftp'<br />
run bootcmd<br />
</syntaxhighlight><br />
<!--<br />
setenv set_pcie 'i2c dev 0; i2c mw 0x6c 0x26 5; i2c mw 0x6c 0x254.2 0x1e; i2c mw 0x6c 0x258.2 0x1e; i2c mw 0x20 0x3.1 0xfe;'<br />
setenv bootcmd 'run set_pcie; run bootcmd_tftp'<br />
--><br />
<br />
== Confirmed Xen Commands ==<br />
=== Dom0 ===<br />
* Get information about Xen host (xl info)<br />
*: <syntaxhighlight lang="text"><br />
root@generic-armv8-xt-dom0:~# xl info<br />
host : generic-armv8-xt-dom0<br />
release : 5.10.41-yocto-tiny<br />
version : #1 SMP PREEMPT Fri Sep 1 06:40:51 UTC 2023<br />
machine : aarch64<br />
nr_cpus : 8<br />
max_cpu_id : 7<br />
nr_nodes : 1<br />
cores_per_socket : 1<br />
threads_per_core : 1<br />
cpu_mhz : 16.666<br />
hw_caps : 00000000:00000000:00000000:00000000:00000000:00000000:00000000:00000000<br />
virt_caps : hvm hvm_directio hap iommu_hap_pt_share vpmu gnttab-v1<br />
total_memory : 3456<br />
free_memory : 1501<br />
sharing_freed_memory : 0<br />
sharing_used_memory : 0<br />
outstanding_claims : 0<br />
free_cpus : 0<br />
xen_major : 4<br />
xen_minor : 17<br />
xen_extra : -unstable<br />
xen_version : 4.17-unstable<br />
xen_caps : xen-3.0-aarch64 xen-3.0-armv7l<br />
xen_scheduler : credit2<br />
xen_pagesize : 4096<br />
platform_params : virt_start=0x200000<br />
xen_changeset : Thu Dec 8 19:01:46 2022 +0000 git:df73c24859-dirty<br />
xen_commandline : dom0_mem=256M console=dtuart dtuart=/soc/serial@e6540000 dom0_max_vcpus=2 loglvl=all xsm=flask flask=permissive bootscrub=0 pci-passthrough=on<br />
cc_compiler : aarch64-poky-linux-gcc (GCC) 9.3.0<br />
cc_compile_by : xen-4.17.0+gitA<br />
cc_compile_domain : poky<br />
cc_compile_date : 2022-12-20<br />
build_id : dd12b927ba9ed4a4d0c3af6b7e509e75cfc36124<br />
xend_config_format : 4<br />
root@generic-armv8-xt-dom0:~#<br />
</syntaxhighlight><br />
<br />
* List information about all/some domains (xl list)<br />
*: <syntaxhighlight lang="text"><br />
root@generic-armv8-xt-dom0:~# xl list<br />
Name ID Mem VCPUs State Time(s)<br />
Domain-0 0 256 2 r----- 12.5<br />
DomD 1 1021 4 -b---- 21.0<br />
DomU 2 511 2 -b---- 8.2<br />
root@generic-armv8-xt-dom0:~#<br />
</syntaxhighlight><br />
<br />
* Terminate a domain immediately (xl destroy DomU)<br />
*: <syntaxhighlight lang="text"><br />
root@generic-armv8-xt-dom0:~# xl list<br />
Name ID Mem VCPUs State Time(s)<br />
Domain-0 0 256 2 r----- 12.5<br />
DomD 1 1021 4 -b---- 21.0<br />
DomU 2 511 2 -b---- 8.2<br />
root@generic-armv8-xt-dom0:~#<br />
root@generic-armv8-xt-dom0:~#<br />
root@generic-armv8-xt-dom0:~# xl destroy DomU<br />
root@generic-armv8-xt-dom0:~# xl list<br />
Name ID Mem VCPUs State Time(s)<br />
Domain-0 0 256 2 r----- 14.2<br />
DomD 1 1023 4 -b---- 23.3<br />
root@generic-armv8-xt-dom0:~#<br />
</syntaxhighlight><br />
<br />
* Create a domain from config file <filename> (xl create <config file>)<br />
*: <syntaxhighlight lang="text"><br />
root@generic-armv8-xt-dom0:~# xl list<br />
Name ID Mem VCPUs State Time(s)<br />
Domain-0 0 256 2 r----- 14.2<br />
DomD 1 1023 4 -b---- 23.3<br />
root@generic-armv8-xt-dom0:~#<br />
root@generic-armv8-xt-dom0:~# xl create /etc/xen/domu.cfg<br />
Parsing config from /etc/xen/domu.cfg<br />
libxl: info: libxl_create.c:121:libxl__domain_build_info_setdefault: qemu-xen is unavailable, using qemu-xen-traditional instead: No such file or directory<br />
(XEN) GICv3: Mapping ITS translation register to d3:addr=0x00000000f1050000 size=0x0000000000010000<br />
libxl: error: libxl_arm.c:1137:copy_partial_fdt: Can't copy the node "/passthrough" from the partial FDT<br />
(XEN) memory_map:add: dom3 gfn=e6260 mfn=e6260 nr=10<br />
(XEN) memory_map:add: dom3 gfn=37fc9 mfn=47fc9 nr=2<br />
(XEN) ipmmu: /soc/iommu@eefc0000: d3: Set IPMMU context 3 (pgd 0x4f65a0000)<br />
(XEN) ipmmu: /soc/rswitch_osid1: Using IPMMU context 3<br />
root@generic-armv8-xt-dom0:~# (XEN) d3v0: vGICD: RAZ on reserved register offset 0x00000c<br />
(XEN) d3v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER4<br />
(XEN) d3v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER8<br />
(XEN) d3v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER12<br />
(XEN) d3v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER16<br />
(XEN) d3v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER20<br />
(XEN) d3v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER24<br />
(XEN) d3v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER28<br />
(XEN) d3v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER32<br />
(XEN) d3v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER36<br />
(XEN) d3v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER40<br />
(XEN) d3v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER44<br />
(XEN) d3v0: vGICR: SGI: unhandled word write 0x000000ffffffff to ICACTIVER0<br />
(XEN) d3v1: vGICR: SGI: unhandled word write 0x000000ffffffff to ICACTIVER0<br />
(XEN) grant_table.c:1879:d3v1 Expanding d3 grant table from 1 to 2 frames<br />
(XEN) grant_table.c:1879:d3v1 Expanding d3 grant table from 2 to 3 frames<br />
<br />
root@generic-armv8-xt-dom0:~# xl list<br />
Name ID Mem VCPUs State Time(s)<br />
Domain-0 0 256 2 r----- 15.9<br />
DomD 1 1021 4 -b---- 26.5<br />
DomU 3 511 2 -b---- 7.5<br />
root@generic-armv8-xt-dom0:~#<br />
</syntaxhighlight><br />
<br />
* Attach to domain's console (xl console DomD)<br />
*: <syntaxhighlight lang="text"><br />
root@generic-armv8-xt-dom0:~# xl list<br />
Name ID Mem VCPUs State Time(s)<br />
Domain-0 0 256 2 r----- 15.9<br />
DomD 1 1021 4 -b---- 26.5<br />
DomU 3 511 2 -b---- 7.5<br />
root@generic-armv8-xt-dom0:~#<br />
root@generic-armv8-xt-dom0:~# xl console DomD<br />
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x412fd050]<br />
[ 0.000000] Linux version 5.10.41-yocto-standard (oe-user@oe-host) (aarch64-poky-linux-gcc (GCC) 9.3.0, GNU ld (GNU Binutils) 2.34.0.20200220) #1 SMP PREEMPT Thu Jul 15 12:11:21 UTC 2021<br />
[ 0.000000] Machine model: XENVM-4.17<br />
[ 0.000000] Xen 4.17 support found<br />
(snip)<br />
s4sk-domd login: root<br />
root@s4sk-domd:~#<br />
</syntaxhighlight><br />
** Back to Dom0 : ctrl + ]<br />
**: <syntaxhighlight lang="text"><br />
root@s4sk-domd:~# root@generic-armv8-xt-dom0:~#<br />
root@generic-armv8-xt-dom0:~#<br />
</syntaxhighlight><br />
<br />
* Attach to domain's console (xl console DomU)<br />
*: <syntaxhighlight lang="text"><br />
root@generic-armv8-xt-dom0:~# xl list<br />
Name ID Mem VCPUs State Time(s)<br />
Domain-0 0 256 2 r----- 21.6<br />
DomD 1 1021 4 -b---- 33.3<br />
DomU 3 511 2 -b---- 8.2<br />
root@generic-armv8-xt-dom0:~# xl console DomU<br />
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x412fd050]<br />
[ 0.000000] Linux version 5.10.41-yocto-standard (oe-user@oe-host) (aarch64-poky-linux-gcc (GCC) 9.3.0, GNU ld (GNU Binutils) 2.34.0.20200220) #1 SMP PREEMPT Thu Jul 15 12:11:21 UTC 2021<br />
[ 0.000000] Machine model: XENVM-4.17<br />
[ 0.000000] Xen 4.17 support found<br />
(snip)<br />
s4sk-domu login: root<br />
root@s4sk-domu:~#<br />
</syntaxhighlight><br />
** Back to Dom0 : ctrl + ]<br />
<br />
* List the VCPUs for all/some domains (xl vcpu-list)<br />
*: <syntaxhighlight lang="text"><br />
root@generic-armv8-xt-dom0:~# xl vcpu-list<br />
Name ID VCPU CPU State Time(s) Affinity (Hard / Soft)<br />
Domain-0 0 0 6 r-- 12.0 all / all<br />
Domain-0 0 1 1 -b- 11.4 all / all<br />
DomD 1 0 2 -b- 10.3 all / all<br />
DomD 1 1 3 -b- 7.9 all / all<br />
DomD 1 2 4 -b- 7.9 all / all<br />
DomD 1 3 5 -b- 9.2 all / all<br />
DomU 3 0 7 -b- 4.3 all / all<br />
DomU 3 1 0 -b- 4.2 all / all<br />
root@generic-armv8-xt-dom0:~#<br />
</syntaxhighlight><br />
<br />
* Set which CPUs a VCPU can use (xl vcpu-pin <domain ID> <vCPU> <physical CPUs>)<br />
*: <syntaxhighlight lang="text"><br />
root@generic-armv8-xt-dom0:~# xl vcpu-list<br />
Name ID VCPU CPU State Time(s) Affinity (Hard / Soft)<br />
Domain-0 0 0 6 r-- 13.3 all / all<br />
Domain-0 0 1 1 -b- 12.6 all / all<br />
DomD 1 0 2 -b- 10.6 all / all<br />
DomD 1 1 3 -b- 8.9 all / all<br />
DomD 1 2 4 -b- 8.6 all / all<br />
DomD 1 3 5 -b- 10.3 all / all<br />
DomU 3 0 7 -b- 4.5 all / all<br />
DomU 3 1 0 -b- 4.3 all / all<br />
root@generic-armv8-xt-dom0:~# xl vcpu-pin 1 1 7<br />
root@generic-armv8-xt-dom0:~# xl vcpu-list<br />
Name ID VCPU CPU State Time(s) Affinity (Hard / Soft)<br />
Domain-0 0 0 6 r-- 13.4 all / all<br />
Domain-0 0 1 1 -b- 12.7 all / all<br />
DomD 1 0 2 -b- 10.6 all / all<br />
DomD 1 1 7 -b- 8.9 7 / all<br />
DomD 1 2 4 -b- 8.6 all / all<br />
DomD 1 3 5 -b- 10.4 all / all<br />
DomU 3 0 7 -b- 4.5 all / all<br />
DomU 3 1 0 -b- 4.3 all / all<br />
root@generic-armv8-xt-dom0:~#<br />
</syntaxhighlight><br />
<br />
* Create multiple domains (xl create)<br />
*: <syntaxhighlight lang="text"><br />
root@generic-armv8-xt-dom0:~# xl vcpu-list<br />
Name ID VCPU CPU State Time(s) Affinity (Hard / Soft)<br />
Domain-0 0 0 0 -b- 6.0 all / all<br />
Domain-0 0 1 1 r-- 4.4 all / all<br />
DomD 1 0 2 -b- 4.7 all / all<br />
DomD 1 1 3 -b- 4.1 all / all<br />
DomD 1 2 4 -b- 6.5 all / all<br />
DomD 1 3 5 -b- 3.3 all / all<br />
DomU 2 0 6 -b- 3.8 all / all<br />
DomU 2 1 7 -b- 3.8 all / all<br />
root@generic-armv8-xt-dom0:~# xl destroy DomU<br />
root@generic-armv8-xt-dom0:~# xl vcpu-list<br />
Name ID VCPU CPU State Time(s) Affinity (Hard / Soft)<br />
Domain-0 0 0 0 r-- 6.5 all / all<br />
Domain-0 0 1 1 -b- 4.7 all / all<br />
DomD 1 0 2 -b- 4.9 all / all<br />
DomD 1 1 3 -b- 4.4 all / all<br />
DomD 1 2 4 -b- 6.7 all / all<br />
DomD 1 3 5 -b- 3.5 all / all<br />
root@generic-armv8-xt-dom0:~# cp /etc/xen/domu.cfg /etc/xen/domu1.cfg<br />
root@generic-armv8-xt-dom0:~# cp /etc/xen/domu.cfg /etc/xen/domu2.cfg<br />
root@generic-armv8-xt-dom0:~# cp /etc/xen/domu.cfg /etc/xen/domu3.cfg<br />
root@generic-armv8-xt-dom0:~# vi /etc/xen/domu1.cfg<br />
Before: vif = [ 'backend=DomD, bridge=xenbr0, mac=08:00:27:ff:cb:cf' ]<br />
After : vif = [ 'backend=DomD, bridge=xenbr0, mac=08:00:27:ff:cb:d1' ]<br />
root@generic-armv8-xt-dom0:~# vi /etc/xen/domu2.cfg<br />
Before: vif = [ 'backend=DomD, bridge=xenbr0, mac=08:00:27:ff:cb:cf' ]<br />
After : vif = [ 'backend=DomD, bridge=xenbr0, mac=08:00:27:ff:cb:d2' ]<br />
root@generic-armv8-xt-dom0:~# vi /etc/xen/domu3.cfg<br />
Before: vif = [ 'backend=DomD, bridge=xenbr0, mac=08:00:27:ff:cb:cf' ]<br />
After : vif = [ 'backend=DomD, bridge=xenbr0, mac=08:00:27:ff:cb:d3' ]<br />
root@generic-armv8-xt-dom0:~#<br />
root@generic-armv8-xt-dom0:~# xl create /etc/xen/domu1.cfg 'name="DomU-1" ; vcpus="1" ; cpus="all" ; memory="128" ; tee = [] ; dt_passthrough_nodes = [] ; dtdev = [] ; irqs = [] ; iomem = [] ; renesas_vmq = []'<br />
Parsing config from /etc/xen/domu1.cfg<br />
libxl: info: libxl_create.c:121:libxl__domain_build_info_setdefault: qemu-xen is unavailable, using qemu-xen-traditional instead: No such file or directory<br />
(XEN) GICv3: Mapping ITS translation register to d3:addr=0x00000000f1050000 size=0x0000000000010000<br />
root@generic-armv8-xt-dom0:~# (XEN) d3v0: vGICD: RAZ on reserved register offset 0x00000c<br />
(XEN) d3v0: vGICR: SGI: unhandled word write 0x000000ffffffff to ICACTIVER0<br />
(XEN) grant_table.c:1879:d3v0 Expanding d3 grant table from 1 to 2 frames<br />
<br />
root@generic-armv8-xt-dom0:~# xl create /etc/xen/domu2.cfg 'name="DomU-2" ; vcpus="1" ; cpus="all" ; memory="128" ; tee = [] ; dt_passthrough_nodes = [] ; dtdev = [] ; irqs = [] ; iomem = [] ; renesas_vmq = []'<br />
Parsing config from /etc/xen/domu2.cfg<br />
libxl: info: libxl_create.c:121:libxl__domain_build_info_setdefault: qemu-xen is unavailable, using qemu-xen-traditional instead: No such file or directory<br />
(XEN) GICv3: Mapping ITS translation register to d4:addr=0x00000000f1050000 size=0x0000000000010000<br />
root@generic-armv8-xt-dom0:~# (XEN) d4v0: vGICD: RAZ on reserved register offset 0x00000c<br />
(XEN) d4v0: vGICR: SGI: unhandled word write 0x000000ffffffff to ICACTIVER0<br />
(XEN) grant_table.c:1879:d4v0 Expanding d4 grant table from 1 to 2 frames<br />
<br />
root@generic-armv8-xt-dom0:~# xl create /etc/xen/domu3.cfg 'name="DomU-3" ; vcpus="1" ; cpus="all" ; memory="128" ; tee = [] ; dt_passthrough_nodes = [] ; dtdev = [] ; irqs = [] ; iomem = [] ; renesas_vmq = []'<br />
Parsing config from /etc/xen/domu3.cfg<br />
libxl: info: libxl_create.c:121:libxl__domain_build_info_setdefault: qemu-xen is unavailable, using qemu-xen-traditional instead: No such file or directory<br />
(XEN) GICv3: Mapping ITS translation register to d5:addr=0x00000000f1050000 size=0x0000000000010000<br />
root@generic-armv8-xt-dom0:~# (XEN) d5v0: vGICD: RAZ on reserved register offset 0x00000c<br />
(XEN) d5v0: vGICR: SGI: unhandled word write 0x000000ffffffff to ICACTIVER0<br />
(XEN) grant_table.c:1879:d5v0 Expanding d5 grant table from 1 to 2 frames<br />
<br />
root@generic-armv8-xt-dom0:~#<br />
root@generic-armv8-xt-dom0:~# xl vcpu-list<br />
Name ID VCPU CPU State Time(s) Affinity (Hard / Soft)<br />
Domain-0 0 0 0 r-- 6.9 all / all<br />
Domain-0 0 1 3 -b- 7.2 all / all<br />
DomD 1 0 4 -b- 7.8 all / all<br />
DomD 1 1 6 -b- 5.6 all / all<br />
DomD 1 2 7 -b- 7.8 all / all<br />
DomD 1 3 5 -b- 5.1 all / all<br />
DomU 2 0 1 -b- 4.2 all / all<br />
DomU 2 1 2 -b- 3.8 all / all<br />
DomU-1 3 0 0 -b- 6.7 all / all<br />
DomU-2 4 0 2 -b- 7.1 all / all<br />
DomU-3 5 0 6 -b- 6.7 all / all<br />
root@generic-armv8-xt-dom0:~#<br />
</syntaxhighlight><br />
<br />
=== DomD ===<br />
* Attach to domain's console (xl console DomD)<br />
*: <syntaxhighlight lang="text"><br />
root@generic-armv8-xt-dom0:~# xl console DomD<br />
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x412fd050]<br />
[ 0.000000] Linux version 5.10.41-yocto-standard (oe-user@oe-host) (aarch64-poky-linux-gcc (GCC) 9.3.0, GNU ld (GNU Binutils) 2.34.0.20200220) #1 SMP PREEMPT Thu Jul 15 12:11:21 UTC 2021<br />
(snip)<br />
s4sk-domd login: root<br />
root@s4sk-domd:~#<br />
</syntaxhighlight><br />
* Ethernet TSN<br />
*: S4SK TSN0(IC101) <-- LAN Cable --> PC<br />
*: <syntaxhighlight lang="text"><br />
root@generic-armv8-xt-dom0:~# xl console DomD<br />
(snip)<br />
root@s4sk-domd:~#<br />
root@s4sk-domd:~# ifconfig tsn0 192.168.10.10<br />
[ 1687.829480] rswitch_get_phy_node PHY interface = sgmii<br />
[ 1687.831104] libphy: rswitch_mii: probed<br />
[ 1687.879559] mv88x2110 etha0:01: Firmware version 8.5.0.0<br />
[ 1687.915572] mv88x2110 etha0:01: attached PHY driver [mv88x2110] (mii_bus:phy_addr=etha0:01, irq=POLL)<br />
root@s4sk-domd:~# [ 1691.032980] renesas_eth_sw e68c0000.ethernet tsn0: Link is Up - 1Gbps/Full - flow control off<br />
[ 1691.033147] IPv6: ADDRCONF(NETDEV_CHANGE): tsn0: link becomes ready<br />
<br />
root@s4sk-domd:~#<br />
root@s4sk-domd:~# ifconfig tsn0<br />
tsn0 Link encap:Ethernet HWaddr 74:90:50:D0:7B:58<br />
inet addr:192.168.10.10 Bcast:192.168.10.255 Mask:255.255.255.0<br />
inet6 addr: fe80::7690:50ff:fed0:7b58/64 Scope:Link<br />
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br />
RX packets:60 errors:0 dropped:3 overruns:0 frame:0<br />
TX packets:17 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:1000<br />
RX bytes:6835 (6.6 KiB) TX bytes:1380 (1.3 KiB)<br />
<br />
root@s4sk-domd:~# ping 192.168.10.116<br />
PING 192.168.10.116 (192.168.10.116): 56 data bytes<br />
64 bytes from 192.168.10.116: seq=0 ttl=127 time=1.123 ms<br />
64 bytes from 192.168.10.116: seq=1 ttl=127 time=1.631 ms<br />
64 bytes from 192.168.10.116: seq=2 ttl=127 time=1.009 ms<br />
root@s4sk-domd:~#<br />
root@s4sk-domd:~# ifconfig tsn1 192.168.11.11<br />
root@s4sk-domd:~# ifconfig tsn1<br />
tsn1 Link encap:Ethernet HWaddr E6:22:98:08:D9:C9<br />
inet addr:192.168.11.11 Bcast:192.168.11.255 Mask:255.255.255.0<br />
UP BROADCAST MULTICAST MTU:1500 Metric:1<br />
RX packets:0 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:1000<br />
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)<br />
<br />
root@s4sk-domd:~#<br />
</syntaxhighlight><br />
* UFS<br />
*: <syntaxhighlight lang="text"><br />
root@s4sk-domd:~# mount /dev/sda1 /mnt/<br />
[ 869.252821] EXT4-fs (sda1): recovery complete<br />
[ 869.253400] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)<br />
root@s4sk-domd:~#<br />
</syntaxhighlight><br />
: * Click [[R-Car/Boards/S4SK/Yocto-Linux/SDK-v3.16.2#UFS | here]] to see how to format.<br />
<br />
* Micro SD (CN5)<br />
*: <syntaxhighlight lang="text"><br />
root@s4sk-domd:~# dmesg |grep mmcblk<br />
[ 0.000000] Kernel command line: root=/dev/mmcblk0p2 rw rootwait console=hvc0 clk_ignore_unused pci=pcie_bus_perf<br />
[ 3.646050] Waiting for root device /dev/mmcblk0p2...<br />
[ 3.829567] mmcblk0: mmc0:aaaa SC32G 29.7 GiB<br />
[ 3.833074] mmcblk0: p1 p2 p3<br />
[ 4.145066] EXT4-fs (mmcblk0p2): recovery complete<br />
[ 4.148809] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)<br />
[ 5.281648] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)<br />
root@s4sk-domd:~#<br />
</syntaxhighlight><br />
** Back to Dom0 : ctrl + ]<br />
*: <syntaxhighlight lang="text"><br />
root@s4sk-domd:~# root@generic-armv8-xt-dom0:~#<br />
root@generic-armv8-xt-dom0:~#<br />
</syntaxhighlight><br />
<br />
=== DomU ===<br />
* Attach to domain's console (xl console DomU)<br />
*: <syntaxhighlight lang="text"><br />
root@generic-armv8-xt-dom0:~# xl console DomU<br />
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x412fd050]<br />
[ 0.000000] Linux version 5.10.41-yocto-standard (oe-user@oe-host) (aarch64-poky-linux-gcc (GCC) 9.3.0, GNU ld (GNU Binutils) 2.34.0.20200220) #1 SMP PREEMPT Thu Jul 15 12:11:21 UTC 2021<br />
(snip)<br />
s4sk-domu login: root<br />
root@s4sk-domu:~#<br />
</syntaxhighlight><br />
<!--<br />
* Ethernet TSN<br />
*: S4SK TSN1(IC104) <== LAN Cable ==> PC<br />
*: <syntaxhighlight lang="text"><br />
root@generic-armv8-xt-dom0:~# xl console DomU<br />
(snip)<br />
root@s4sk-domd:~#<br />
root@s4sk-domd:~# ifconfig tsn1 192.168.10.10<br />
[ 1687.829480] rswitch_get_phy_node PHY interface = sgmii<br />
[ 1687.831104] libphy: rswitch_mii: probed<br />
[ 1687.879559] mv88x2110 etha0:01: Firmware version 8.5.0.0<br />
[ 1687.915572] mv88x2110 etha0:01: attached PHY driver [mv88x2110] (mii_bus:phy_addr=etha0:01, irq=POLL)<br />
root@s4sk-domd:~# [ 1691.032980] renesas_eth_sw e68c0000.ethernet tsn0: Link is Up - 1Gbps/Full - flow control off<br />
[ 1691.033147] IPv6: ADDRCONF(NETDEV_CHANGE): tsn0: link becomes ready<br />
<br />
root@s4sk-domd:~#<br />
root@s4sk-domd:~# ifconfig tsn1<br />
tsn1 Link encap:Ethernet HWaddr F6:28:2B:C2:B0:30<br />
inet addr:192.168.10.10 Bcast:169.254.255.255 Mask:255.255.0.0<br />
inet6 addr: fe80::f428:2bff:fec2:b030/64 Scope:Link<br />
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br />
RX packets:74 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:25 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:1000<br />
RX bytes:12111 (11.8 KiB) TX bytes:3518 (3.4 KiB)<br />
root@s4sk-domd:~# ping 192.168.10.116<br />
PING 192.168.10.116 (192.168.10.116): 56 data bytes<br />
64 bytes from 192.168.10.116: seq=0 ttl=127 time=1.123 ms<br />
64 bytes from 192.168.10.116: seq=1 ttl=127 time=1.631 ms<br />
64 bytes from 192.168.10.116: seq=2 ttl=127 time=1.009 ms<br />
root@s4sk-domd:~#<br />
</syntaxhighlight><br />
--><br />
** Back to Dom0 : ctrl + ]<br />
*: <syntaxhighlight lang="text"><br />
root@s4sk-domd:~# root@generic-armv8-xt-dom0:~#<br />
root@generic-armv8-xt-dom0:~#<br />
</syntaxhighlight><br />
<br />
== Known issues & Restrictions ==<br />
<!-- Fixed SDK v3.16.1<br />
# HW offload feature may cause TSN1 hang<br />
# "xl console DomU" is not available<br />
--><br />
{{Template:R-Car-Yocto-Gen4-SK-footer}}</div>RenesasJahttps://elinux.org/R-Car/Boards/S4SK/Yocto-Linux/SDK-v3.16.2R-Car/Boards/S4SK/Yocto-Linux/SDK-v3.16.22024-01-10T02:38:36Z<p>RenesasJa: /* How to flash/update the loader */</p>
<hr />
<div>{{Template:R-Car-S4-Navbox}}<br />
{{TOC right}}<br />
[[Category:R-Car]]<br />
[[Category:R-Car Gen4]]<br />
<br />
== Software revisions ==<br />
<br />
{| class="wikitable"<br />
|-<br />
! Software !! Revision<br />
|-<br />
| R-Car SDK || v3.16.2<br />
|-<br />
| R-Car S4 Linux Yocto package || Version 5.24.1<br />
|-<br />
| Yocto Project || [http://git.yoctoproject.org/cgit/cgit.cgi/poky/tag/?id=yocto-3.1.11 3.1.11]<br />
|- <br />
| aarch64-poky-linux-gcc (GCC) || 9.3<br />
|- <br />
| Linux Kernel || 5.10.41<br />
|- <br />
| Userland 64/32bit || 64<br />
|- <br />
| U-Boot || 2020.10<br />
|- <br />
|}<br />
<br />
== Host PC ==<br />
Ubuntu 20.04 LTS (64bit) is recommended as OS. 32bit version is not supported. <br/><br />
<br />
== Building the BSP for R-Car S4 Starter Kit ==<br />
Warning! Yocto builds require a lot of disk space (up to 100 GB). Make sure you have got enough before starting the build.<br />
<br />
=== Installation of required tools and libraries ===<br />
Ubuntu is used as Linux Host PC since Yocto Project Quick Start specifies Ubuntu as one of the distributions. You need to install the required packages as follows.<br />
: <syntaxhighlight lang="bash"><br />
sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib \<br />
build-essential chrpath socat cpio python3 python3-pip python3-pexpect \<br />
xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa \<br />
libsdl1.2-dev pylint3 xterm libarchive-zip-perl<br />
</syntaxhighlight><br />
<br />
=== Using build script ===<br />
# Build script(build.sh)<br />
#: <syntaxhighlight lang="bash"><br />
#!/bin/bash<br />
<br />
POKY_COMMIT=74b22db6879b388d700f61e08cb3f239cf940d18<br />
META_OE_COMMIT=814eec96c2a29172da57a425a3609f8b6fcc6afe<br />
META_RENESAS_COMMIT=92ddfebae62b78a65ee430d49b710bb16b719bf2<br />
<br />
mkdir build<br />
cd build<br />
export WORK=`pwd`<br />
cd ${WORK}<br />
<br />
# Clone basic Yocto layers in parallel<br />
git clone git://git.yoctoproject.org/poky &<br />
git clone git://git.openembedded.org/meta-openembedded &<br />
git clone https://github.com/renesas-rcar/meta-renesas &<br />
<br />
# Wait for all clone operations<br />
wait<br />
<br />
# Switch to proper branches/commits<br />
cd ${WORK}/poky<br />
git checkout -b tmp ${POKY_COMMIT}<br />
cd ${WORK}/meta-openembedded<br />
git checkout -b tmp ${META_OE_COMMIT}<br />
cd ${WORK}/meta-renesas<br />
git checkout -b tmp ${META_RENESAS_COMMIT}<br />
<br />
cd ${WORK}<br />
source poky/oe-init-build-env ${WORK}/build-s4sk-gateway<br />
<br />
cp $WORK/meta-renesas/meta-rcar-gateway/docs/sample/conf/s4sk/poky-gcc/bsp/*.conf ./conf/<br />
<br />
bitbake rcar-image-gateway<br />
<br />
</syntaxhighlight><br />
# build<br />
#: <syntaxhighlight lang="bash"><br />
./build.sh<br />
</syntaxhighlight><br />
<!--<br />
#: If the build completes successfully, all the necessary files are generated in a following directory:<br />
#:: <syntaxhighlight lang="text"><br />
${WORK}/build-s4sk-gateway/tmp/deploy/images/s4sk/<br />
</syntaxhighlight><br />
#:: The built Image directory is below.<br />
#:: https://hydrochoerus.com/rcar/s4sk/build/build-s4sk-gateway/tmp/deploy/images/s4sk/<br />
#:: The built directory is below.<br />
#:: https://hydrochoerus.com/rcar/s4sk/<br />
--><br />
<br />
=== Manual steps ===<br />
# Create a directory and switch to it<br />
#: <syntaxhighlight lang="bash"><br />
mkdir build<br />
cd build<br />
export WORK=`pwd`<br />
</syntaxhighlight><br />
# Clone basic Yocto layers:<br />
#: <syntaxhighlight lang="bash">cd $WORK<br />
git clone git://git.yoctoproject.org/poky<br />
git clone git://git.openembedded.org/meta-openembedded<br />
git clone https://github.com/renesas-rcar/meta-renesas<br />
</syntaxhighlight><br />
# Switch to proper branches/commits<br />
#: <syntaxhighlight lang="bash"><br />
cd $WORK/poky<br />
git checkout -b tmp 74b22db6879b388d700f61e08cb3f239cf940d18<br />
cd $WORK/meta-openembedded<br />
git checkout -b tmp 814eec96c2a29172da57a425a3609f8b6fcc6afe<br />
cd $WORK/meta-renesas<br />
git checkout -b tmp 92ddfebae62b78a65ee430d49b710bb16b719bf2<br />
</syntaxhighlight><br />
# Setup build environment<br />
#: <syntaxhighlight lang="bash"><br />
cd $WORK<br />
source poky/oe-init-build-env $WORK/build-s4sk-gateway<br />
</syntaxhighlight><br />
# Prepare default configuration files.<br />
#: <syntaxhighlight lang="bash"><br />
cp $WORK/meta-renesas/meta-rcar-gateway/docs/sample/conf/s4sk/poky-gcc/bsp/*.conf ./conf/<br />
</syntaxhighlight><br />
# Start the build<br />
#: <syntaxhighlight lang="bash"><br />
bitbake rcar-image-gateway<br />
</syntaxhighlight><br />
# Building image can take up to a few hours depending on your host system performance.<br>After the build has been completed successfully, you should see the output similar to:<br />
#: <syntaxhighlight lang="bash"><br />
NOTE: Tasks Summary: Attempted 5076 tasks of which 5 didn't need to be rerun and all succeeded.<br />
</syntaxhighlight><br />
#: and the command prompt should return.<br />
<br />
=== Generated images ===<br />
: Bitbake has generated all the necessary files in ./tmp/deploy/images directory. <br/>You can verify its content:<br />
: <syntaxhighlight lang="bash"><br />
$ ls -1 `find ./tmp/deploy/images/s4sk/ -maxdepth 1 -type l -print`<br />
./tmp/deploy/images/s4sk/Image<br />
./tmp/deploy/images/s4sk/Image-s4sk.bin<br />
./tmp/deploy/images/s4sk/modules-s4sk.tgz<br />
./tmp/deploy/images/s4sk/r8a779f0-s4sk-s4sk.dtb<br />
./tmp/deploy/images/s4sk/r8a779f0-s4sk.dtb<br />
./tmp/deploy/images/s4sk/rcar-image-gateway-s4sk.manifest<br />
./tmp/deploy/images/s4sk/rcar-image-gateway-s4sk.tar.bz2<br />
./tmp/deploy/images/s4sk/rcar-image-gateway-s4sk.testdata.json<br />
./tmp/deploy/images/s4sk/u-boot-elf-s4sk.srec<br />
./tmp/deploy/images/s4sk/u-boot-elf.srec<br />
./tmp/deploy/images/s4sk/u-boot-initial-env<br />
./tmp/deploy/images/s4sk/u-boot-initial-env-s4sk<br />
./tmp/deploy/images/s4sk/u-boot-s4sk.bin<br />
./tmp/deploy/images/s4sk/u-boot.bin<br />
</syntaxhighlight><br />
: '''[https://hydrochoerus.com/rcar/s4sk/build/build-s4sk-gateway/tmp/deploy/images/s4sk/Image Image]''' is a Kernel image, '''[https://hydrochoerus.com/rcar/s4sk/build/build-s4sk-gateway/tmp/deploy/images/s4sk/r8a779f0-s4sk.dtb *.dtb]''' is a blob file, '''[https://hydrochoerus.com/rcar/s4sk/build/build-s4sk-gateway/tmp/deploy/images/s4sk/rcar-image-gateway-s4sk.tar.bz2 rcar-image-gateway-s4sk.tar.bz2]''' is the rootfs<!--, '''modules-s4sk.tgz''' are kernel modules-->.<br />
: <syntaxhighlight lang="bash"><br />
$ ls -1 tmp/deploy/images/s4sk/*.srec<br />
tmp/deploy/images/s4sk/bl31-s4sk.srec<br />
tmp/deploy/images/s4sk/tee-s4sk.srec<br />
tmp/deploy/images/s4sk/u-boot-elf-s4sk-v2020.10+gitAUTOINC+616f05eb5a-r0.srec<br />
tmp/deploy/images/s4sk/u-boot-elf-s4sk.srec<br />
tmp/deploy/images/s4sk/u-boot-elf.srec<br />
</syntaxhighlight><br />
: The built Image directory is below.<br />
: https://hydrochoerus.com/rcar/s4sk/build/build-s4sk-gateway/tmp/deploy/images/s4sk/<br />
: The built directory is below.<br />
: https://hydrochoerus.com/rcar/s4sk/<br />
<br />
=== How to flash/update the loader ===<br />
: Write the generated bl31-s4sk.srec, tee-s4sk.srec and u-boot-elf-s4sk.srec binaries and ICUMX loader[*] to flash<br />
: See : [[R-Car/Boards/S4SK#How_to_flash.2Fupdate_the_loader]]<br />
: [*] Download from [https://www.renesas.com/icumx-loader-and-flash-writer-package-r-car-s4-starter-kit here]<br />
<br />
== How to boot ==<br />
=== Micro SD boot ===<br />
<span style="color:#ff0000">'''WARNING!''' These steps will erase the Micro SD card completely. In short, all files will be lost.</span><br/><br />
In order to prepare you Micro SD card, follow these instructions on host machine:<br />
# Partion your Micro SD card to set 1 partition and ID=83 (Linux)<br />
#: Make sure the Micro SD card doesn't contain any important files.<br />
#: <syntaxhighlight lang="bash"><br />
$ fdisk /dev/mmcblk0 or /dev/sdb etc.<br />
-> d<br />
-> n<br />
-> p<br />
-> 1<br />
-> t<br />
-> 83<br />
</syntaxhighlight><br />
# Format this partition to ext4<br />
#: <syntaxhighlight lang="bash"><br />
$ mkfs.ext4 /dev/mmcblk0p1<br />
</syntaxhighlight><br />
# Mount this partition on your host to any directory and upack the rcar-image-gateway-s4sk.tar.bz2 into mounted folder.<br/><br />
#: <syntaxhighlight lang="bash"><br />
$ mount /dev/mmcblk0p1 /mnt<br />
$ cd <your_yocto_build_directory><br />
$ tar xjf ${WORK}/build-s4sk-gateway/tmp/deploy/images/s4sk/rcar-image-gateway-s4sk.tar.bz2 -C /mnt<br />
$ sync<br />
$ umount /mnt<br />
</syntaxhighlight><br />
#: NOTE: probably you need to be a root user, hence use "sudo"<br />
#: Image and r8a779f0-s4sk.dtb are deployed under /mnt/boot/ directory<br />
# Insert Micro SD card to S4 SK Mciro SD card slot(CN5)<br />
# Set SW3<br />
#:SW3.1 : On <br><br />
#:SW3.2 : On <br><br />
#:SW3.3 : Off <br><br />
#:SW3.4 : On <br><br />
#:SW3.5 : Off <br><br />
#:SW3.6 : On <br><br />
#:SW3.7 : Off <br><br />
#:SW3.8 : Off <br><br />
# Power ON (SW5)<br />
#: <syntaxhighlight lang="bash"><br />
Ex)<br />
=> setenv bootargs rw root=/dev/mmcblk0p1 rootwait ignore_loglevel cma=560M<br />
=> ext4load mmc 0 0x48080000 /boot/Image; ext4load mmc 0 0x48000000 /boot/r8a779f0-s4sk.dtb; booti 0x48080000 - 0x48000000<br />
</syntaxhighlight><br />
<br />
=== NFS boot ===<br />
# Install some packages for NFS boot on Host PC (See [[R-Car/Boards/Yocto-Gen3/v5.9.0#Loading_kernel_via_TFTP_and_rootfs_via_NFS]])<br />
# Decompress the rootfs on Host PC<br />
#: <syntaxhighlight lang="bash"><br />
$ tar xjf ${WORK}/build-s4sk-gateway/tmp/deploy/images/s4sk/rcar-image-gateway-s4sk.tar.bz2 -C ${NFS_ROOT}<br />
</syntaxhighlight><br />
#: Image and r8a779f0-s4sk.dtb are deployed under /mnt/boot/ directory<br />
# Connect the Host PC to the S4SK IC101(TSN0) connector with a LAN cable<br />
# Set SW3<br />
#:SW3.1 : On <br><br />
#:SW3.2 : On <br><br />
#:SW3.3 : Off <br><br />
#:SW3.4 : On <br><br />
#:SW3.5 : Off <br><br />
#:SW3.6 : On <br><br />
#:SW3.7 : Off <br><br />
#:SW3.8 : Off <br><br />
# Power ON (SW5)<br />
#: <syntaxhighlight lang="bash"><br />
Ex)<br />
=> setenv ethaddr xx:xx:xx:xx:xx:xx <- MAC address [*]<br />
=> setenv ipaddr 192.168.1.3<br />
=> setenv serverip 192.168.1.2<br />
=> setenv bootargs rw root=/dev/nfs nfsroot=192.168.1.2:/srv/tftp/s4/rootfs,nfsvers=3 ip=192.168.1.3:::::tsn0 ignore_loglevel cma=560M<br />
=> setenv bootcmd 'tftp 0x48080000 {Your path}/boot/Image; tftp 0x48000000 {Your path}/boot/r8a779f0-s4sk.dtb; booti 0x48080000 - 0x48000000'<br />
=> saveenv<br />
Saving Environment to SPIFlash... Erasing SPI flash...Writing to SPI flash...done<br />
OK<br />
=> run bootcmd<br />
Using ethernet@e68c0000 device<br />
TFTP from server 192.168.1.2; our IP address is 192.168.1.2<br />
Filename '{Your path}/boot/Image'.<br />
Load address: 0x48080000<br />
Loading: ##########################################################<br />
######################<br />
(snip)<br />
8.7 MiB/s<br />
done<br />
Bytes transferred = 33714688 (2027200 hex)<br />
Using ethernet@e68c0000 device<br />
TFTP from server 192.168.1.2; our IP address is 192.168.1.3<br />
Filename '{Your path}/boot/r8a779f0-s4sk.dtb'.<br />
Load address: 0x48000000<br />
Loading: ####<br />
6.6 MiB/s<br />
done<br />
Bytes transferred = 55591 (d927 hex)<br />
Moving Image from 0x48080000 to 0x48200000, end=4a2b0000<br />
## Flattened Device Tree blob at 48000000<br />
Booting using the fdt blob at 0x48000000<br />
Loading Device Tree to 0000000057fef000, end 0000000057fff926 ... OK<br />
<br />
Starting kernel ...<br />
</syntaxhighlight><br />
: [*]<br />
: Check the MAC address of the board using S4_StarterKit_Configurator.exe. See [[R-Car/Boards/S4SK#Tab_of_S4_Starter_Kit]]. <br />
: Please use the MAC address of TSN0<br />
<br />
== How to test some capabilities ==<br />
=== Micro SD (CN5) ===<br />
<syntaxhighlight lang="bash"><br />
root@s4sk:~# dmesg|grep mmcblk<br />
[ 0.000000] Kernel command line: rw root=/dev/mmcblk0p1 rootwait ignore_loglevel cma=560M<br />
[ 1.934976] Waiting for root device /dev/mmcblk0p1...<br />
[ 1.984307] mmcblk0: mmc0:aaaa SL08G 7.40 GiB<br />
[ 1.988193] mmcblk0: p1<br />
[ 2.223505] EXT4-fs (mmcblk0p1): recovery complete<br />
[ 2.225750] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: (null)<br />
[ 3.806413] EXT4-fs (mmcblk0p1): re-mounted. Opts: (null)<br />
root@s4sk:~#<br />
root@s4sk:~# mount /dev/mmcblk0p1 /mnt/<br />
</syntaxhighlight><br />
<br />
=== TSN0/1 (IC101/IC104) ===<br />
<syntaxhighlight lang="bash"><br />
Ex)<br />
root@s4sk:~# ifconfig tsn0 192.168.10.100<br />
[ 743.368014] rswitch_get_phy_node PHY interface = sgmii<br />
[ 744.372046] libphy: rswitch_mii: probed<br />
[ 744.419085] mv88x2110 etha0:01: Firmware version 8.5.0.0<br />
[ 744.455718] mv88x2110 etha0:01: attached PHY driver [mv88x2110] (mii_bus:phy_addr=etha0:01, irq=POLL)<br />
[ 747.601932] renesas_eth_sw e68c0000.ethernet tsn0: Link is Up - 1Gbps/Full - flow control off<br />
[ 747.603126] IPv6: ADDRCONF(NETDEV_CHANGE): tsn0: link becomes ready<br />
root@s4sk:~# ping 192.168.10.116<br />
PING 192.168.10.116 (192.168.10.116): 56 data bytes<br />
64 bytes from 192.168.10.116: seq=0 ttl=128 time=0.904 ms<br />
64 bytes from 192.168.10.116: seq=1 ttl=128 time=0.639 ms<br />
64 bytes from 192.168.10.116: seq=2 ttl=128 time=0.854 ms<br />
</syntaxhighlight><br />
<br />
=== UFS ===<br />
<syntaxhighlight lang="bash"><br />
root@s4sk:~# fdisk /dev/sda<br />
<br />
Welcome to fdisk (util-linux 2.35.1).<br />
Changes will remain in memory only, until you decide to write them.<br />
Be careful before using the write command.<br />
<br />
[ 2889.819979] sda:<br />
<br />
Command (m for help): n<br />
Partition number (1-128, default 1): 1<br />
First sector (256-31256570, default 256): 256<br />
Last sector, +/-sectors or +/-size{K,M,G,T,P} (256-31256570, default 31256570): +64G<br />
<br />
Created a new partition 1 of type 'Linux filesystem' and of size 64 GiB.<br />
<br />
Command (m for help): w<br />
The partition table has been altered.<br />
Calling ioctl() to re-read partition table.<br />
[ 2917.736661] sda: sda1<br />
Syncing disks.<br />
<br />
root@s4sk:~# mkfs.ext4 /dev/sda1<br />
mke2fs 1.45.4 (23-Sep-2019)<br />
Discarding device blocks: done<br />
Creating filesystem with 16777216 4k blocks and 4194304 inodes<br />
Filesystem UUID: bdf0481e-52a8-4562-a60c-24721db2ed66<br />
Superblock backups stored on blocks:<br />
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,<br />
4096000, 7962624, 11239424<br />
<br />
Allocating group tables: done<br />
Writing inode tables: done<br />
Creating journal (131072 blocks): done<br />
Writing superblocks and filesystem accounting information: done<br />
<br />
root@s4sk:~# mount /dev/sda1 /mnt/<br />
[ 2940.602149] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)<br />
root@s4sk:~#<br />
</syntaxhighlight><br />
<br />
=== PCIe ===<br />
==== PCIe Root Complex(CN30) : SSD ====<br />
Environment:<br />
: 1) [https://www.amazon.co.jp/Samsung-MZVPV512HDGL00000/dp/B017LDAIJG MZVPV512HDGL-0000]<br />
: 2) [https://www.microsatacables.com/u-2-sff-8639-to-m-2-m-key-nvme-ssd-and-pcie-x4-slot-u2-1329-m2 U.2 to M.2 M-Key NVME SSD and PCIe]<br />
: 3) [https://www.microsatacables.com/pcie-gen-4-16-gt-s-oculink-sff-8611-to-u-2-sff-8639-cable Oculink to U.2 Cable ]<br />
: 4) [https://www.yodobashi.com/product/100000001006318891/ SATA/IDE AC Adoperq(Japanese site)]<br />
::[[File:s4sk_pcie_nvme3.jpg|350px]]<br />
: <syntaxhighlight lang="bash"><br />
root@s4sk:~# mount /dev/nvme0n1p1 /mnt/<br />
[ 41.822014] EXT4-fs (nvme0n1p1): mounted filesystem with ordered data mode. Opts: (null)<br />
root@s4sk:~# mount -t tmpfs -o size=400M tmpfs /tmp<br />
root@s4sk:~# dd if=/dev/urandom of=/tmp/file bs=1M count=350<br />
350+0 records in<br />
350+0 records out<br />
367001600 bytes (367 MB, 350 MiB) copied, 4.96337 s, 73.9 MB/s<br />
root@s4sk:~# cp /tmp/file /mnt/<br />
root@s4sk:~# cp /tmp/file /mnt/<br />
root@s4sk:~# cmp /mnt/file /tmp/file<br />
root@s4sk:~#<br />
</syntaxhighlight><br />
==== PCIe Root Complex(CN30) : LAN card ====<br />
Environment:<br />
: [https://www.amazon.com/Jeirdus-Chipset-EXPI9301CT-Desktop-Network/dp/B07DCRLWCC PCI-e Network Card ]<br />
: <syntaxhighlight lang="bash"><br />
root@s4sk:~# dmesg|grep e1000e<br />
[ 0.977043] e1000e: Intel(R) PRO/1000 Network Driver<br />
[ 0.977678] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.<br />
[ 0.986786] e1000e 0000:01:00.0: enabling device (0000 -> 0002)<br />
[ 1.025259] e1000e 0000:01:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode<br />
[ 1.088330] e1000e 0000:01:00.0 0000:01:00.0 (uninitialized): registered PHC clock<br />
[ 1.143115] e1000e 0000:01:00.0 eth0: (PCI Express:2.5GT/s:Width x1) 68:05:ca:30:bf:05<br />
[ 1.144182] e1000e 0000:01:00.0 eth0: Intel(R) PRO/1000 Network Connection<br />
[ 1.145073] e1000e 0000:01:00.0 eth0: MAC: 3, PHY: 8, PBA No: E46981-008<br />
[ 5.370228] e1000e 0000:01:00.0 enp1s0: renamed from eth0<br />
root@s4sk:~#<br />
root@s4sk:~# ifconfig enp1s0 192.168.10.100<br />
root@s4sk:~# ping 192.168.10.101<br />
PING 192.168.10.101 (192.168.10.101): 56 data bytes<br />
64 bytes from 192.168.10.101: seq=0 ttl=128 time=1.095 ms<br />
64 bytes from 192.168.10.101: seq=1 ttl=128 time=1.397 ms<br />
</syntaxhighlight><br />
==== PCIe Endpoint(CN31) ====<br />
pcitest [S4SK - Another S4 SK] :<br />
: 1) Environments<br />
:: S4 SK board [A] : PCIe CH0(CN30)[*1] <--- OCuLink cable[*2] ---> Another S4 SK board [B] : PCIe CH1(CN31)[*3]<br />
:: [*1] PCIe CH0(CN30) : Root Complex<br />
:: [*2] Ex) https://store.supermicro.com/supermicro-55cm-oculink-to-oculink-cable-cbl-sast-0818.html<br />
:: [*3] PCIe CH1(CN31) : Endpoint <br />
<br />
: 2) Create DTB file for Endpoint of S4 SK board [B]<br />
:: Disable: Root Complex of PCIe CH0<br />
:: Enable : Endpoint of PCIe CH1<br />
:: <syntaxhighlight lang="bash"><br />
Ex)<br />
$ cd (Your SDK Build directory)<br />
$ ls<br />
build-s4sk-gateway build_yocto.sh meta-openembedded meta-renesas poky<br />
$ source poky/oe-init-build-env build-s4sk-gateway/<br />
$ bitbake -c devshell linux-renesas<br />
$ vi arch/arm64/boot/dts/renesas/r8a779f0-s4sk.dts<br />
(snip)<br />
&pciec0 {<br />
status = "disabled"; <-- Change to disable !!!<br />
pinctrl-0 = <&pcie0_pins>;<br />
pinctrl-names = "default";<br />
clkreq-gpios = <&gpio2 15 GPIO_ACTIVE_LOW>;<br />
};<br />
<br />
&pciec1_ep {<br />
status = "okay"; <-- Change to enable !!!<br />
pinctrl-0 = <&pcie1_pins>;<br />
pinctrl-names = "default";<br />
clkreq-gpios = <&gpio2 16 GPIO_ACTIVE_LOW>;<br />
};<br />
<br />
$ make dtbs<br />
$ exit<br />
</syntaxhighlight><br />
::Output: tmp/work/s4sk-poky-linux/linux-renesas/5.10.41+xxxxx/linux-s4sk-standard-build/arch/arm64/boot/dts/renesas/r8a779f0-s4sk.dtb<br />
<br />
: 3) Create Image file for Endpoint of S4 SK board [B]<br />
:: Enable CONFIG_PCI_EPF_TEST and CONFIG_PCIE_RENESAS_EP<br />
:: <syntaxhighlight lang="bash"><br />
Ex)<br />
$ cd (Your SDK Build directory)<br />
$ source poky/oe-init-build-env build-s4sk-gateway/<br />
$ bitbake -c devshell linux-renesas<br />
$ make menuconfig<br />
Device Drivers ---><br />
[*] PCI support<br />
PCI Endpoint ---><br />
[*] PCI Endpoint Support<br />
[*] PCI Endpoint Test driver <-- Change to "*"<br />
Device Drivers ---><br />
[*]PCI support ---><br />
PCI controller drivers ---><br />
DesignWare PCI Core Support ---><br />
[*] Renesas R-Car PCIe 4.0 Endpoint controller <-- Change to "*"<br />
$ make Image<br />
$ exit<br />
</syntaxhighlight><br />
:: Output: tmp/work/s4sk-poky-linux/linux-renesas/5.10.41+xxxxx/linux-s4sk-standard-build/arch/arm64/boot/Image<br />
<br />
: 4) Copty to binaries to Micro SD card for S4 SK board [B]<br />
:: <syntaxhighlight lang="bash"><br />
Ex)<br />
$ mount /dev/mmcblk0p1 /mnt<br />
$ cp r8a779f0-s4sk.dtb /mnt/boot/r8a779f0-s4sk_pcie1ep.dtb<br />
$ cp Image /mnt/boot/Image_ep<br />
<br />
$ ls /mnt/boot<br />
Image Image_ep r8a779f0-s4sk_pcie1ep.dtb<br />
Image-5.10.41-yocto-standard r8a779f0-s4sk.dtb <br />
</syntaxhighlight><br />
<br />
: 5) pcitest<br />
:: Step 1: Start S4 SK board [B] of Endpoint using Image_ep and r8a779f0-s4sk_pcie1ep.dtb<br />
:: <syntaxhighlight lang="bash"><br />
=> setenv bootargs console=ttySC0,921600 rw root=/dev/mmcblk0p1 rootwait cma=560M<br />
=> ext4load mmc 0:1 0x48080000 /boot/Image_ep;ext4load mmc 0:1 0x48000000 /boot/r8a779f0-s4sk_pcie1ep.dtb;booti 0x48080000 - 0x48000000<br />
(snip)<br />
s4sk login: root<br />
root@s4sk:~# sed -e 's/e65d0000.pciec0_ep/e65d8000.pciec1_ep/' ep_setup.sh > ep1_setup.sh<br />
root@s4sk:~# chmod +x ep1_setup.sh<br />
root@s4sk:~# ./ep1_setup.sh<br />
Endpoint setup<br />
mount: /sys/kernel/config: none already mounted or mount point busy.<br />
completed.<br />
root@s4sk:~#<br />
</syntaxhighlight><br />
:: Step 2: Start S4 SK board [A] of Root Complex (after Step 1)<br />
:: <syntaxhighlight lang="bash"><br />
=> setenv bootargs console=ttySC0,921600 rw root=/dev/mmcblk0p1 rootwait cma=560M<br />
=> ext4load mmc 0:1 0x48080000 /boot/Image;ext4load mmc 0:1 0x48000000 /boot/r8a779f0-s4sk.dtb;booti 0x48080000 - 0x48000000<br />
(snip)<br />
s4sk login: root<br />
root@s4sk:~# sed -e 's/1024000/102400/' -e 's/1024001/102401/' pcitest_script.sh > pcitest_script_s4sk.sh<br />
root@s4sk:~# chmod +x pcitest_script_s4sk.sh<br />
root@s4sk:~# ./pcitest_script_s4sk.sh<br />
</syntaxhighlight><br />
:: Log: Root Complex (S4 SK board [A])<br />
:: <syntaxhighlight lang="bash"><br />
root@s4sk:~# ./pcitest_script_s4sk.sh<br />
BAR tests<br />
<br />
BAR0: OKAY<br />
BAR4: OKAY<br />
<br />
MSI Interrupt tests<br />
<br />
SET IRQ TYPE TO MSI: OKAY<br />
MSI1: OKAY<br />
MSI2: OKAY<br />
<br />
(snip)<br />
<br />
Copy Tests<br />
<br />
COPY ( 1 bytes): OKAY<br />
COPY ( 1024 bytes): OKAY<br />
COPY ( 1025 bytes): OKAY<br />
COPY ( 102400 bytes): OKAY<br />
COPY ( 102401 bytes): OKAY<br />
<br />
root@s4sk:~#<br />
</syntaxhighlight><br />
:: Log: Endpoint S4 SK board [B]<br />
:: <syntaxhighlight lang="bash"><br />
[ 44.917496] WRITE => Size: 1 bytes DMA: NO Time: 0.000001320 seconds Rate: 739 KB/s<br />
[ 45.941519]<br />
[ 45.941519] WRITE => Size: 1024 bytes DMA: NO Time: 0.000003060 seconds Rate: 326797 KB/s<br />
<br />
(snip)<br />
<br />
[ 642.777482] COPY => Size: 1 bytes DMA: NO Time: 0.000002160 seconds Rate: 452 KB/s<br />
[ 643.793517]<br />
[ 643.793517] COPY => Size: 1024 bytes DMA: NO Time: 0.000060420 seconds Rate: 16550 KB/s<br />
[ 644.809523]<br />
[ 644.809523] COPY => Size: 1025 bytes DMA: NO Time: 0.000061500 seconds Rate: 16276 KB/s<br />
[ 645.831665]<br />
[ 645.831665] COPY => Size: 102400 bytes DMA: NO Time: 0.006186660 seconds Rate: 16163 KB/s<br />
[ 646.851668]<br />
[ 646.851668] COPY => Size: 102401 bytes DMA: NO Time: 0.006195241 seconds Rate: 16141 KB/s<br />
</syntaxhighlight><br />
<br />
=== Thermal ===<br />
<syntaxhighlight lang="bash"><br />
root@s4sk:~# cat /sys/class/thermal/thermal_zone*/temp<br />
39500<br />
37500<br />
37500<br />
root@s4sk:~#<br />
</syntaxhighlight><br />
<br />
=== CPU Hotplug ===<br />
<syntaxhighlight lang="bash"><br />
root@s4sk:~# cat /sys/devices/system/cpu/online<br />
0-7<br />
root@s4sk:~# echo 0 > /sys/devices/system/cpu/cpu1/online<br />
[ 145.337609] IRQ227: set affinity failed(-22).<br />
[ 145.337764] CPU1: shutdown<br />
[ 145.338704] psci: CPU1 killed (polled 0 ms)<br />
root@s4sk:~# cat /sys/devices/system/cpu/offline<br />
1<br />
root@s4sk:~# echo 1 > /sys/devices/system/cpu/cpu1/online<br />
[ 169.401119] Detected VIPT I-cache on CPU1<br />
[ 169.401189] GICv3: raw_spin_lock_init for SGI<br />
[ 169.401202] GICv3: CPU1: found redistributor 100 region 0:0x00000000f1080000<br />
[ 169.401303] CPU1: Booted secondary processor 0x0000000100 [0x412fd050]<br />
root@s4sk:~# cat /sys/devices/system/cpu/offline<br />
<br />
root@s4sk:~#<br />
</syntaxhighlight><br />
<br />
== Known issues & Restrictions ==<br />
# [Known issue] Bitbake error messages when building SDK first time<br />
#: <syntaxhighlight lang="bash"><br />
ERROR: When reparsing <build directory>../poky/meta/recipes-core/meta/meta-environment.bb:do_generate_content, the basehash value changed from 64c5dd461f406265715a6af027a37e78b6ea72e63aa576426a354b4becee57fc to af14637c6b64b6b26c9a37492a361cc15a15be8f5ffa7ceb06618ce994035e75. The metadata is not deterministic and this needs to be fixed.<br />
ERROR: The following commands may help:<br />
ERROR: $ bitbake meta-environment-s4sk -cdo_generate_content -Snone<br />
ERROR: Then:<br />
ERROR: $ bitbake meta-environment-s4sk -cdo_generate_content -Sprintdiff<br />
</syntaxhighlight><br />
#: These error message are Poky 3.1.11 bug, it doesn't affect to build output.<br />
#: Ignore error messages.<br />
# [Restriction] The "reboot" command is not completed. Therefore, press the power(SW5) or reset(SW4) button.<br />
<!--# [Restriction] PCIe 1ch Endpoint doesn't work when both PCIe 0ch Root Complex and PCIe 1ch Endpoint are enabled.--><br />
<br />
<br />
{{Template:R-Car-Yocto-Gen4-SK-footer}}</div>RenesasJahttps://elinux.org/ST40ST402023-12-25T19:12:51Z<p>Polprog: /* Linux support */</p>
<hr />
<div>'''ST40''' is a SuperH4-based architecture from ST Microelectronics. The cores were used in ST's SoCs designed for television set-top boxes.<br />
<br />
[[File:Sti7111.png|thumb|right|STi7111 block diagram]]<br />
== SoCs ==<br />
* STi 7100<br />
* STi 7105<br />
* STi 7111<br />
<br />
<br />
== Linux support ==<br />
<br />
STMicroelectronics used to distribute STLinux, an SDK package that contained Linux 2.4 (later 3.1) and U-Boot sources, as well as GDB-based debug environment to be used on ST40 products.<br />
<br />
* [https://archive.org/details/stlinux-2.4-sh-4 STLinux 2.4 SDK for Linux]<br />
* [https://archive.org/details/stlinux-3.10-stworkbench-20140606 STLinux 3.10 + STWorkbench for Linux]<br />
* [https://archive.org/details/stlinux-3.10-source-20140606 STLinux 3.10 Source]<br />
* [https://archive.org/details/stm-st40.540-5.4.0-MSWin32-x86 ST40 Micro Toolset R5.4.0] - Windows SDK (SH4 gcc + gdb)<br />
* [https://archive.org/details/stm-stmc.160-1.6.0-MSWin32-x86 ST Micro Connection Package R1.6.0] - Windows JTAG adapter driver package<br />
<br />
== JTAG Adapter ==<br />
<br />
JTAG adapter based on FT2232H or FT4232H. Custom VID/PID required. MProg programming template: [[File:Stmclite.ept]]<br />
<br />
JTAG adapter pinout<br />
<br />
AD0 TCK<br />
AD1 TDI<br />
AD2 TDO<br />
AD3 TMS<br />
AD4 nTRST<br />
AD5 nRST<br />
AD6 nASEBRK<br />
AD7 TRIGOUT<br />
<br />
Connecting to target is done using ST's GDB script<br />
<br />
$ sh4gdb<br />
(gdb)> sh4tp STMCLT1000A:[devkit]:st40<br />
<br />
Where `devkit` is a matching development kit ID.<br />
<br />
Production devices often come with JTAG debug access locked. If you get an error "Sentinel not found", JTAG debug is disabled on your device.<br />
<br />
== See Also ==<br />
<br />
* [https://www.st.com/resource/en/reference_manual/cd17182230-st40-core-and-instruction-set-architecture-stmicroelectronics.pdf ST40 Core and Instruction Set Architecture]<br />
* [https://www.st.com/resource/en/reference_manual/rm0288-st40-core-support-peripherals-stmicroelectronics.pdf Core Support Peripherals]<br />
* [[File:Sti7111.pdf]] STi7111 Datasheet<br />
* http://duff.dk/zaptor/</div>Polprog