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 |
Quote:
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!) ;-) |
Quote:
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:
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. :p |
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 Code:
console=serial0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait Code:
+============================================================================== To get the Raspberry Foundation provided compiled overlays (development version), just run: Code:
cd /boot 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:
Code:
COPYING.linux 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/ |
@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 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 Code:
.config - Linux/arm 4.19.28 Kernel Configuration Code:
.config - Linux/arm 4.19.28 Kernel Configuration |
Quote:
Quote:
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. |
@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 Code:
#grep -E "BCM2835|RASP" .config | grep -e =y - header-description of linux-4.19.28/drivers/dma/bcm2835-dma.c Code:
* BCM2835 DMA engine support Code:
CONFIG_DMADEVICES=y Code:
# grep -e MMC .config | grep =y 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. |
[QUOTE=abga;5979017]
Code:
CONFIG_MMC_BLOCK=y Quote:
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:
|
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:
If you have some particular technical questions or like me to test your Rpi kernel support for armv7, I'm always happy to help. |
Quote:
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! |
Quote:
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. |
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. Happy to help on technical issues and share my experience if you need it. |
Quote:
Quote:
|
Quote:
|
Quote:
|
All times are GMT -5. The time now is 12:17 PM. |