Will the missing links/webpages be added to the DebianOn wiki?
https://wiki.debian.org/InstallingDebianOn/PINE64
ROCK64 and Pinebook Pro do not seem to have a linked webpage.
Does this include kernel updates from Debian package repositories?
Will there be official support for Pinebook Pro in the Debian Installer?
08-17-2020, 04:31 PM
(This post was last modified: 08-17-2020, 04:45 PM by Nikolay_Po.)
@ foresto , indeed, preserving of first FAT32 partition on bootable SD-card done the trick. Debian Linux boots OK.
How to enable RK3399 SPDIF output? I see none options both Ubuntu Focal (Armbian) and Debian testing setup. Both have only HDMI sound.
Older releases, say, Feature Complete Debian Desktop Release from Mrfixit2001 or Ayufan releases supported SPDIF output and ES8316 audio codec.
Why SPDIF and ES8316 support is absent in latest releases? May it depend on architecture? For example, desktops with full-feature sound was armhf architecture (32 bit). Newer I tested are aarm64 (64-bit) and have a lack of "sound cards". The same is for video support. I saw none working video acceleration with aarm64 architecture...
mainline kernel and bsp kernel (based on 4.4) support different features. unfortunately, rockchip have not yet switched to a 5.x kernel development, i.e. "a kernel from this decade".
What a frustrating headache! The Linux Foundation releases a new kernel like every 6 weeks and SoC manufacturers aren't releasing newer kernel builds for their SoC's. Please Rockchip and NXP, release the source code, and dependencies, under the GNU Public License or Lesser GNU Public License. That way it doesn't have to maintain by the OEM, or port it to the newer kernel versions, and it can be re-distributed via the myriad of other Linux kernel/Open Software distributors...etc. These things could be maintained and supported for over 10 years, much longer than a vendor would want to.
(08-20-2020, 04:53 PM)u974615 Wrote: What a frustrating headache! The Linux Foundation releases a new kernel like every 6 weeks and SoC manufacturers aren't releasing newer kernel builds for their SoC's. Please Rockchip and NXP, release the source code, and dependencies, under the GNU Public License or Lesser GNU Public License. That way it doesn't have to maintain by the OEM, or port it to the newer kernel versions, and it can be re-distributed via the myriad of other Linux kernel/Open Software distributors...etc. These things could be maintained and supported for over 10 years, much longer than a vendor would want to.
That would be awesome. But sometimes is impossible for legal reasons - those blobs may implement bits that are licensed from third parties. And sometimes even no third party may be involved, just some patented stuff. And as someone who's familiar with such situations first hand - the developers in the company may want stuff to be open-sourced, but the legal department is really apprehensive about potentially opening up patented stuff for anyone to use and suppress any such notion. Every time I try to open up any piece of code I have to go through a legal review process where it is determined whether the code contains anything that may either infringe on someone else's patents or expose our own intellectual property.
This message was created with 100% recycled electrons
A few days ago the link worked, now it doesn't. Did they remove the files or move it somewhere else?
(08-21-2020, 10:49 PM)moonwalkers Wrote: (08-20-2020, 04:53 PM)u974615 Wrote: What a frustrating headache! The Linux Foundation releases a new kernel like every 6 weeks and SoC manufacturers aren't releasing newer kernel builds for their SoC's. Please Rockchip and NXP, release the source code, and dependencies, under the GNU Public License or Lesser GNU Public License. That way it doesn't have to maintain by the OEM, or port it to the newer kernel versions, and it can be re-distributed via the myriad of other Linux kernel/Open Software distributors...etc. These things could be maintained and supported for over 10 years, much longer than a vendor would want to.
That would be awesome. But sometimes is impossible for legal reasons - those blobs may implement bits that are licensed from third parties. And sometimes even no third party may be involved, just some patented stuff. And as someone who's familiar with such situations first hand - the developers in the company may want stuff to be open-sourced, but the legal department is really apprehensive about potentially opening up patented stuff for anyone to use and suppress any such notion. Every time I try to open up any piece of code I have to go through a legal review process where it is determined whether the code contains anything that may either infringe on someone else's patents or expose our own intellectual property.
One would think that this makes trade unions like The Linux Foundation more necessary. ...software copyright, copyright collectives, software patents, patent pools, trademarks and trade secrets so much fun. Corporate laywers exist to protect and defend their corporation.
I would like to think that organizations such as Linaro ( https://www.linaro.org/services/open-sou...nsultancy/ ), Software Freedom Law Center ( https://softwarefreedom.org/ ), Free Software Foundation ( https://www.fsf.org/licensing/ ), and Software Freedom Conservacy ( https://sfconservancy.org/ ) provide services for companies and professional navigating this nightmare. I am not certain how much Red Hat (IBM), Cannonical, The Linux Foundation, Mozilla Foundation, or The Apache Foundation could provide direction in this.
08-27-2020, 04:30 PM
(This post was last modified: 08-27-2020, 04:35 PM by moonwalkers.)
(08-27-2020, 03:04 PM)u974615 Wrote: One would think that this makes trade unions like The Linux Foundation more necessary. ...software copyright, copyright collectives, software patents, patent pools, trademarks and trade secrets so much fun. Corporate laywers exist to protect and defend their corporation.
I would like to think that organizations such as Linaro ( https://www.linaro.org/services/open-sou...nsultancy/ ), Software Freedom Law Center ( https://softwarefreedom.org/ ), Free Software Foundation ( https://www.fsf.org/licensing/ ), and Software Freedom Conservacy ( https://sfconservancy.org/ ) provide services for companies and professional navigating this nightmare. I am not certain how much Red Hat (IBM), Cannonical, The Linux Foundation, Mozilla Foundation, or The Apache Foundation could provide direction in this.
Let me just say that I myself am a paying member of FSF, EFF, and SFC, so I do believe in FLOSS and the ideas behind it. With that out of the way...
It's all in cost-benefit trade-off and your business model. If your primary source of income are software licenses - you'd better behave like MS did throughout most of its history. If your primary source are support contracts - open-sourcing virtually everything is totally fine, just look at Red Hat. If your primary source is providing services using your own proprietary infrastructure - you'd better be highly selective about what you open-source and what you keep closed, see Google and Amazon. But if your primary source of income is selling hardware units - tell me, where is the benefit in allowing the older hardware to be maintained by the community virtually indefinitely? That would undermine the sales of the spanking brand new improved hardware!
Open-sourcing things in a commercial environment takes time, effort, and money, believe it or not. It may be bringing benefits, but often times those benefits are less tangible than the cost of doing so. Could one make an argument that by open-sourcing things to allow better long-term software support for the hardware can improve customer experience and make them more loyal? Sure. But frankly speaking that argument often sounds rather flimsy to someone who's more interested in sales volumes now than in some marginal number of customers hopefully staying loyal and maybe buying another unit or two in another half a decade, especially for hardware that is primarily intended for appliances rather than general computing, consumed by people of whom majority have not even heard the term "open source" and who despise updates and postpone them as long as they can.
This message was created with 100% recycled electrons
(08-16-2020, 11:21 PM)foresto Wrote: (08-16-2020, 10:50 PM)Nikolay_Po Wrote: Have tried pineperson's recommendations about files for booting. No boot.
I suspect that's because pineperson left out some important details. I got it working by doing all of the following:
- Create my /boot partition on the same microsd card that contains the installer image. This becomes partition 2 on that card.
- Set the bootable flag on partition 2.
- Create the boot/dtbs/rockchip directory on partition 2.
- Copy boot/dtbs/rockchip/rk3399-rockpro64-v2.dtb from partition 1 (the installer partition) to the same directory on partition 2.
- Create the /extlinux directory on partition 2.
- Create an extlinux/extlinux.conf file in that directory on parition 2, with this content: (Note the root= line!)
Code: menu title Debian
prompt 0
timeout 50
label l0
menu label Debian
linux /vmlinuz
append root=<your-root-device>
initrd /initrd.img
fdt /dtbs/rockchip/rk3399-rockpro64-v2.dtb
I believe the reason this works is because the installer image already contains the various u-boot components needed for boot, in the correct disk locations preceding the first partition.
Preparing a fresh sd card (or emmc module) with those required components is most likely possible, but would require more work. I hope to figure out how to do this at some point in the future, when I have more time. If I succeed, I'll describe the procedure in my debian setup thread.
That seems to be what happens. I got it working by roughly following your instructions (and those of the installer as to where to put root=). It's important NOT to tell it to install over the whole disk else the FAT32 partition with the funny stuff gets wiped. I even put LVM on mine without problem, though.
Then I also had to copy initrd.img from /boot (on the root partition) into the FAT32 partition. Not changing that meant that the installer ramdisk kept on being called.
Note that the FAT32 partition is very small, and without deleting some of the stuff, one can run out of room to put initrd. That happened to me on first go.
Seems images for RockPro 64 are broken for the last several days.
20201006 and earlier images flashed to SD card boot to the Debian installer successfully.
20201007 and later do not boot, but hang at this point:
Code: ## Flattened Device Tree blob at 01f00000
Booting using the fdt blob at 0x1f00000
Any advice?
|
