LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM
User Name
Password
Slackware - ARM This forum is for the discussion of Slackware ARM.

Notices


Reply
  Search this Thread
Old 03-24-2019, 04:56 AM   #46
justwantin
Member
 
Registered: Aug 2003
Location: Melbourne, Australia
Distribution: Slackware, Slackwarearm
Posts: 878

Rep: Reputation: 120Reputation: 120

Ah yes I thought you subscribed to this list ... g'day!.

I've heard of software engineers, hydraulic engineers, civil engineers etc. etc. But I had never until that day knew that you could get a degree in raspberry pi engineering .... good thing we both kept a civil tongue at least :-P
 
Old 03-24-2019, 12:42 PM   #47
drmozes
Slackware Contributor
 
Registered: Apr 2008
Distribution: Slackware
Posts: 1,531

Rep: Reputation: 1274Reputation: 1274Reputation: 1274Reputation: 1274Reputation: 1274Reputation: 1274Reputation: 1274Reputation: 1274Reputation: 1274
Quote:
Originally Posted by Penthux View Post
I was a little miffed at James' response to you. Still didn't get any answers to my questions about why they diminish Slackware ARM.
I looked at the response and in isolation, it's just pointing out a statement of (most likely) fact.
It's a business - I'm sure if there were enough people who wanted to run Slackware on it, they'd have a different response; but there isn't and so they don't.
In the same way as this _isn't_ a business for me and so I have really no interest at all in it.
As my daughter says, "get over it! It's already happened" (although she's hardly mastered the art of Zen when her favourite stuff gets smashed and I ironically instruct her to "get over it", but there's time!) ;-)
 
Old 03-24-2019, 05:58 PM   #48
Penthux
Member
 
Registered: Dec 2008
Location: Middlesbrough, UK
Distribution: Slackware
Posts: 264

Rep: Reputation: 74
Quote:
Originally Posted by drmozes View Post
I looked at the response and in isolation, it's just pointing out a statement of (most likely) fact.
You don't have to read the response in isolation. You can just read it as part of a social exercise with friends/family or with strangers in public on a mobile device! Trust me on this. It works!

Anyway, at the time of that RPi forum thread, I was churning out SARPi installers and packages at an alarming rate, and investing a _lot_ of time and effort into the project. As you know. When I read "other distros for which you may find it difficult to get help" in reference to Slackware ARM I thought it was rather ignorant, and certainly wasn't accurate or even near to the truth! The guy is the chief RPi software honcho and people ARE going to take notice of what he says. Can't have someone of Jamesh's status spreading disinformation and BS about something he [apparently] knows nothing about.

Quote:
Originally Posted by drmozes View Post
It's a business - I'm sure if there were enough people who wanted to run Slackware on it, they'd have a different response; but there isn't and so they don't.

In the same way as this _isn't_ a business for me and so I have really no interest at all in it.
I know the Slackware ARM user base pales in comparison to the vast numbers of Raspbian users. I'd still bet my last dollar that there's certainly more Slackers on the RPis than FreeBSD, Gentoo, OpenSUSE, Plan 9 and Puppy Linux users.

The interest _IS_ there for Slackware ARM... or I must be dreaming about the +150GB of binary downloads bandwidth per month that FatDog.NL accrues... and not every Slackware ARM installation on the RPi is done by using the SARPi shizzle.
 
1 members found this post helpful.
Old 03-26-2019, 03:47 PM   #49
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,634

Original Poster
Rep: Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929
Got some time to test the latest Slackware ARM - current kernel 4.19.31 on a Raspberry Pi2B by loading the initrd-armv7-4.19.31
Worth mentioning that the kernel, initrd and dtb collection Slackware ARM -current is currently offering is almost 50MB big.
It finally loads a driver (sdhost-bcm2835) for the SDCard and it mounts the root partition. Thanks drmozes!
However, because there is no DMA support, it falls back to PIO mode and that will put some overhead on the CPU(s).

Loaded on a minimalistic (4GB) Slackware ARM -current test system - screenshot initrd-armv7-4-19-31.jpg
https://www88.zippyshare.com/v/FhagMpHX/file.html

- content of /boot/config.txt
Code:
kernel=zImage-armv7-4.19.31
initramfs initrd-armv7-4.19.31
device_tree=dtb-4.19.31/bcm2836-rpi-2-b.dtb
avoid_warnings=2

