Jump to content

Klez

Members
  • Posts

    5
  • Joined

  • Last visited

Profile Information

  • Gender
    Male
  • Location
    Spain

Recent Profile Visitors

833 profile views
  1. Hi Igor and everyone else. Id'like to suggest the following: /etc/fstab It´s not necesary to use both noatime and nodiratime, because noatime already implies nodiratime, so you can use only the option "noatime" instead of both. When creating the ext4 filesystem with mkfs.ext4 you can type a label for it with the parameter " -L " so when the users mount their cards on a computer, the desktop will show some name instead "NO NAME". For example: # mkfs.ext4 -O ^has_journal -L Armbian /dev/mmcblk0p1 or... # mkfs.ext4 -O ^has_journal -L Cubox-i /dev/mmcblk0p1 Cheers - Klez
  2. i think you are refering to the firmware file, a .BIN file, (wich is part of linux-firmware). But i am refering to the specific nvram file, wich is a text .TXT file, wich is supposed to be specific to the device wich mounts the chip. Yes, for sure the most up-to-date firmware file must be from linux-firmware at: http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/brcm As you can see in the GIT repository, there are only BIN firmware files, but not Nvram .txt files... Differences between the two files are quite important and my fear is that one could be better or have less wifi bugs. I´m hoping that Jon Nettleton answers my question and tell me where in the earth the "upgraded" file come from. Maybe depending solid-runs answer you could take the decission of upgrading (or keeping) the nvram file shipped in Armbian. Will post replies as i find more info about - Klez
  3. Hi, i've asked this question also in the solid-run forum, but i think it's important to ask here also to Igor. Must be an explanation to from where the nvram file came out first. There are different brcmfmac4330-sdio.txt sources, with very different files for same wifi adapter and device (Cubox-i) I'm wondering what is the difference from the nvram .txt file for broadcom wifi firmware (brcmfmac4330-sdio.txt) between (A)solid-run:meta-solidrun-arm-imx6 (much longer with lots of additional parameters)https://github.com/SolidRun/meta-solidrun-arm-imx6/blob/fido/recipes-bsp/broadcom-nvram-config/files/solidrun-imx6/brcmfmac4330-sdio.txt (B)the one that ships with the Armbian image for Cubox-ihttps://github.com/igorpecovnik/lib/blob/master/bin/firmware-overlay/brcm/brcmfmac4330-sdio.txt I've been using this last one, because it shipped with the Debian image, but there are a lot of differences between them. After some tests, i can say both work and i don't see any noticeable differences. Wich one is "the correct" one, or at last, the most updated/better/nicer/bugless.
  4. No it´s not. The vanilla kernel 4.1 rc supports (without any patches) HDMI output much better than the solid-run kernel. Most video modes work in almost all kind of monitors. Enablement patches are mostly the Etna_Viv staging driver and DTS patches for supporting audio over HDMI ( Synopsis Designware AHB Audio interface) and support for Wifi+Bluetooth Broadcom brcm4330-sdio. Personally, i do not use the Etna_viv DRM staging driver and i can grant that the HDMI video output is vastly improved with stock unpatched 4.1rc. You can have a look to my .config file and base your work with it. It´s very stripped for my cubox-i DL. http://www.klezstyle.com/temp/config-4.1rc-klez.gz Proudly compiled in my Cubox-i DL with your debian Jessie image. I´ll be around for comments, see you. - Klez
  5. Hi, If you think that Solid-run Cubox-i kernel branch is becoming outdated, you can use a mainline linux kernel with the following enablement patches: Russell King home dir: http://www.home.arm.linux.org.uk/~rmk/cubox/?C=M;O=D Grab the most recent hummingboard-cubox-i DIFF big patch and patch it into your vanilla 4.1 kernel source dir. Then use a default config appropiate for a Cubox-i / Hummingboard: # make imx_v6_v7_defconfig hope it helps
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines