Quote:
|
Quote:
Quote:
|
I started the compilation for the 5.0 kernel on this Pi2B test machine and my SDCard blew up :) It lasted more than 2 years of constant Slackware ARM -current updates, a lot of personal hammering and small compilations, a dozen Kodi compilations and several kernel compilations.
Frankly, I recommend Samsung EVO cards, true heroes, it also failed gracefully - got stuck in read-only mode, no data corruption/loss. Will put it in a frame... I took this as a sign "from above" or "below", depending on your beliefs, and used the mainstream 4.19.28 kernel instead. Did some changes to the kernel config - basically including the CPU frequency governors in the kernel and compiling cpufreq-dt as a module, just to have some more control over it. Code:
diff old-kernel-config new-kernel-config The Pi2B switches between 600Mhz and 900Mhz. - cat bcm2836.dtsi-patch Code:
--- bcm2836.dtsi.orig 2019-03-17 10:11:43 Code:
bcmstat.sh A Taking a closer look: Code:
cat /proc/interrupts https://www.raspberrypi.org/forums/v...ic.php?t=13058 https://www.raspberrypi.org/forums/v...7866&start=125 Raspberry Foundation - dwc_otg downstream Fix: https://www.raspberrypi.org/forums/v...ic.php?t=70437 Commits: https://github.com/raspberrypi/linux...b98e5df9585550 https://github.com/raspberrypi/linux...0c4a990efb0877 Personally, I can live with this, not sensing a huge overhead because of it and my DVB tuners and Ethernet adapter are doing great. BTW, absolutely no "Continuity counter error" on my DVB adapters and the channels switching is faster. There's another cosmetic issue you might encounter: - dmesg: Code:
[ 1.629795] dwc2 3f980000.usb: 3f980000.usb supply vusb_d not found, using dummy regulator https://patchwork.kernel.org/patch/10820563/ In my post #5 I presented a patch for the Makefile.dtbinst, inspired by the Raspberry Foundation kernel source, to enable the automatic installation of the overlays files by using the make target: make dtbs_install Never tested it, but copied the files manually. I did stress @Dunc. with a lot of questions, presuming he used the "make dtbs_install" because he followed the gentoo wiki howto, but I doubt he used the overlays. Now I got my own answers and patching Makefile.dtbinst seems futile: make dtbs_install - copied dtb files in: /boot/dtbs/4.19.28/ - & overlays in: /boot/dtbs/4.19.28/overlays/ Learned that the overlays are not relative (subfolder) to the dtb files, but must reside in /boot/overlays . I had to manually move them there. Therefore, instead of "make dtbs_install", backup & move (clean) your actual /boot stuff and better use the sequence: Code:
cp -f arch/arm/boot/dts/bcm283*.dtb /boot/ https://www57.zippyshare.com/v/BSda25AY/file.html Code:
sha256sum patched-files-kernel-config-mainstream-4-19-28.tgz Don't mind the CPU frequency graph, it mainly stays at 600Mhz, Monitorix creates itself some overhead when gathering the stats - it runs a perl script that pushes the CPU briefly at 900Mhz... https://imgur.com/a/jdsnkj8 @drmozes Your kernel doesn't boot because you're compiling the SDCard driver as a module, so it gets stuck while trying to mount the root partition and load the modules ... You should fully respect the list I provided - I just took it myself from the Raspberry Foundation default kernel config. Related to the bcm2835-cpufreq-add-CPU-frequency-control-driver.patch . After you apply it, you'll find the CONFIG_CLK_RASPBERRYPI_CPU=y in menuconfig: Device Drivers ---> Common Clock Framework --->[*] Raspberry Pi CPU clock driver (CONFIG_CLK_RASPBERRYPI_CPU=y) This is the only CPU frequency scaling method that works ATM and it's apparently using: https://www.kernel.org/doc/Documenta...cpufreq-dt.txt Regarding the ARM future, I'm waiting for the Raspberry Pi4 and hope they'll fit it with something like: https://www.theregister.co.uk/2018/1...napdragon_8cx/ https://www.pcworld.com/article/3325...mance-gap.html and keep the price at 35 quid. Actually I'll pay 50 for it...just saying :) @SCerovec Nope, I would've insisted on that VPN test, but the youtube review I posted there was convincing. That SoC starts to overheat & throttle in seconds. Not interested, thank you. |
Quote:
I don't know about the boot loader for the RPi but if it's capable of loading an initial RAM risk from the SD card (it has to be), then the modules can be loaded from the initial RAM disk - as happens for the USB and SCSI support for the devices I support. You have to be judicious about what's added, as the Kernel simply won't boot after it reaches a certain size (unless that's changed, but I used to have difficulties managing the size of the Kernel until I switched to the initrd). If you were only talking about CONFIG_MMC=y with the individual drivers as modules, that's ok - I've changed that. Quote:
|
Quote:
I guess it could be set up to run as single core as well, maybe even handle it at 1.2GHz then? I see your point, tho. |
I just compiled the mainstream 4.19.28 on Slackware ARM 14.2 for Pi Zero - I have two live boards that I use for Kodi.
Used the Pi1 kernel config defaults: Code:
make bcm2835_defconfig Adapted bcm2835.dtsi for the 700MHz-1GHz CPU frequency scaling: - cat bcm2835.dtsi-pi-zero-patch : Code:
--- bcm2835.dtsi.orig 2019-03-19 Code:
bcmstat.sh A There are two issues I can't resolve ATM. I cannot use the sound adapters I manufactured (copied the schematics from Pi3B and attached them over the GPIO) and the mainstream GL enabled Broadcom VC4 DRM Driver (graphics) doesn't look to be working with Kodi. First of all, for the analogue sound, I'm rerouting the internal (and not connected on the Pi Zero) SoC PWM pins to the GPIO connector in /boot/config.txt with the following line (calling the pwm-2chan overlay): Code:
dtoverlay=pwm-2chan,pin=18,func=2,pin2=13,func2=4 Code:
[ 0.322727] pinctrl-bcm2835 20200000.gpio: pin gpio18 already requested by 20200000.gpio; cannot claim for 2020c000.pwm - Kodi linked to the GL drivers in /opt/vc, it segfaults and I get: Code:
failed to add service - already in use? Code:
[ 197.724205] vc4_hdmi 20902000.hdmi: ASoC: can't open interface 20902000.hdmi: -19 Code:
gbm: failed to open any driver (search paths /usr/lib/xorg/modules/dri) |
Quote:
I suggested to respect that list I provided, not because it looked "monolithic", but because it looked sane, as previously mentioned, core HW devices shouldn't be subject of external modules, and because I'm not sure if only CONFIG_MMC_BCM2835=y will suffice, might also need the DMA driver CONFIG_DMA_BCM2835=y Looking at the kernel log: https://pastebin.com/FACEgjws I see that it also attaches to the firmware, before mounting the partitions, so CONFIG_RASPBERRYPI_FIRMWARE=y might be also needed for proper functionality of the HW. I do understand your size concerns, but mine are more related to the compatibility with other ARM platforms if you enable too many Raspberry specific support options. I cannot run any such compat tests because I only own Raspberry ARM boards... On the initrd/initramfs, it looks possible, never considered it on the Pi until you mentioned it now: https://www.raspberrypi.org/forums/viewtopic.php?t=7626 https://www.raspberrypi.org/forums/v...c.php?t=100609 |
Quote:
I believe it would be more accurate to say, "happy that you are willing to 'add support for' the Pi boards in the kernel." That being said, it would be somewhat of a monumental ball-grinding task to fully support all of the Pi boards for someone who has little or no interest in the device(s). Especially for someone who doesn't even own one of them! If MoZes is willing to add support for the RPis then he's doing the Slackware ARM community nothing less than a huge service and big favour. Though he'd be adding support for an ARM device whose creator(s) don't give a flying-FSCK about Slackware ARM. In fact, the Raspberry Pi Trading Ltd are alarmingly silent (i.e. reticent and non-committal) about the best educational Linux OS they could install on their ARM devices. I have much personal experience of this. Sadly. On compiling the mainstream kernel: I've done it dozens of times with a multitude of different kernel versions. Sometimes successfully, sometimes not. What I've learned from my experience is; it's not worth the time and effort. Unless you're doing it for educational reasons, or you're a Linux purist who thinks running anything except the mainstream kernel is heresy, then I'd advise that you ARE wasting your time. The RPi GitHub kernel just works without much messing about. It makes sense to use the RPi kernel on the device that the mainstream kernel was intentionally bastardized for. It's as easy to configure and compile as any other kernel - with the added assurance that it will work on the RPis, unless you haphazardly do something to negate that eventuality. Quote:
Quote:
I've had to do quite a bit of messing around with deciding what to add and leave out of the initrd because the size can be an issue. If it's too big there'll be overlap in memory and then the fun and games begin. |
Quote:
Whether that limit is now a thing of the past already (I think it is, as I recall noticing an email thread about it years ago) or not, it's ancillary to the fact that a smaller Kernel means smaller RAM footprint, faster to load and potentially is slightly more secure (only due to some module not being loaded, that subsequently presents an attack vector). Having a single Kernel support multiple hardware groups is what initial RAM disks were created for. Quote:
|
Quote:
Quote:
Then, based on your size concerns, you added all those kernel options as modules, not providing a SDCard driver included in the kernel, hence the failed boot. Discussing these options now, I became curious over how these made their way into the mainstream kernel: https://raw.githubusercontent.com/to...i_v7_defconfig Code:
# grep -E "BCM2835|RASP" multi_v7_defconfig Quote:
https://wiki.gentoo.org/wiki/Raspber..._to_Bootloader I'm happy to test your build on my Pi2B, if you consider such an approach. There are some U-Boot efforts for the Raspberry Pis, but none look mature enough: https://elinux.org/RPi_U-Boot#Get_the_source And I doubt they'll ever be, those Raspberry firmware binary blobs (BIOS) take care of many HW/SoC functions, warranty stuff included. Quote:
Even now, much like yourself, I have the tendency to remove all the stuff I identify as not useful. Making things worse, in my first mainstream kernel compilation for the Raspberry, in the Multimedia Support > DVB section I found an option to let the kernel "automagically" choose the DVB components, must have been inspired by the Redmond philosophy, and used it. Only to find out after the first boot, that one of the DVB tuners I use was not "automagically" chosen... I just went for another compilation and manually enabled all the DVB stuff as modules. I don't know if this helps, as it doesn't represent the "depends on" tags, but the interactive map, exploring the kernel, looks useful: http://www.makelinux.net/kernel_map/ |
Quote:
Quote:
In the end, my approach is straight forward: Can it be included in the initrd and the system work? Yes, goes in initrd. If it can't, it's compiled in. I was going to use the example of the filesystem drivers, but even those I have as modules. If it's going to be a pain in the ass and I'm not interested in it anyway, it gets dumped :-) I need to lie down now after looking at that!! ;-) |
@drmozes
Just tried your latest kernel 4.19.30 and it still won't recognize the SDCard drive. Normal boot, loading zImage-armv7. - content of /boot/config.txt Code:
kernel=zImage-armv7 https://www95.zippyshare.com/v/71vBswK6/file.html Checked the Raspberry bootloader to see if it'll tolerate the initrd-armv7. - content of /boot/config.txt Code:
kernel=zImage-armv7 https://www50.zippyshare.com/v/2t2Sr6pJ/file.html But then, you're still loading CONFIG_MMC_BCM2835=m as a module, no SDCard driver included in the kernel and no wonder it cannot mount the partitions... http://ftp.arm.slackware.com/slackwa...s/armv7/config Code:
# grep -E "BCM2835|RASP" config |
Just an observation and a workaround for the mainstream kernel and the bcm2835-cpufreq-add-CPU-frequency-control-driver.patch, plus the subsequent bcm2836.dtsi presented in post #33, for the Pi2B dynamic frequency scaling.
I noticed that the core frequency will stay always at the default 250MHz, just the arm frequency will dynamically change based on the load. With the official Raspberry kernel and their frequency scaling driver, this core frequency is dynamically changing: 250MHz-300MHz. Reference on the different components frequencies: https://www.raspberrypi.org/document...verclocking.md (core_freq - "but there is a small benefit for SDRAM on the Pi 2/Pi 3") I added in /boot/config.txt: Code:
core_freq=300 raspberrypi1z.1day.png - the cyan (core) graph https://www54.zippyshare.com/v/Qx62HZGG/file.html |
Slightly off topic but perhaps apropos:
About 5 years ago in a thread on the the raspberry pi forum when looking for help to get a picam working with v4l-utils on a pi running slackware I was told the following by a "Raspberry PI Engineer" & Forum Moderator (quotatoions are mine). Quote:
|
Quote:
Jamesh, the "Raspberry PI Engineer" & Forum Moderator is actually the Principal Software Engineer at Raspberry Pi (Trading) Ltd. 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. :banghead: |
All times are GMT -5. The time now is 02:13 PM. |