gpu_mem=128
framebuffer_depth=32
dtparam=audio=on
audio_pwm_mode=2
- content of /boot/cmdline.txt
Code:
console=serial0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
The kernel installation script tries to create some symlinks and throws some errors that should be ignored - /boot is a FAT16 partition.
Code:
+==============================================================================
| Upgrading kernel_armv7-4.7.2-arm-1 package using ./kernel_armv7-4.19.31-arm-1.txz
+==============================================================================
Pre-installing package kernel_armv7-4.19.31-arm-1...
ln: failed to create symbolic link 'System.map-armv7': Operation not permitted
ln: failed to create symbolic link 'dtb': Operation not permitted
ln: failed to create symbolic link 'initrd-armv7': Operation not permitted
ln: failed to create symbolic link 'uImage-armv7': Operation not permitted
ln: failed to create symbolic link 'uinitrd-armv7': Operation not permitted
ln: failed to create symbolic link 'zImage-armv7': Operation not permitted
Just figured out that you could use the already compiled overlays that the Raspberry Foundation is providing, even if you don't build them (and they are not included in what Slackware ARM -current is currently providing). I thought they are pretty much bound to the kernel&device tree binaries, much like the kernel modules, but it looks like they are just compiled simple extensions to the already provided device tree binaries (bcm283*.dtb) and at least the IR receiver overlay - gpio-ir, the only one I tested, was working fine.
To get the Raspberry Foundation provided compiled overlays (development version), just run:
Code:
cd /boot
svn export https://github.com/raspberrypi/firmware/trunk/boot/overlays/
Some older version that you already have in /boot/overlays might also work, worth testing.
Speaking of overlays, in one of my previous posts I speculated that these might be not required anymore in the future and that the mainstream kernel won't support them. Now, reading through these links, I just found out that I was wrong and these overlays are here to stay:
https://www.raspberrypi.org/document...device-tree.md
(Part 2: Device Tree overlays)
https://docs.armbian.com/Hardware_Allwinner_overlays/
(Allwinner is also working to implement them)

Some other considerations for fully supporting the Raspberry Pi boards, SW components that are not provided by Slackware ARM -current.
The GPU Firmware that is needed to boot the board and enable the HW, it must reside in /boot and /boot must be a FAT16 partition:
https://github.com/raspberrypi/firmw...ster/README.md
Quote:
boot:
start*.elf, fixup*.dat and bootcode.bin are the GPU firmwares and bootloader. Their licence is described in boot/LICENCE.broadcom.
- basically, you need the following files to be available in /boot
Code:
COPYING.linux
LICENCE.broadcom
LICENSE.oracle
bootcode.bin
fixup.dat
fixup_cd.dat
fixup_db.dat
fixup_x.dat
issue.txt
start.elf
start_cd.elf
start_db.elf
start_x.elf
- get the development version of the GPU firmware files from:
https://github.com/raspberrypi/firmw...ee/master/boot

The GPU firmware (bootloader) configuration files /boot/config.txt & /boot/cmdline.txt need also to be present and contain relevant configuration directives - see the beginning of the post for a sample. Note that the kernel= / initramfs / device_tree= directives from /boot/config.txt need to be manually adjusted on every kernel upgrade because these are not taken care of by the Slackware ARM -current installation/upgrade script.

Device drivers firmware. Slackware ARM -current is offering the collection that is provided by the kernel.org, it's huge - over 400MB, I deliberately avoided mentioning it in my post #1 from this thread and chose some smaller alternatives instead, and it doesn't provide you with the required firmware for the WiFi & BT components on the Raspberry Pi3B(+).
Source:
https://git.kernel.org/pub/scm/linux...-firmware.git/
You can get the firmware (development version) for the WiFi & BT components directly from the Raspberry official repository:
Code:
mkdir /tmp/raspi-firmware/ && cd /tmp/raspi-firmware/
svn export https://github.com/RPi-Distro/firmware-nonfree/trunk/brcm/
cp -f brcm/* /lib/firmware/brcm/
wget -N -P /lib/firmware/brcm https://raw.githubusercontent.com/RPi-Distro/bluez-firmware/master/broadcom/BCM43430A1.hcd
wget -N -P /lib/firmware/brcm https://raw.githubusercontent.com/RPi-Distro/bluez-firmware/master/broadcom/BCM4345C0.hcd
cd /
rm -rf /tmp/raspi-firmware/

Last edited by abga; 03-26-2019 at 04:01 PM. Reason: typo
 
Old 03-26-2019, 03:56 PM   #50
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,634

Original Poster
Rep: Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929
@drmozes

We discussed over the core components of the kernel and I told you that I never touched the default kernel-included I/O, architecture, basic HW functionalities support when I configured a kernel. Actually I did and always crippled the kernel. I just leave them included =y, as they come by default "recommended" by the kernel folks, just in order to have them available/loaded when they're needed in the beginning of the boot process, before the root partition is available and being able to load them as modules.
I guess you asked me about the "rationale" behind this and my approach is (actually it was - I told you it became pointless nowadays to recompile the kernel, unless Raspberry provides you a broken one) to have it slimmed-down but not crippled. Crippled like in your case now with the lack of DMA support.
In my post #37 I've also mentioned that the CONFIG_DMA_BCM2835 might be required for proper SDCard functionality:
https://www.linuxquestions.org/quest...ml#post5975517

This is an "uncrippled" multi_v7_defconfig boot log snippet related to the SDCard driver for the 4.19.28 I built & currently using:
Code:
[    0.458054] sdhci: Secure Digital Host Controller Interface driver
[    0.460235] sdhci: Copyright(c) Pierre Ossman
[    0.462662] Synopsys Designware Multimedia Card Interface Driver
[    0.561556] sdhost-bcm2835 3f202000.mmc: loaded - DMA enabled (>1)
[    0.564005] sdhci-pltfm: SDHCI platform and OF driver helper
[    0.567928] ledtrig-cpu: registered to indicate activity on CPUs
[    0.570884] usbcore: registered new interface driver usbhid
[    0.573094] usbhid: USB HID core driver
[    0.575539] bcm2835-mbox 3f00b880.mailbox: mailbox enabled
[    0.578994] NET: Registered protocol family 17
[    0.581525] Key type dns_resolver registered
[    0.584673] ThumbEE CPU extension supported.
[    0.587099] Registering SWP/SWPB emulation handler
[    0.590301] Loading compiled-in X.509 certificates
[    0.599420] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 81, base_baud = 0) is a PL011 rev2
[    0.989593] mmc0: host does not support reading read-only switch, assuming write-enable
[    0.999607] mmc0: new high speed SDHC card at address aaaa
[    1.007102] mmcblk0: mmc0:aaaa SB16G 14.8 GiB
Since you're supporting only pretty modern armv7 (and above) with your Slackware ARM -current kernel, I suggest starting again clean with the default kernel config multi_v7_defconfig and move the core kernel included components that you change from =y to =m into your initial ramdisk. That's if you still consider providing the initial ramdisk, which looks to be pretty useless given the modern armv7 available RAM, well, pointless unless you want to boot from LAN and you need the network drivers available, of which you've got some squeezed in that almost 30MB big initrd file.

The CONFIG_MMC_BCM2835, that comes included by default (=y) doesn't show that it depends on CONFIG_DMA_BCM2835 (which also comes included by default (=y) ) & subsequently on general DMA support:
Code:
 .config - Linux/arm 4.19.28 Kernel Configuration
 > Device Drivers > MMC/SD/SDIO card support qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
  lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq Broadcom BCM2835 SDHOST MMC Controller support qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
  x CONFIG_MMC_BCM2835:                                                                                                                                                      x
  x                                                                                                                                                                          x
  x This selects the BCM2835 SDHOST MMC controller. If you have                                                                                                              x
  x a BCM2835 platform with SD or MMC devices, say Y or M here.                                                                                                              x
  x                                                                                                                                                                          x
  x Note that the BCM2835 has two SD controllers: The Arasan                                                                                                                 x
  x sdhci controller (supported by MMC_SDHCI_IPROC) and a custom                                                                                                             x
  x sdhost controller (supported by this driver).                                                                                                                            x
  x                                                                                                                                                                          x
  x If unsure, say N.                                                                                                                                                        x
  x                                                                                                                                                                          x
  x Symbol: MMC_BCM2835 [=y]                                                                                                                                                 x
  x Type  : tristate                                                                                                                                                         x
  x Prompt: Broadcom BCM2835 SDHOST MMC Controller support                                                                                                                   x
  x   Location:                                                                                                                                                              x
  x     -> Device Drivers                                                                                                                                                    x
  x       -> MMC/SD/SDIO card support (MMC [=y])                                                                                                                             x
  x   Defined at drivers/mmc/host/Kconfig:884                                                                                                                                x
  x   Depends on: MMC [=y] && (ARCH_BCM2835 [=y] || COMPILE_TEST [=n])
But the CONFIG_DMA_BCM2835 does:
Code:
   .config - Linux/arm 4.19.28 Kernel Configuration
 > Device Drivers > DMA Engine support qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
  lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq BCM2835 DMA engine support qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
  x There is no help available for this option.                                                                                                                              x
  x Symbol: DMA_BCM2835 [=m]                                                                                                                                                 x
  x Type  : tristate                                                                                                                                                         x
  x Prompt: BCM2835 DMA engine support                                                                                                                                       x
  x   Location:                                                                                                                                                              x
  x     -> Device Drivers                                                                                                                                                    x
  x       -> DMA Engine support (DMADEVICES [=y])                                                                                                                            x
  x   Defined at drivers/dma/Kconfig:132                                                                                                                                     x
  x   Depends on: DMADEVICES [=y] && ARCH_BCM2835 [=y]                                                                                                                       x
  x   Selects: DMA_ENGINE [=y] && DMA_VIRTUAL_CHANNELS [=y]                                                                                                                  x
Additional to that, basic SDCard controller support is included (=y) by default in the multi_v7_defconfig and in your .config file you changed that and externalized them as modules, without including them in the initial ramdisk. The majority of these ARM SBCs are using the SDCard as their "HardDrive" or permanent storage ...
Code:
 .config - Linux/arm 4.19.28 Kernel Configuration
 > Device Drivers > MMC/SD/SDIO card support qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
  lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq Secure Digital Host Controller Interface support qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
  x CONFIG_MMC_SDHCI:                                                                                                                                                        x
  x                                                                                                                                                                          x
  x This selects the generic Secure Digital Host Controller Interface.                                                                                                       x
  x It is used by manufacturers such as Texas Instruments(R), Ricoh(R)                                                                                                       x
  x and Toshiba(R). Most controllers found in laptops are of this type.                                                                                                      x
  x                                                                                                                                                                          x
  x If you have a controller with this interface, say Y or M here. You                                                                                                       x
  x also need to enable an appropriate bus interface.                                                                                                                        x
  x                                                                                                                                                                          x
  x If unsure, say N.                                                                                                                                                        x
  x                                                                                                                                                                          x
  x Symbol: MMC_SDHCI [=m]                                                                                                                                                   x
  x Type  : tristate                                                                                                                                                         x
  x Prompt: Secure Digital Host Controller Interface support                                                                                                                 x
  x   Location:                                                                                                                                                              x
  x     -> Device Drivers                                                                                                                                                    x
  x       -> MMC/SD/SDIO card support (MMC [=y])                                                                                                                             x
  x   Defined at drivers/mmc/host/Kconfig:47                                                                                                                                 x
  x   Depends on: MMC [=y] && HAS_DMA [=y]                                                                                                                                   x

  
   .config - Linux/arm 4.19.28 Kernel Configuration
 > Device Drivers > MMC/SD/SDIO card support qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
  lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq SDHCI platform and OF driver helper qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
  x CONFIG_MMC_SDHCI_PLTFM:                                                                                                                                                  x
  x                                                                                                                                                                          x
  x This selects the common helper functions support for Secure Digital                                                                                                      x
  x Host Controller Interface based platform and OF drivers.                                                                                                                 x
  x                                                                                                                                                                          x
  x If you have a controller with this interface, say Y or M here.                                                                                                           x
  x                                                                                                                                                                          x
  x If unsure, say N.                                                                                                                                                        x
  x                                                                                                                                                                          x
  x Symbol: MMC_SDHCI_PLTFM [=m]                                                                                                                                             x
  x Type  : tristate                                                                                                                                                         x
  x Prompt: SDHCI platform and OF driver helper                                                                                                                              x
  x   Location:                                                                                                                                                              x
  x     -> Device Drivers                                                                                                                                                    x
  x       -> MMC/SD/SDIO card support (MMC [=y])                                                                                                                             x
  x         -> Secure Digital Host Controller Interface support (MMC_SDHCI [=m])                                                                                             x
  x   Defined at drivers/mmc/host/Kconfig:120                                                                                                                                x
  x   Depends on: MMC [=y] && MMC_SDHCI [=m] 
#
#...
#... The Arasan sdhci controller (supported by MMC_SDHCI_IPROC) - alternative to CONFIG_MMC_BCM2835
# etc.
 
Old 03-27-2019, 11:42 AM   #51
drmozes
Slackware Contributor
 
Registered: Apr 2008
Distribution: Slackware
Posts: 1,531

Rep: Reputation: 1274Reputation: 1274Reputation: 1274Reputation: 1274Reputation: 1274Reputation: 1274Reputation: 1274Reputation: 1274Reputation: 1274
Quote:
Originally Posted by abga View Post
@drmozes

I guess you asked me about the "rationale" behind this and my approach is (actually it was - I told you it became pointless nowadays to recompile the kernel, unless Raspberry provides you a broken one) to have it slimmed-down but not crippled. Crippled like in your case now with the lack of DMA support.
In my post #37 I've also mentioned that the CONFIG_DMA_BCM2835 might be required for proper SDCard functionality:
I looked in Fedora's config, and theirs is a module too.

Quote:
Since you're supporting only pretty modern armv7 (and above) with your Slackware ARM -current kernel, I suggest starting again clean with the default kernel config multi_v7_defconfig and move the core kernel included components that you change from =y to =m into your initial ramdisk. That's if you still consider providing the initial ramdisk, which looks to be pretty useless given the modern armv7 available RAM, well, pointless unless you want to boot from LAN and you need the network drivers available, of which you've got some squeezed in that almost 30MB big initrd file.
I see your point, and there's the other side which is that I'd shift the size in to the Kernel instead.
I'm quite happy with the initrd solution and see no need to change it. I've added support for many devices over the years and simply add whatever's required to the initrd and occasionally compile in support if absolutely necessary.
I certainly won't be reverting to another Kernel configuration, when the one I have works perfectly for the systems I support, and has been tested for years.

If you want me to add anything to the initrd, you need to provide the module names. I won't be adding anything further peace meal and I unless there's some absolute necessity, nothing else will be =y.
 
Old 03-28-2019, 09:18 PM   #52
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,634

Original Poster
Rep: Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929
@drmozes
Based on the mainstream armv7(&v8) kernel "recipe" multi_v7_defconfig resulted .config file, generated by the following commands:
Code:
#tar -xpf linux-4.19.28.tar.xz
#cd linux-4.19.28/
#KERNEL=kernel7
#make multi_v7_defconfig
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  YACC    scripts/kconfig/zconf.tab.c
  LEX     scripts/kconfig/zconf.lex.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
#
# configuration written to .config
#
I am (again) presenting the Raspberry Pi, kernel included, related options that you might want to include in the initial ramdisk as modules:
Code:
#grep -E "BCM2835|RASP" .config | grep -e =y
CONFIG_ARCH_BCM2835=y
CONFIG_RASPBERRYPI_FIRMWARE=y
CONFIG_SERIAL_8250_BCM2835AUX=y
CONFIG_HW_RANDOM_BCM2835=y
CONFIG_I2C_BCM2835=y
CONFIG_SPI_BCM2835=y
CONFIG_SPI_BCM2835AUX=y
CONFIG_PINCTRL_BCM2835=y
CONFIG_GPIO_RASPBERRYPI_EXP=y
CONFIG_BCM2835_WDT=y
CONFIG_MMC_BCM2835=y
CONFIG_DMA_BCM2835=y
CONFIG_BCM2835_TIMER=y
CONFIG_BCM2835_MBOX=y
CONFIG_RASPBERRYPI_POWER=y
CONFIG_PWM_BCM2835=y
- without looking at Debilan, a distro that didn't & still doesn't impress me, strictly related to the system design and system configuration, nevertheless respecting their efforts and contribution for upstream patches & such. Found out that CONFIG_DMA_BCM2835=y isn't MMC related but the support for I2S DACs - still needed to be available before the actual I2S DAC audio driver loads.
- header-description of linux-4.19.28/drivers/dma/bcm2835-dma.c
Code:
 * BCM2835 DMA engine support
 *
 * This driver only supports cyclic DMA transfers
 * as needed for the I2S module.
- DMA support to be included in the initial ramdisk, just to "uncripple" your otherwise working & tested for the platforms you support kernel, never stated otherwise. Here I couldn't search for patterns because there are plenty of "DMA" references. Instead, just took out copy/paste the DMA support related section:
Code:
CONFIG_DMADEVICES=y
# CONFIG_DMADEVICES_DEBUG is not set

#
# DMA Devices
#
CONFIG_ASYNC_TX_ENABLE_CHANNEL_SWITCH=y
CONFIG_DMA_ENGINE=y
CONFIG_DMA_VIRTUAL_CHANNELS=y
CONFIG_DMA_OF=y
# CONFIG_ALTERA_MSGDMA is not set
# CONFIG_AMBA_PL08X is not set
CONFIG_AT_HDMAC=y
CONFIG_AT_XDMAC=y
# CONFIG_AXI_DMAC is not set
CONFIG_DMA_BCM2835=y
CONFIG_DMA_SUN4I=y
CONFIG_DMA_SUN6I=y
# CONFIG_DW_AXI_DMAC is not set
CONFIG_FSL_EDMA=y
CONFIG_IMX_DMA=y
CONFIG_IMX_SDMA=y
# CONFIG_INTEL_IDMA64 is not set
# CONFIG_K3_DMA is not set
CONFIG_MV_XOR=y
CONFIG_MXS_DMA=y
CONFIG_MX3_IPU=y
CONFIG_MX3_IPU_IRQS=4
# CONFIG_NBPFAXI_DMA is not set
CONFIG_PL330_DMA=y
CONFIG_SIRF_DMA=y
CONFIG_STE_DMA40=y
CONFIG_ST_FDMA=m
CONFIG_STM32_DMA=y
CONFIG_STM32_DMAMUX=y
CONFIG_STM32_MDMA=y
CONFIG_TEGRA20_APB_DMA=y
CONFIG_XILINX_DMA=y
# CONFIG_XILINX_ZYNQMP_DMA is not set
# CONFIG_MTK_HSDMA is not set
CONFIG_QCOM_BAM_DMA=y
# CONFIG_QCOM_HIDMA_MGMT is not set
# CONFIG_QCOM_HIDMA is not set
CONFIG_DW_DMAC_CORE=y
CONFIG_DW_DMAC=y
# CONFIG_DW_DMAC_PCI is not set
CONFIG_RENESAS_DMA=y
CONFIG_SH_DMAE_BASE=y
CONFIG_SH_DMAE=y
CONFIG_SH_DMAE_R8A73A4=y
CONFIG_RCAR_DMAC=y
CONFIG_RENESAS_USB_DMAC=m
# CONFIG_SUDMAC is not set
CONFIG_TI_CPPI41=m
CONFIG_TI_EDMA=y
CONFIG_DMA_OMAP=y
CONFIG_TI_DMA_CROSSBAR=y

#
# DMA Clients
#
# CONFIG_ASYNC_TX_DMA is not set
# CONFIG_DMATEST is not set
CONFIG_DMA_ENGINE_RAID=y

#
# DMABUF options
#
CONFIG_SYNC_FILE=y
# CONFIG_SW_SYNC is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
# CONFIG_VFIO is not set
# CONFIG_VIRT_DRIVERS is not set
CONFIG_VIRTIO=y
CONFIG_VIRTIO_MENU=y
CONFIG_VIRTIO_PCI=y
CONFIG_VIRTIO_PCI_LEGACY=y
# CONFIG_VIRTIO_BALLOON is not set
# CONFIG_VIRTIO_INPUT is not set
CONFIG_VIRTIO_MMIO=y
# CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES is not set
- And if you'd like to add generic MMC/SDCards support, here are the options you might want to include in the initial ramdisk:
Code:
# grep -e MMC .config | grep =y
CONFIG_MMC=y
CONFIG_PWRSEQ_EMMC=y
CONFIG_MMC_BLOCK=y
CONFIG_MMC_ARMMMCI=y
CONFIG_MMC_QCOM_DML=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_IO_ACCESSORS=y
CONFIG_MMC_SDHCI_PLTFM=y
CONFIG_MMC_SDHCI_OF_ARASAN=y
CONFIG_MMC_SDHCI_OF_AT91=y
CONFIG_MMC_SDHCI_OF_ESDHC=y
CONFIG_MMC_SDHCI_ESDHC_IMX=y
CONFIG_MMC_SDHCI_DOVE=y
CONFIG_MMC_SDHCI_TEGRA=y
CONFIG_MMC_SDHCI_S3C=y
CONFIG_MMC_SDHCI_PXAV3=y
CONFIG_MMC_SDHCI_SPEAR=y
CONFIG_MMC_SDHCI_S3C_DMA=y
CONFIG_MMC_SDHCI_BCM_KONA=y
CONFIG_MMC_SDHCI_IPROC=y
CONFIG_MMC_MESON_MX_SDIO=y
CONFIG_MMC_SDHCI_ST=y
CONFIG_MMC_OMAP=y
CONFIG_MMC_OMAP_HS=y
CONFIG_MMC_ATMELMCI=y
CONFIG_MMC_SDHCI_MSM=y
CONFIG_MMC_MVSDIO=y
CONFIG_MMC_TMIO_CORE=y
CONFIG_MMC_SDHI=y
CONFIG_MMC_SDHI_SYS_DMAC=y
CONFIG_MMC_DW=y
CONFIG_MMC_DW_PLTFM=y
CONFIG_MMC_DW_EXYNOS=y
CONFIG_MMC_DW_ROCKCHIP=y
CONFIG_MMC_SH_MMCIF=y
CONFIG_MMC_WMT=y
CONFIG_MMC_SUNXI=y
CONFIG_MMC_CQHCI=y
CONFIG_MMC_BCM2835=y
CONFIG_MMC_SDHCI_BRCMSTB=y
CONFIG_MMC_SDHCI_OMAP=y
# cut here - last 3 ones are unrelated to the MMC section
CONFIG_APQ_MMCC_8084=y
CONFIG_MSM_MMCC_8960=y
CONFIG_MSM_MMCC_8974=y
Now, just an end note to this thread I consider solved and done. I'm not asking you personally anything, I'm fine with my kernel build and documented the steps for the Slackware fellows who might be interested in building their own downstream&mainstream Raspberry kernels.
In post #6 I presented what the Slackware ARM -current kernel is missing and in #8 I indirectly expressed my "hope" that you might want to consider starting supporting the Raspberry boards. Happy that you got involved in #15 and that your contribution could make (ARM)Slackers happy. I'm trying to stay suggestive (if that's the proper word) and collaborative, not really asking for anything, especially in such cases in which I just documented the whole thing and able to self-service. I can't use your kernel, not only because I consider it crippled (TBH, I couldn't even use your config file to start with, just dumped it after I noticed that it was pretty much butchered and (meaninglessly) core components options changed from included to modules), but also because I always need some extra options and patches(DVB). I also don't have time to play with different kernels, but build, test and maintain one, until I consider it's worth upgrading. Still, happy to help you with Raspberry armv7 related kernel tests.

Last edited by abga; 03-28-2019 at 09:41 PM. Reason: formatting & typo
 
Old 03-29-2019, 05:45 AM   #53
drmozes
Slackware Contributor
 
Registered: Apr 2008
Distribution: Slackware
Posts: 1,531

Rep: Reputation: 1274Reputation: 1274Reputation: 1274Reputation: 1274Reputation: 1274Reputation: 1274Reputation: 1274Reputation: 1274Reputation: 1274
[QUOTE=abga;5979017]

Code:
CONFIG_MMC_BLOCK=y
CONFIG_MMC_ARMMMCI=y
CONFIG_MMC_QCOM_DML=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_IO_ACCESSORS=y
CONFIG_MMC_SDHCI_PLTFM=y
CONFIG_MMC_SDHCI_OF_ARASAN=y
CONFIG_MMC_SDHCI_OF_AT91=y
CONFIG_MMC_SDHCI_OF_ESDHC=y
CONFIG_MMC_SDHCI_ESDHC_IMX=y
CONFIG_MMC_SDHCI_DOVE=y
CONFIG_MMC_SDHCI_TEGRA=y
CONFIG_MMC_SDHCI_S3C=y
CONFIG_MMC_SDHCI_PXAV3=y
CONFIG_MMC_SDHCI_SPEAR=y
CONFIG_MMC_SDHCI_S3C_DMA=y
CONFIG_MMC_SDHCI_BCM_KONA=y
CONFIG_MMC_SDHCI_IPROC=y
CONFIG_MMC_MESON_MX_SDIO=y
CONFIG_MMC_SDHCI_ST=y
CONFIG_MMC_OMAP=y
CONFIG_MMC_OMAP_HS=y
CONFIG_MMC_ATMELMCI=y
CONFIG_MMC_SDHCI_MSM=y
CONFIG_MMC_MVSDIO=y
CONFIG_MMC_TMIO_CORE=y
CONFIG_MMC_SDHI=y
CONFIG_MMC_SDHI_SYS_DMAC=y
CONFIG_MMC_DW=y
CONFIG_MMC_DW_PLTFM=y
CONFIG_MMC_DW_EXYNOS=y
CONFIG_MMC_DW_ROCKCHIP=y
CONFIG_MMC_SH_MMCIF=y
CONFIG_MMC_WMT=y
CONFIG_MMC_SUNXI=y
CONFIG_MMC_CQHCI=y
CONFIG_MMC_BCM2835=y
CONFIG_MMC_SDHCI_BRCMSTB=y
CONFIG_MMC_SDHCI_OMAP=y
# cut here - last 3 ones are unrelated to the MMC section
CONFIG_APQ_MMCC_8084=y
CONFIG_MSM_MMCC_8960=y
CONFIG_MSM_MMCC_8974=y
Really, The Rpi needs all of these does it?

Quote:
I'm trying to stay suggestive (if that's the proper word) and collaborative, not really asking for anything, especially in such cases in which I just documented the whole thing and able to self-service. I can't use your kernel, not only because I consider it crippled (TBH, I couldn't even use your config file to start with, just dumped it after I noticed that it was pretty much butchered and (meaninglessly)
Dude, I don't know if you realise this or not but to me, you just present yourself as seriously rude. It's a config file with settings in it. "Butchered" ?
Do you know what this implies? It implies someone's hacked it up to bits with no consideration.
I mean, seriously do you have any clue about the amount of time that has gone in to this project to make it work? It's built on YEARS of work, and things were done for a reason and were well thought out.. .. and ..

Quote:
core components options changed from included to modules), but also because I always need some extra options and patches(DVB). I also don't have time to play with different kernels, but build, test and maintain one, until I consider it's worth upgrading.
You don't have time, but I do and you expect me to take all this stuff? Start again with a new config, dump initrd? LOL. Get real man.

Last edited by drmozes; 03-29-2019 at 05:51 AM.
 
2 members found this post helpful.
Old 03-29-2019, 12:42 PM   #54
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,634

Original Poster
Rep: Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929
Here we go again...
Look now, there's no reason I should be rude and it looks like you're over sensitive, or maybe, looking back to our interactions, tendentiously misinterpreting and overreacting. I was honestly considering that maybe you're a female and briefly checked your LinkedIn profile, noticing that you're younger and less experienced (both technically and social sciences (business) related, not to mention the organizing and responsibilities experience difference (these are the only facts I can present about myself by still respecting my privacy)).
That's all about the non-technical, distorted, personal "stuff" (I might call it rubbish - but then you'll say again that I'm "rude") you wrote in your last post.

The MMC/SD list you quoted has nothing to do with the RPi, it's written in the sentence preceding it, but strictly related to the generic MMC/SDCards support and it was a suggestion we discussed earlier in this thread. Obviously, not all those options are required , there are some specific HW related options that you can safely omit.
I used the word "butchered" and also "(meaninglessly)" to distinguish the action that was applied over your kernel config form the optimized/configured one, which would require to respect the kernel dependencies hierarchical structure in the first place, what I called core components, and only then considering the size optimizations.
Speaking of size optimizations, you might find this thread interesting:
https://unix.stackexchange.com/quest...the-kernel-use
I also called your kernel crippled because it lacks DMA support, missed that one over the "YEARS of work" and suggested to fix it. I fear that there are some other such options required and removed (changed to =m) and not available in the initial ramdisk, but as I said, I dumped your kernel config when I started this mainstream kernel compilation and also haven't played with your latest Rpi enabled kernel after noticing it lacks DMA support - post #49 - screenshot.

This I need to quote, because is wrong in every letter:
Quote:
You don't have time, but I do and you expect me to take all this stuff? Start again with a new config, dump initrd? LOL. Get real man.
I said I don't expect anything from you, happy that you're compiling and maintaining the original Slackware X86 distro for ARM, you have my full appreciation for that. Start with a new config because fixing the actual, reverting the changes, respecting the recommended core support and dependencies structure (without necessarily following what the Debilan is doing) looks more time consuming to me (your kernel .config - multi_v7_defconfig diff file has almost 10000 lines!). Then you'd also need to check what's inside the actual initial ramdisk and you get a second (diff) list you need to follow. I never said you should dump the initial ramdisk support, I only said it looks pointless for general use these days, considering the RAM availability on modern HW, but still useful in some particular cases and I suggested to include in this initial ramdisk the "core options" you move from =y to =m.

If you have some particular technical questions or like me to test your Rpi kernel support for armv7, I'm always happy to help.

Last edited by abga; 03-29-2019 at 02:28 PM. Reason: proceeding = preceding
 
Old 03-29-2019, 02:52 PM   #55
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware AArch64
Posts: 1,043

Rep: Reputation: 665Reputation: 665Reputation: 665Reputation: 665Reputation: 665Reputation: 665
Quote:
Originally Posted by abga View Post
Here we go again...
Look now, there's no reason I should be rude and it looks like you're over sensitive, or maybe, looking back to our interactions, tendentiously misinterpreting and overreacting. I was honestly considering that maybe you're a female and briefly checked your LinkedIn profile, noticing that you're younger and less experienced (both technically and social sciences (business) related, not to mention the organizing and responsibilities experience difference (these are the only facts I can present about myself by still respecting my privacy)).
That's all about the non-technical, distorted, personal "stuff" (I might call it rubbish - but then you'll say again that I'm "rude") you wrote in your last post.
Hey... this rubbish has no place on LQ and besides that; just who do you think you are to question the work, efforts, reasons, results, or anything relating to Slackware ARM regarding MoZes? If MoZes does something because he's wearing bright blue Calvin's and/or eats +3 oranges that day then that's HIS call... NOT yours! It's not appropriate or legitimate to negatively question "WHY?" things are as they appear to be if they don't specifically suit you. It's not wise to be disrespectful because you're not getting what you want. That's just petulance.

MoZes does what he wants to do and then he decides to share the work. So, it most likely will _not_ be tailored to your specific requirements. It's YOUR job to make it how you want it to be. We are at least afforded that ability with the software MoZes releases. Sometimes that will be easy and other times it will be hard as hell. That being said, it's not MoZes' responsibility to do anything other than what _HE_ wants to do! We are all eternally and perpetually grateful for the work and information he shares and makes available.

In the past MoZes has [very rarely] asked me to include certain things for the RPi in the SARPi installers and packages because it's purely RPi exclusive shizzle. Sometimes it makes good sense to do it. Other times it's not. Either way, I get that he has no interest in the RPi; as has been stated multiple times in this thread! Why don't you?

If MoZes starts to support the RPi he'll be putting me out of a job. That means I'll have to hunt him down and challenge him to a space-hopper race. Slackware ARM on a Raspberry Pi is what _I_ do. So MoZes doesn't have to bother because he has zero interest in it. It's all taken care of in the SARPi shizzle. You don't have to use it. You can do your own thing if you prefer. For shizzle regarding Slackware ARM on a Raspberry Pi... http://sarpi.fatdog.eu

Slackware seriously has too much integrity for this BS!
 
5 members found this post helpful.
Old 03-29-2019, 04:21 PM   #56
drmozes
Slackware Contributor
 
Registered: Apr 2008
Distribution: Slackware
Posts: 1,531

Rep: Reputation: 1274Reputation: 1274Reputation: 1274Reputation: 1274Reputation: 1274Reputation: 1274Reputation: 1274Reputation: 1274Reputation: 1274
Quote:
Originally Posted by abga View Post
Here we go again...
Look now, there's no reason I should be rude and it looks like you're over sensitive, or maybe, looking back to our interactions, tendentiously misinterpreting and overreacting. I was honestly considering that maybe you're a female and briefly checked your LinkedIn profile, noticing that you're younger and less experienced (both technically and social sciences (business) related, not to mention the organizing and responsibilities experience difference (these are the only facts I can present about myself by still respecting my privacy)).
That's all about the non-technical, distorted, personal "stuff" (I might call it rubbish - but then you'll say again that I'm "rude") you wrote in your last post.
Over sensitive, and you spend how long going and researching past interactions and my linked in profile? That's response alone implies a sensitivity on your part. And calling me female? I cracked up laughing at that - rude _and_ makes me laugh. You're quite a character. However, I won't try to find out who you are or suggest that you're any sex at all, since it's of no relevance.

Not sure what my experience listed on a public profile has _anything_ whatsoever to do with how I conduct and manage a hobby project?
There's no link at all. As I pointed out, if this was a business, I'd have supported the RPi myself long ago - just like I did for the stuff I'm interested in.

As _I_ recall from the past interactions, you tend to take a fact and link it to something unrelated in order to prove yourself right - it seems to me.
I decided this time to look at your technical reasons and separate them from your approach, as some of them were useful. However, I don't feel like doing that any longer.

It's a shame really. You could have had RPi support in the Kernel already, but I won't work with you on this.
Someone else, I may do.

Last edited by drmozes; 03-29-2019 at 04:26 PM.
 
Old 03-29-2019, 05:13 PM   #57
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,634

Original Poster
Rep: Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929
Quote:
Originally Posted by drmozes View Post
It's a shame really. You could have had RPi support in the Kernel already, but I won't work with you on this.
Someone else, I may do.
Indeed, a shame, you had the list of options to include in your kernel required for supporting the Rpi some over 2 weeks and 30 posts back and in the meantime I provided a lot of details every time you needed them. Started to wonder if you really want to do it, or maybe it requires "YEARS of work" - that's speaking of time management.
As said, I personally don't need your kernel for the reasons I presented in my previous posts, not in its actual crippled state.
Happy to help on technical issues and share my experience if you need it.
 
Old 03-30-2019, 03:32 AM   #58
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware AArch64
Posts: 1,043

Rep: Reputation: 665Reputation: 665Reputation: 665Reputation: 665Reputation: 665Reputation: 665
Quote:
Originally Posted by abga View Post
I provided a lot of details every time you needed them. Started to wonder if you really want to do it, or maybe it requires "YEARS of work" - that's speaking of time management.
You provided a lot of details every time... whether they were requested, required, or not! You cannot expect someone to give you help simply because you're inundating them with masses of information.

Quote:
Originally Posted by abga View Post
As said, I personally don't need your kernel for the reasons I presented in my previous posts, not in its actual crippled state.
Happy to help on technical issues and share my experience if you need it.
It's not crippled. It's a working kernel. You just don't seem to understand how, or have the ability, to configure it accordingly!
 
Old 03-30-2019, 05:12 PM   #59
justwantin
Member
 
Registered: Aug 2003
Location: Melbourne, Australia
Distribution: Slackware, Slackwarearm
Posts: 878

Rep: Reputation: 120Reputation: 120
Quote:
As said, I personally don't need your kernel for the reasons I presented in my previous posts, not in its actual crippled state.
Then what's the big fuss?
 
Old 03-30-2019, 11:22 PM   #60
glorsplitz
Senior Member
 
Registered: Dec 2002
Distribution: slackware!
Posts: 1,304

Rep: Reputation: 368Reputation: 368Reputation: 368Reputation: 368
Quote:
Originally Posted by Exaga View Post
Slackware seriously has too much integrity for this BS!
so you do still exist Exaga, cheers!
 
1 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] KODI Leia - 18.x MediaPlayer - Optimized for Raspberry Pi1/Zero/Pi2B/Pi3B(+) on Slackware ARM 14.2 SF & Slackware ARM - current HF abga Slackware - ARM 25 04-29-2020 05:43 PM
[SOLVED] KODI Krypton - 17.x MediaPlayer - Optimized for Raspberry Pi1/Pi2/Pi3 on Slackware ARM 14.2 SF & Slackware ARM - current HF abga Slackware - ARM 40 08-28-2018 08:50 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM

All times are GMT -5. The time now is 04:42 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration