SteeMan
-
Posts
1651 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by SteeMan
-
-
14 minutes ago, ThatUnknownGuy said:
What am I doing wrong? I'm using the meson-sm1-sei610-ethfix.dtb and I'm sure the env file is setup correctly.
I really need to install into eMMC
It is good that you have the process of restoring the factory android firmware down as you may need that a few more times as you work through this.
It seems that you are doing things correctly, but it isn't clear from your description that you have ever tried without something going wrong and then needed to retry. So I would recommend you go back to step one and try again.
1) Reinstall factory android firmware
2) Download a clean copy of the armbian build you want to install (you talk about switching between desktop and minimal so I don't know what build were have been trying)
3) Burn the build to your sd card
4) On the newly created sd card, edit the /boot/uEnv.txt file for the correct dtb and cpu boot (since you are using an Amlogic device, I would recommend removing the Rockchip and Allwinner sections completely)
5) cp u-boot.sd to u-boot.ext (note copy not move, and I am assuming you are doing this because you have the green screen issue, if you don't have the green screen issue you don't need to do this step, even if you do have the green screen issue, since you are using this as a server and likely rarely using the hdmi output directly you can also skip this step, perhaps try it both with and without this step)
6) boot with the sd card installed via the toothpick method to install the multi-boot and boot from the sd card
7) go through the initial root login and setup your user while booted from the sd card
8) as root run install-aml.sh
9) you should be installed in emmc at this point reboot
That should work and since you are starting from a known fresh firmware and doing only the minimum steps necessary, you should be eliminating other external factors that could be causing a problem.
-
5 hours ago, broose said:
I must be missing something because I tried all the dtb files even on a box I have that is in the list and all it does is boot to the android recovery screen on all of them
Please provide more information for us to help you.
1) What set of instructions you are following to get this working on your box
2) Make/Model of the Box you are trying to get working
3) What armbian build you are using and where you downloaded it from
4) What method you are using to create your sd card
5) What dtb files you are trying (and why you think they are the correct ones to try)
6) The exact uEnv.txt file (or files if you have tried multiple) you are trying (attach file to post)
7) The method you are using to enable booting from the sd card on your box
You probably are just missing a simple step, but it could be any number of things, and without more information it is hard for us to guess what you may be doing wrong.
-
5 hours ago, broose said:
next is the dtb file part, I know I have to copy the name of it and then open up the uEnv file and replace the name with the new one but do I need to remove the hash tag from the start?
You want to remove the hash tag from the lines you want and add it to the lines you don't want (that character comments out those lines).
What you want to end up with is an uEnv.txt file that looks like this (obviously with the dtb file appropriate for your device):
LINUX=/vmlinuz INITRD=/uInitrd # aml s9xxx FDT=/dtb/amlogic/meson-sm1-sei610.dtb #FTD=/dtb/amlogic/meson-sm1-sei610.dtb APPEND=root=LABEL=ROOT_EMMC rootflags=data=writeback rw console=ttyAML0,115200n8 console=tty0 no_console_suspend consoleblank=0 fsck.fix=yes fsck.repair=yes net.ifnames=0
Notice how I removed the other sections for the other chips that you are not working with (as by default some of these other lines are active and would otherwise need to be commented out). Also note that in addition to uncommenting (i.e. removing the hash tag) from the dtb line you want, you also need to do that for the APPEND line.
Also, if the first dtb file you try doesn't work, you should try all of the others for your soc, until you either find one that works or exhaust the set of provided dtbs. Quite often there isn't an exact match for your box, and you need to find the one that works the best by trial and error (or if you can find a post in these forums that leverages the experience of someone else with the same box).
As long as you are following the other steps (i.e. enabling multiboot via a method appropriate for your Amlogic device - usually, but not always pressing a hidden reset button while powering the device) you should at least get armbian booting.
-
1 hour ago, alimbada said:
Do you not recommend running that image on the GT-King Pro? If so, can you elaborate why?
You can certainly try balbes150's generic images. Depending on what your needs are, it may work well enough for you. But don't expect support or fixes if it doesn't work for you.
1 hour ago, alimbada said:Additionally, is there a reason why that image is not included on the Armbian downloads page and is instead hosted on a file sharing service?
balbes150's images and in general most of the discussion in the TV Box subforum revolve around non-official armbian forks that are not supported by the main armbian project. However the armbian project does graciously let those of us who have an interest in these boxes use the forums and some other of their resources.
1 hour ago, alimbada said:I tried to find some kind of "generic" image on the downloads page, but was unable to. Is there a generic image or do all images have to be manufacturer specific?
That is because that is not the goal or structure of the armbian project. It is focused on the wide variety but still somewhat limited number of SBC's out there. The much larger pool of TV boxes (which often have no support from their manufacturers) is outside the scope of the armbian project.
-
8 hours ago, Albert Barcelona said:
1) create a full emmc backup (I believe that is done with a 'sudo ddbr' ) ??
2) (??) Create u-boot.sd as a copy from u-boot.ext
1) Correct, 'sudo ddbr' will make a backup (or recover a backup) of the emmc.
2) The other way around, you need to copy u-boot.sd (or u-boot.usb) to u-boot.ext But you only need to do this once when you make the SD card or USB drive image. The script that copies to emmc does the correct steps if you have a working environment on SD or USB.
-
I doubt anyone in these forums has tried on that specific box. From the website it looks like a very specific box produced for a specific purpose. That doesn't mean it won't work. Search the forums for discussions on similar devices and try. Since you got it for $1, even if you brick it, it will be a learning experience.
-
3 hours ago, almotra said:
I managed to start on my h96max+
Good to hear you got that working.
3 hours ago, almotra said:Now I am trying to boot on an X96max S905X2, I have tried all the .dtb, some boot but no Ethernet.
Anyone have a .dtb that works with the latest .img armbian?
I am successfully using yesterday's build (20200417) on my H96 Max X2 (which is S905X2 based) with the meson-g12a-x96-max-rmii.dtb
You indicate that this was working for you in the past, what was the last build you were successful in running and what dtb file were you using then?
-
3 hours ago, almotra said:
Hello,
I am trying to install on rk3328.
I downloaded the rk3328-mvr9 image but I don't know how to do it with the commands:
dd if = u-boot-rk3328-mvr9.img of = / dev / <SD_card> conv = fsync bs = 1 count = 442
and
dd if = u-boot-rk3328-mvr9.img of = / dev / <SD_card> conv = fsync bs = 512 skip = 1 seek = 1
on windows with cmd ?
on mac with terminal ?If you have access to the terminal app on a mac then you can do the following:
1) Identify the correct disk that your sd card is mounted as:
diskutil list
(from the output find the SD card mounted as /dev/disk<n>? where <n> is the number of the mount i.e. /dev/disk2 or /dev/disk3)
2) Unmount the disk
diskutil unmountDisk /dev/disk<n>
3) Copy the image to the SD card
sudo dd if=u-boot-<model>.img of=/dev/disk<n> bs=1 count=442
sudo dd if=u-boot-<model>.img of=/dev/disk<n> bs=512 skip=1 seek=1
sync
4) Safely eject the SD card
(I don't use windows so I can't give you instructions for that environment)
-
1 hour ago, Alessandro Salgoni said:
I don't found Armbian TV image for Amlogic
Per the topic of this thread the 'arm-64' images support all three chipsets (rockchip, allwinner, amlogic). Just follow the instructions in the first post of this thread.
-
2 hours ago, balbes150 said:
You are mistaken, when using the latest armbian-TV 20.05 images (please note, not just take the core, but use a specially assembled and configured image), the HDMI sound works on all models of RK AW AML. SPDIF output I don't check (I don't have such hardware)
I will retest. When I tested last week, I didn't have any audio on my boxes. I had assumed this was because you were still working on the changes you were making. But now that you are done with these changes and expect it to work, I will retest and let you know the results.
-
4 hours ago, Alessandro Salgoni said:
Is possible turn on the optical audio output?
Without any information about what box you have or what version you are working with, there isn't enough information to answer your question. I will however add my general observation that the answer is "maybe but probably not". For example I don't have any working audio on any of the boxes I am running (not even under HDMI, let alone optical). I consider working audio in these builds on most boxes to be something you are lucky to have working, but don't expect it to work. (Much like wifi and bluetooth generally don't work on many boxes, and people shouldn't expect them to work).
-
1 hour ago, PhilipT said:
Hi. I know it's been a long time but do you remember what the problem was? I have not been able to boot any kernel using bootm, not even Oleg's kernel converted into a uImage following your instructions. Thanks.
It should be possible to build a local kernel. I have been doing it for a while now and have similar boxes (s905w, s905x2 and s905x3). Here is what I have been doing.
Now let me see if I can remember all of the setup steps I did to get a working environment to build and deploy into.1) My builds are against either 5.4 or 5.6 kernel.org sources (i.e. git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git)
2) I used the kernel config files from a corresponding balbes150 build against the same kernels (so the correct options are being compiled in)
3) I applied the text_offset.patch mentioned above in this thread so that I didn't need to modify the boot command in the autoscript files
4) I modified my uEnv.txt file for the location of the dtb (which I have been putting in /boot manually, instead of a /dtb directory)
5) I think that is all, but I am probably missing something important
Given your goal above, I would start simple (just getting a user built kernel running) then start adding in the other features you are looking for (zfs in your case).
# Sync git with kernel head git pull # make the necessary components make LOCALVERSION= -j4 Image modules dtbs sudo make modules_install sudo make dtbs_install # convert image for install sudo cp /boot/uImage /boot/uImage.bak sudo mkimage -A arm64 -O linux -C none -T kernel -a 0x01080000 -e 0x01080000 -d arch/arm64/boot/Image /boot/uImage # copy over the new dtb file(s) (because the default dtb directory is versioned, this copy prevents the need to edit the uEnv.txt file every time the version number changes) sudo cp /boot/dtbs/<linux_kernel_version>/amlogic/<whatever-dtb-you-need.dtb> /boot # prepare the initrd sudo cp /boot/uInitrd /boot/uInitrd.bak sudo update-initramfs -c -k <linux_kernel_version> # reboot sudo shutdown -r now #if everything worked you are now running the new kernel # cleanup as needed sudo rm -r /boot/dtbs/<old_kernal_versions> sudo rm -r /boot/initrd.img-<old_kernel_versions> sudo rm -r /lib/modules/<old_kernel_versions>
-
19 minutes ago, funben said:
Hi,
I successfuly use Armbian on a beelink TV box but I can't install it on eMMC/NAND. So running out of the SDcard will eventually end up crashing .
So I'm Looking for a cheap / realiable / no hassle TV Box to replace it.
So what box would you recommend, around 25$ budget, which works fine "out of the box" to install armbian
When answering please tell which dtb you are using with your box.
Thanks.
You probably need to be more specific about your requirements. What features do you need working and what are you planning on using it for.
I have 4 TX3 Mini 2gb/16gb boxes (the version without the display). I use two of them for servers, a third to test with and the fourth I use the original android firmware to run a digital display. These can be found for $25 or less (for example https://www.aliexpress.com/item/4000537589239.html). I use the meson-gxl-s905w-tx3-mini.dtb file. Ethernet and hdmi work but no wifi or bluetooth. This box at this price point is on the low end, so don't expect to watch 1080p video, but for light web browsing it works fine. Now the problem I have. On two of the boxes I have installed to internal emmc and everything works fine. However the last two boxes I bought, don't have emmc. Instead they have internal cheap nand which can't be accessed. There is nothing about these two nand boxes that indicate they aren't what they are advertised to be, until you open them up and look at the chips that exist on the board. When you are looking for cheap, there are a lot of vendors that sell knockoffs that look like the real thing but come with substandard components in order to cut costs. Buyer beware.
-
2 hours ago, lu4t said:
1.- let's reuse Android dtbs, which are already included on the Android boxes.
2.- Even though it's not possible to reuse those dtbs out of the box, cause they are compiled for a different kernel, we should be able to decompile them to dts. (this dts is the hw manufacturer description of their own hw; and for boxes manufactures, this files are a description of the mix and match exercise they did to build and compile Android for their boxes).
I think this is the core of the misunderstanding of the complexity of the issue. Both of your points 1 and 2 are based on a false understanding of the environment.
The underlying problem with your understanding of the problem is your statement "this dts is the hw manufacturer description of their own hw". It is much more complex than that in reality. The dts is essentially descriptive code that ties the hw, driver, and kernel together. Any of those three things changing will have an impact on the contents of the dts. So even though the hardware is the same, the driver software and kernels are not. So the dts needs to be modified to correspond to the expectations of the target driver software and target kernel. Unfortunately often the original driver software source code isn't available and android kernels are significantly different than mainline kernels. So usually there isn't any use in having the original android dts in trying to support a particular box under armbian with mainline kernels.
-
12 minutes ago, lu4t said:
May be u"niversal DTB", or "multi-DTB," are not the right terms. The fact is, using a way to abstract the kernel (whichever it is) from dtbs, would isolate the complexity of each other.
Some distros (Android, Raspbian,...) use the term "Device Tree Overlay," which I guess is a better term, more descriptive than the former two. The idea behind it is esencially finding a way to isolate the kernel plumbing off the hw.
My suggestion is esencialy copying this strategy. Unless armbian kernel is way different on its design (I bet it's not the case) do not see why it wont work.
What you describe can theoretically be accomplished today through the use of device tree include files (.dtsi). And if you look at the source code, you will see that this mechanism is already used extensively to overlay board specific items on top of base CPU specifications. Adding an additional layer on top doesn't provide additional functionality that couldn't be accomplished today.
Howerver, the scope of the problem is much bigger in the armbian world than in the Android and Raspbian world. In both Android and Raspbian the base hardware is more constrained (i.e. the models of Raspberry Pi are a relatively small number with a small set of well known cpus, etc). In the TV box world of armbian, you have three different primary CPU manufacturers (Amlogic, Rockchip, Allwinner) each with a wide variety of different cpu architectures. Then you have many, many manufacturers that are putting together boards with all manner of third party chips for memory, nand, wifi, ethernet, bluetooth (and for most of them there is no source code available). And since the goal of these manufacturers is to produce the cheapest tv box possible, they are likely using components that are inexpensive and thus not well supported. Combine those hundreds of different devices with the fact that there is no upstream support from the board manufacturers and component makers to support their products (not even providing source code for others to do it) and you have a massive undertaking. Then consider that there are only a handful of developers within armbian capable of working at this level of the code and you have a problem that isn't solvable today.
-
3 hours ago, zanfi said:
Hi Balbes, I write an armbian image (generic) to an USB thumb; I manage to do that. Than I put a .dtb file I found for sun50iw9p1-dts in the directory with other dtb files. Then I edit the uEnv.txt file and point it to my .dtb file.
Now the question...What need I to do to let the TV box boot from a SD card (not the USB cause I suspect that from usb does not work).
Must I download a u-boot file and dd it to the sd card? Which u-boot must I have? Here below the specs of th TV box:
Allwinner H616 Mali G31
linux for T95 Allwinner H616 Android 10 TV BoxIf you want help in these forums, please do your research first (by looking at information already in the forums), follow existing instructions, and please be more detailed in your problem descriptions.
Based on what you have provided in your post, I can state the following:
1) There is no current support for the Allwinner H616 (that is a new chip, and support for it hasn't worked its way in yet). There are other discussions about this in other forum threads.
2) The link you reference is for an entirely different tv box with a different chip. The link you posted is for a "T95 Max" which is based on the Allwinner H6, which is supported. There are many variants of these tv boxes with similar names and each is likely to be very different internally. Also two boxes with the same name can also vary in terms of their CPU and other components.
3) You mention that you found a dtb file that you were trying. (So much more information is needed here: What dtb?, where did you find it?, why do you think this will work?, what instructions are you following that suggests this will work?, what kernel was that dtb built for?, what kernal are you trying to user it with?) In general you simply can't do what I think you are trying to do. If the dtb file isn't part of the distribution you are installing, there is about a 0% chance it will work. There are no instruction that I am aware of in these forums that suggest that you should try what you are trying and expect it will work. Stick to things that are documented as working (like the first post of this thread) if you are asking for help. Or if you really do intend to experiment, make it clear in your posting that you are not following the documentation and trying something different, so that we don't waste valuable time trying to help you.
-
2 hours ago, Seb_Lz said:
As I was still searching for a solution to get eth0 working on beelink gt1, I've come across this:
https://github.com/150balbes/Build-Armbian/blob/7fa5c7b89c7444a2d503f064296e0dda219cee20/patch/kernel/meson64-dev/0361-arm64-dts-meson-gxm-add-beelink-gt1.patch
My understanding is that the dev branch includes a patch that will generate an additional .dtb file specifically for beelink gt1.Here is the command I used to build dev image:
./compile.sh BOARD=arm-64 BRANCH=dev RELEASE=bionic BUILD_MINIMAL=no BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no COMPRESS_OUTPUTIMAGE=gzThe patch you are looking at is part of base armbian, it is not included in balbes150's arm-64 build. (The patch is from meson64-dev and you are building arm-64-dev). So even if the build did work, you wouldn't see the result you were looking for.
The build for arm-64-dev is currently pointing to the linux kernel next branch, which is in the midst of the open merge window ahead of 5.7, this code will be unstable for a while, that is likely the reason for the build failures you are seeing.
-
40 minutes ago, lu4t said:
So, if we can reuse dtbs embedded on the native Android version, I guess we could think of mix and matching and produce a "generic" DT for Armbian. Again, I am not saying this is a simple task, I am just saying that Technically speaking if feasible and might be something that would facilitate massive adoption of Armbian.
I am looking at this as a way to push adoption, which at the end will return this effort to the community. It's true that the ammount of work on the TO DO must be overwhealming, depending on the criteria followed to assign priorities to each pending task, this could be a nice to have feature in the future...
Are you willing to take on this task and do this work? I would say it is clear that the current maintainers here do not see this as a good investment of their time. This is open source, and the best way to get something you need in open source is to step up and do the work and then contribute it back to the community.
A couple of additional thoughts on your request:
1) From what I have observed and know of the state of android on these TV boxes is that the dtb's from android are fairly worthless in helping getting things working under mainline kernels with armbian. Everyone assumes this is not the case, but I haven't seen anything to indicate otherwise. The gulf between ancient android based kernels and drivers (without source code in most cases) and modern mainline kernels is vast.
2) You are making an assumption that "pushing adoption" is a good thing. The way things currently stand, there are not sufficient people on these forums with the desire and knowledge to provide end user support for the existing new users much less a larger quantity of new users in the future. What is needed now is people willing to answer the basic questions that new users post here, and to work on high quality documentation and tutorials (and maintain them as things change), so that the core developers can be relieved of the burden of providing this information so that they can spend more time moving the project forward.
-
On 3/7/2020 at 3:48 PM, rossbcan said:
whoohoo!! solved: No Wifi Tanix TX92
I did all the heavy lifting on this. Please incorporate changes in build (if you want), including the firmware
patch from https://www.spinics.net/lists/linux-wireless/msg190482.html
to patch/kernel/aml-s9xxx-current/qca9377_hw1.1.patch
on target:
hint: https://github.com/erstrom/linux-ath/issues/9
cd /tmp; git clone -b bd-sdmac https://github.com/erstrom/ath10k-firmware.git
mkdir /lib/firmware/ath10k; cp -rf ath10k-firmware/QCA9887/ /lib/firmware/ath10k
cp /lib/firmware/ath10k/QCA9377/hw1.0/firmware-5.bin_WLAN.TF.1.0-00267-1 /lib/firmware/ath10k/QCA9377/hw1.0/firmware-5.bin
cp /lib/firmware/ath10k/QCA9377/hw1.0/untested/firmware-sdio-5.bin_WLAN.TF.1.1.1-00061-QCATFSWPZ-1 /lib/firmware/ath10k/QCA9377/hw1.0/firmware-sdio-5.binRegards;
Bill
First off, I want to say thank you for contributing. We need all the help around here that we can get.
However, a patch like this is a example of the problems that Armbian faces (and probably to even a greater extent that the Armbian for TV boxes fork faces).
There are probably hundreds of different android TV boxes being manufactured. Each with a lot of inexpensive components - wifi chips, bluetooth, ethernet, etc. In an ideal world each manufacturer would support their products and incorporate their drivers into the mainline kernel. But this isn't an ideal world, and many of these chips have no support by the manufacturer (probably no source code, rarely any bug fixes, security updates are unlikely). That kind of works in the android world as the kernel version is fixed and there isn't an expectation of updates or long term support.
But here in the Armbian world, end users expect that there will be long term support and security and bug fix updates. But that becomes very difficult if the upstream chip builders don't support their products. It isn't sustainable for the limited Armbian developers to spend all their time tracking down and then maintaining hundreds of patches for all these different drivers over a period of years. Therefore you will see in Armbian a desire to put effort into areas where the upstream code can be integrated into the mainline kernel (hopefully by the original manufacturer), so that patches only need to be maintained for a couple of kernel release cycles as the code get integrated into mainline.
So while I know nothing about the wifi chip that your supplied patch supports, it there isn't an effort by someone upstream to be integrating that into the mainline kernel, it probably doesn't make sense for it to be incorporated here. The long term maintenance costs aren't worth the effort. While there certainly are exceptions, that is how I see the reality of being of the current Armbian environment. The project is not able to support the wide variety of components that exist in all the different SBC's and TV boxes being produced today or over the last 5 years, so the effort goes to where there is the most support from upstream suppliers.
-
42 minutes ago, rossbcan said:
It was a simple question: how to use linux-headers from released build system, hoping someone has run into this already.
@SteeManappears to suggest if I work with dev as opposed to current, headers may be OK. Maybe so, but hard to get repeatable builds at bleeding edge, so, I will stick with current until dev becomes current+
Your reply indicates I think a misunderstanding of the status of the Armbian TV Box fork builds (I think we need a better name for these builds). You mention the "released build system" and that "current" is more stable than "dev". Those are both incorrect understandings of the current state of the TV box builds.
First off there isn't a "build system" for the builds off of this fork of Armbian. The builds are simply what balbes150 decides to release to the community for testing. And the "current" vs "dev" is simply a difference in which kernel tree is being used in the build. "current" being a significantly patched 5.6ish kernel and "dev" being an unpatched mainline "next" or "rc" tree.
These Armbian for TV box fork builds are essentially snapshots of balbes150's development work, some more stable than others less so. There isn't any formal release management process around them, nor are they reproducible from a specific git tag (if you look at balbes150's Build_armbian github tree there are no tags or branches). This work is purely the stream of effort that one developer can put into this fork of Armbian. I don't want to come across as complaining about the current status nor downplay balbes150's efforts. It is obvious to me that for the continued progress of these efforts, we need to figure out a way for balbes150 to focus on his strengths (moving the development efforts forward), and the rest of us need to step up and do more of the end user support on these forums and work to bring some structured release management to this code base. The core Armbian team has been focusing on it's release management process recently and I think the results of that effort are great. Something similar needs to happen here with the TV builds as well, but balbes150 can't do it all by himself.
Since I have more time recently (being stuck at home), I am trying to answer more questions on these forums. But it has taken me almost a year of observing to feel confident in being able to contribute knowledgeable information. I am also starting to dig into the build system to better understand it with the intention to submit patches that will improve the release management side of things for the TV box builds. I can't do what balbes150 does for this project, but there are things I can help with, and hopefully I will be able to.
-
23 minutes ago, rossbcan said:
Hi Folks;
(Tanix TX92) uname -a: Linux aml-s9xxx 5.5.1-aml-s9xxx #trunk SMP PREEMPT Thu Apr 9 17:54:57 EDT 2020 aarch64 aarch64 aarch64 GNU/Linux
I need kernel headers to build some out of tree kernel modules such as openvfd but have been stuck for several days.
Research / experience has shown that:
- lot of obsolete information - old kernels
- armbian-config fails to install headers
- No correct linux-headers version available for download
- ./compile.sh INSTALL_HEADERS=yes does install headers, but issues (forum search) due to WIREGUARD
- ./compile.sh INSTALL_HEADERS=yes WIREGUARD=no is required for proper headers (still true?)
Issues:
- "make ARCH=arm64 scripts" fails due to the tool binaries being x86_64
- "make ARCH=arm64 clean" (attempt to rebuild tool binaries) fails "scripts/Makefile.clean:67: recipe for target 'drivers/gpu/drm/arm' failed"
So, how to I get a usable set of kernel-headers?
Thanks;
Bill
The build you have installed is built from balbes150's fork. You don't mention which git tree you are working with, but you should be working with https://github.com/150balbes/Build-Armbian
I believe balbes150 just removed the s905xxx targets and consolidated into the generic arm-64 target, so if you use the current head of the git master branch you will be working with newer kernels. I pulled this code yesterday and built Armbian_20.05.1_Arm-64_bionic_current_5.6.2_desktop.img and in output/debs is the headers package linux-headers-current-arm-64_20.05.1_arm64.deb
It is unlikely that you will be able to rebuild the header package that corresponds to your currently installed build, but you can certainly build a current version with headers for you to work with.
-
15 minutes ago, Nikeb said:
I m using Armbian_5.77_Aml-s812_Ubuntu_bionic_default_3.10.108_desktop_20190326.img
The build you are using would be a build from balbes150's fork. As you can see from the build date, that build is over a year old and on a kernel version (3.10) that is almost 7 years old. If you value security you really shouldn't be using such an old build. balbes150's work is now focused on current mainline kernels (5.4 or higher). Since the build you are using predates my involvement in these forums, I have no idea if installation to internal storage is possible with what you are using.
-
2 hours ago, psxsnake said:
I have strange things when i try tu install a package
it happens even with sudo apt update
E: Release file for http://ports.ubuntu.com/dists/focal/InRelease is not valid yet (invalid for another 14d 3h 8min 43s). Updates for this repository will not be applied.
Is your system clock correct?
-
7 hours ago, Nikeb said:
I'm trying to install it on the ROM of the Minix (wich i guess is NAND) but i can't find the nand-sata-install script (command not found) or in the armbian-config (there is no such menù "Install")
Is something that i could do? use the armbian OS from the minix drive without SD Card?
Assuming you are using one of balbes150's builds, then follow the information in this post:
Unable to boot into SD
in General Chat
Posted
In addition to what blabes150 just said, you can find the current instructions and latest builds in the first post of the below thread: