bozden

A useful overview... Seems updated regularly... https://ssd.borecraft.com/SSD_Buying_Guide.pdf

Tesla MCU1 eMMC failure https://tesla-info.com/blog/tesla-mcu1-emmc-failure.php

Follow-up: After compiling the kernel with usbtouchscreen as module and enabling it + apt-get xinput & xinput-calibrator , my touchscreen worked. Axis were inverted, so a transformation matrix is needed on /etc/X11/xorg.conf.d/99-calibration.conf: Option "TransformationMatrix" "0 -1 1 1 0 0 0 0 1" On the other hand it needs some scaling as I cannot reach the screen's edges. As far as I can see it can only be done by trial-error - a very tedious task. By looking into /var/log/Xorg.0.log I can see the TransformationMatrix is read, but not other parameters suggested by xinput_calibrator mentioned in the log, so I'm not sure if they are relevant (modifying them had no effect). That's it for now...

Thank you for the tip. I currently solved this without cheating: 1) I use a shared folder on VirtualBox 2) On the main bash I'm running, after the compilation is done I create MyApp folder, and move from the output/images folder renaming 3 files generated. Simple solution for my dumb question :/

I fully understand this, that quote was attribute to "No end-user support: built from trunk" wording in motd I learned linux playing with these SBC's, mainly Armbian and it is a hobby for me. I have several installations at my home-office as hobby projects. If I ever earn some money from these stuff I'll donate it. But for this or helping others on the forums, I need to learn first Things like chroot environment, kernel parameters, kernel compiling are very new to me. The build script is very high quality code from my perspective. Last week, by examining it I learned a lot. For example the "wait_for_package_manager" function in general.sh provides solution for some of my problems. Kudos for @Igor and everybody contributed. I'll try to "document" my adventure for other newbies.

For anybody reading this: Most of the debugging for your setup routines can be done just by looking inside generated image file. Of course I have to burn the sd-card and run on actual device at the end...

OK, after a weeks effort, I (quick-)examined the code, found some related posts and got help from @Werner, thank you for breaking the "you are on your own" rule . The structure above needs major revising, if we go step by step: 1) I have to write the variables in the outher bash to some .sh file (e.g. under userpatches/overlay/myapp) to be copied to chroot environment to be sourced. 2 & 3) I cannot do this, because in "image-helpers.sh" customize_image routine only one file, "customize-image.sh" is copied to $SDCARD. So I must combine everything into that file. 3) In customize-image.sh, I need to source the file I've saved in step 1 to get my variables back 4) Is ok, but can only be used for setting variables. And finally how I can include my own files... See: Now I have to test this whole thing. Cheers

Thank you Werner, that helps. I had a misconception with the namin. "Userpatch" mixed with kernel pathing, "overlay" with overlayfs. After examining the code I found correct keywords for search and found this: I also recognized from the code that only customize-image.sh is copied to destination and my other files (which I call from it) do not. Now the post you shared comes into play... Thank you again.

Nope, didn't work... As far as I can understand, at that stage it is not ready yet...

OK, learning... I just recognized customize-image.sh is run in chroot, so direct access to host OS is not possible, maybe there is a variable for host binding which I couldn't find. On the other hand lib.config is run on host. Although it seems to be used for setting variables, it is source'd, so I can run anything there. So, this might work: cp "${SRC}""${MY_PRODUCT_DIR}" "${SDCARD}""${MY_SETUP_DIR}" And in customize-image.sh, I can move files around and do whatever I like with them. Can somebody please confirm? It takes too long to test...

I have several files I want to embed into the compiled image, such as logos, desktop backgrounds, some public keys, scripts etc. I can put them in correct place (e.g. /usr/local/bin) or put it in a directory at root (e.g. /MyAppSetup) and run a script to handle/move them. In the past I was using a private git repo on my server to clone these, but if I'm compiling, I'd like to get rid of this extra layer. I could not find a way to do that. Could someone please advise?

I have several applications running on different boards. After reading documents/forum posts and checking the code here and there, I came to the following setup and I'll be very pleased if someone confirms it. Application A1, A2,..An Board B1, B2,...Bn 1) Create multiple compile_Ax_By.sh, containing: #!/bin/bash # Define my application MYAPP=A1 # Call ./compile.sh with predefined parameters ./compile.sh BOARD="orangepipcplus" BRANCH="current" RELEASE="focal" BUILD_DESKTOP="yes" KERNEL_ONLY="no" KERNEL_CONFIGURE="no" 2) In userpatches/customize-image.sh add a single line to my custom my-custom-image.sh (in case original got overwritten by update) 3) In userpatches/my-custom-image.sh put my main logic with case and/or common functions: # MY VARIABLES ... # MY MAIN main() { case $MYAPP in App1) ... App2) ... esac } # MY SUBS ... 4) Create userpatches/lib.config and form a similar case structure for variables case $HKBOX_TYPE in App1) PACKAGE_LIST_ADDITIONAL="$PACKAGE_LIST_ADDITIONAL ..." ;; App2) ... esac # common ones here One thing I couldn't find is the name of the final image. Something like Armbian_MyApp_MyBoard_....img would be nice. Otherwise it overwrites the original...

Yes, they only have cubieboard and Rpi 2 included in base. I wonder if people have created others. I can guess that it will fail at kernel level if a board is not modeled. I'll stick with writing better code and testing all in one for now...

Thank you Igor, I already had examined them briefly. Very nice work indeed... But not applicable for my case (I think)... I'm not bulk-producing... What I'm trying to do (for now) is simply adding some drivers, adding some scripting to customize-image.sh, such as additions to motd, several users/groups/rights management, pre-installing some additional software through apt-get, adding some custom scripts under /usr/local/bin etc. Testing this would require installation of the customized Armbian and checking the logs etc. Is there a working armhf emulator for x32-64? That would ease the burden alot... I found QEMU just now, did you try it? My development environment is on Win 10 and I don't mind speed loss caused by emulation. Or I'm really missing the point :/

(Please feel free to move the post if it is not appropriate here.) I'm trying the build environment on VirtualBox and modifying settings and adding new scripting. I have had a habit of testing each modification right away, but the compile/burn/on-device-test is not logical. How can I emulate a device / setup / install process? Is there any way?