belfastraven
-
Posts
65 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by belfastraven
-
-
@Werner, I was perhaps not being clear enough in my suggestion. I don't have any experience with managing forum software, but was wondering if you could actually stop people from generating new topics in the bug system except by their using the bug reporting link.
So If someone tires to create a new topic without going through the bug reporting link, they are directed to the community forum. or their post is automativally moved there. .... One could even add that that fact to the header....
It might actually come across as "friendlier" and probably would be less work for moderators, but, as I said, I don't know enough about the forum software to know if that is even possible......
Is Armbian still using the Invision Community software? IS the documentation for it available ? I'd be happy to look into further trying to automate things if it would help...
-
Would it perhaps help to add the link to the bug reporting form to the heading for
"Bug tracker - supported boards and images only"
e.g. "Bug tracker for supported boards and images only- please use the bug reporting form found here for your initial posting. "
and if the form is not filled out, just move the post to the "community supported" forum.
Might that not make it easier for @Werner to moderate? It would certainly be "friendlier". Saying "invalid" and telling people that they may have "refused" to do something comes across as sounding a bit hostile--I think perhaps this is somewhat of caused by having different ways of expressing things in different languages. I think it is sometimes difficult to understand where to ask a question i you are just trying to ask for help in figuring something out, rather than reporting a bug. FWIW.
-
22 hours ago, lukasz said:
Strange, I fetched the GNOME OS image, figured they all come with GPU accelerated desktops now? Stable branch, daily build with GNOME desktop from yesterday.
@lukaszDid you try running glxinfo? I was just trying to indicate that there seems to be a difference in gnome settings in terms of what is reported for X rather than Wayland, but in both cases glxinfo shows panfrost as the extended renderer.
-
6 hours ago, lukasz said:
A few other issues I encountered when testing on the Pinebook Pro:
1) Natural scrolling setting doesn't work
2) WiFi doesn't come back up after suspend. Restarting network-manager brings it back up.
3) Video out via USB-C doesn't appear to work on any of my docks
One other thing I noticed: in settings 'About' panel, under graphics, it doesn't list Mali T-860 (Panfrost) but rather Unknown
@lukasz are you running on X11
For me , using self built hirsute/gnome (as opposed to just downloading) , using gnome on Wayland shows proper " mali T860 (Panfrost)" where gnome on Xorg shows " unknown, but in in either case glxinfo extended renderer section shows panfrost is used. Perhaps there is a bug in the settings program?
Desktop sort of works for me on my 4k monitor (usbc dock-hdmi connection--same as on other distributions--the geometry is wrong and that also effects the display on the pinebook itself, but it has worked that way on any distribution I have tried) Natural scrolling setting seems to work on Wayland...
-
@piter85, here's result of testing with official build, which uses 20.7, u-boot, I see:
Bourd booted fine without all of those""Timeout poll on interrupt endpoint" spams, using nand-sata-install overwrote the spi_flash just fine ( as you can see :-) ) and without this error, which I imagine would have been fixed by your most recent patch anyway?
Loading Environment from SPIFlash... Invalid bus 0 (err=-19)
*** Warning - spi_flash_probe_bus_cs() failed, using default environmentSpoiler-Boot TPL 2020.07-armbian (Dec 12 2020 - 02:09:32)
Channel 0: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
Channel 1: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
256B stride
256B stride
lpddr4_set_rate: change freq to 400000000 mhz 0, 1
lpddr4_set_rate: change freq to 800000000 mhz 1, 0
Trying to boot from BOOTROM
Returning to boot ROM...U-Boot SPL 2020.07-armbian (Dec 12 2020 - 02:09:32 +0100)
Trying to boot from SPI
NOTICE: BL31: v1.3(debug):42583b6
NOTICE: BL31: Built : 07:55:13, Oct 15 2019
NOTICE: BL31: Rockchip release version: v1.1
INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3
INFO: Using opteed sec cpu_context!
INFO: boot cpu mask: 0
INFO: If lpddr4 need support multi frequency,
INFO: please update loader!
INFO: Current ctl index[0] freq=400MHz
INFO: Current ctl index[1] freq=800MHz
INFO: plat_rockchip_pmu_init(1190): pd status 3e
INFO: BL31: Initializing runtime services
WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK
ERROR: Error initializing runtime service opteed_fast
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x200000
INFO: SPSR = 0x3c9
U-Boot 2020.07-armbian (Dec 12 2020 - 02:09:32 +0100)SoC: Rockchip rk3399
Reset cause: POR
Model: Pine64 RockPro64 v2.1
DRAM: 3.9 GiB
PMIC: RK808
MMC: mmc@fe310000: 2, mmc@fe320000: 1, sdhci@fe330000: 0
Loading Environment from SPI Flash... SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
*** Warning - bad CRC, using default environmentIn: serial
Out: vidconsole
Err: vidconsole
Model: Pine64 RockPro64 v2.1
Net: eth0: ethernet@fe300000
Hit any key to stop autoboot: 0
Card did not respond to voltage select!
Card did not respond to voltage select!Device 0: Vendor: 0x144d Rev: EXD7101Q Prod: S444NE0K603440
Type: Hard Disk
Capacity: 244198.3 MB = 238.4 GB (500118192 x 512)
... is now current device
Scanning nvme 0:1...
Found U-Boot script /boot/boot.scr
3185 bytes read in 2 ms (1.5 MiB/s)
## Executing script at 00500000
Boot script loaded from nvme 0
165 bytes read in 2 ms (80.1 KiB/s)
15788878 bytes read in 30 ms (501.9 MiB/s)
27507200 bytes read in 50 ms (524.7 MiB/s)
75803 bytes read in 3 ms (24.1 MiB/s)
2698 bytes read in 2 ms (1.3 MiB/s)
Applying kernel provided DT fixup script (rockchip-fixup.scr)
## Executing script at 09000000
## Loading init Ramdisk from Legacy Image at 06000000 ...
Image Name: uInitrd
Image Type: AArch64 Linux RAMDisk Image (gzip compressed)
Data Size: 15788814 Bytes = 15.1 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 01f00000
Booting using the fdt blob at 0x1f00000
Loading Ramdisk to f0ff8000, end f1f06b0e ... OK
Loading Device Tree to 00000000f0f7d000, end 00000000f0ff7fff ... OKStarting kernel ...
[ 7.927446] OF: graph: no port node found in /i2c@ff3d0000/typec-portc@22
[ 10.176477] Bluetooth: hci0: command 0x0c03 tx timeout
[ 18.400471] Bluetooth: hci0: BCM: Reset failed (-110)
[ 20.812505] rockchip-i2s ff8a0000.i2s: Fail to set mclk -22
[ 20.813004] rockchip-i2s ff8a0000.i2s: ASoC: error at snd_soc_dai_set_sysclk on ff8a0000.i2s: -22
[ 20.814478] rockchip-i2s ff8a0000.i2s: Fail to set mclk -22
[ 20.814975] rockchip-i2s ff8a0000.i2s: ASoC: error at snd_soc_dai_set_sysclk on ff8a0000.i2s: -22
[ 20.816344] rockchip-i2s ff8a0000.i2s: Fail to set mclk -22
[ 20.816944] rockchip-i2s ff8a0000.i2s: ASoC: error at snd_soc_dai_set_sysclk on ff8a0000.i2s: -22
[ 20.818487] rockchip-i2s ff8a0000.i2s: Fail to set mclk -22
[ 20.818984] rockchip-i2s ff8a0000.i2s: ASoC: error at snd_soc_dai_set_sysclk on ff8a0000.i2s: -22
[ 20.820589] rockchip-i2s ff8a0000.i2s: Fail to set mclk -22
[ 20.821086] rockchip-i2s ff8a0000.i2s: ASoC: error at snd_soc_dai_set_sysclk on ff8a0000.i2s: -22
[ 20.822781] rockchip-i2s ff8a0000.i2s: Fail to set mclk -22
[ 20.823279] rockchip-i2s ff8a0000.i2s: ASoC: error at snd_soc_dai_set_sysclk on ff8a0000.i2s: -22
[ 20.874651] rockchip-i2s ff890000.i2s: Fail to set mclk -22
[ 20.875145] rockchip-i2s ff890000.i2s: ASoC: error at snd_soc_dai_set_sysclk on ff890000.i2s: -22
[ 20.879467] rockchip-i2s ff890000.i2s: Fail to set mclk -22
[ 20.879975] rockchip-i2s ff890000.i2s: ASoC: error at snd_soc_dai_set_sysclk on ff890000.i2s: -22
[ 20.882323] rockchip-i2s ff890000.i2s: Fail to set mclk -22
[ 20.882828] rockchip-i2s ff890000.i2s: ASoC: error at snd_soc_dai_set_sysclk on ff890000.i2s: -22
[ 20.885386] rockchip-i2s ff890000.i2s: Fail to set mclk -22
[ 20.885895] rockchip-i2s ff890000.i2s: ASoC: error at snd_soc_dai_set_sysclk on ff890000.i2s: -22
[ 20.887769] rockchip-i2s ff890000.i2s: Fail to set mclk -22
[ 20.888263] rockchip-i2s ff890000.i2s: ASoC: error at snd_soc_dai_set_sysclk on ff890000.i2s: -22
[ 20.892113] rockchip-i2s ff890000.i2s: Fail to set mclk -22
[ 20.892645] rockchip-i2s ff890000.i2s: ASoC: error at snd_soc_dai_set_sysclk on ff890000.i2s: -22
[ 20.901997] rockchip-i2s ff890000.i2s: Fail to set mclk -22
[ 20.902492] rockchip-i2s ff890000.i2s: ASoC: error at snd_soc_dai_set_sysclk on ff890000.i2s: -22
[ 20.903935] rockchip-i2s ff890000.i2s: Fail to set mclk -22
[ 20.904600] rockchip-i2s ff890000.i2s: ASoC: error at snd_soc_dai_set_sysclk on ff890000.i2s: -22
[ 20.906022] rockchip-i2s ff890000.i2s: Fail to set mclk -22
[ 20.906515] rockchip-i2s ff890000.i2s: ASoC: error at snd_soc_dai_set_sysclk on ff890000.i2s: -22
[ 20.907968] rockchip-i2s ff890000.i2s: Fail to set mclk -22
[ 20.908490] rockchip-i2s ff890000.i2s: ASoC: error at snd_soc_dai_set_sysclk on ff890000.i2s: -22
[ 20.910050] rockchip-i2s ff890000.i2s: Fail to set mclk -22
[ 20.910543] rockchip-i2s ff890000.i2s: ASoC: error at snd_soc_dai_set_sysclk on ff890000.i2s: -22
[ 20.913290] rockchip-i2s ff890000.i2s: Fail to set mclk -22
[ 20.913786] rockchip-i2s ff890000.i2s: ASoC: error at snd_soc_dai_set_sysclk on ff890000.i2s: -22
[ 20.921297] rockchip-i2s ff890000.i2s: Fail to set mclk -22
[ 20.921791] rockchip-i2s ff890000.i2s: ASoC: error at snd_soc_dai_set_sysclk on ff890000.i2s: -22
[ 20.927416] rockchip-i2s ff890000.i2s: Fail to set mclk -22
[ 20.927911] rockchip-i2s ff890000.i2s: ASoC: error at snd_soc_dai_set_sysclk on ff890000.i2s: -22
[ 20.928934] rockchip-i2s ff890000.i2s: Fail to set mclk -22
[ 20.929426] rockchip-i2s ff890000.i2s: ASoC: error at snd_soc_dai_set_sysclk on ff890000.i2s: -22
[ 20.935687] rockchip-i2s ff890000.i2s: Fail to set mclk -22
[ 20.936181] rockchip-i2s ff890000.i2s: ASoC: error at snd_soc_dai_set_sysclk on ff890000.i2s: -22
[ 20.941726] rockchip-i2s ff890000.i2s: Fail to set mclk -22
[ 20.942221] rockchip-i2s ff890000.i2s: ASoC: error at snd_soc_dai_set_sysclk on ff890000.i2s: -22
[ 20.943164] rockchip-i2s ff890000.i2s: Fail to set mclk -22
[ 20.943656] rockchip-i2s ff890000.i2s: ASoC: error at snd_soc_dai_set_sysclk on ff890000.i2s: -22Armbian 20.11.3 Focal ttyS2
rockpro64 login: [ 26.084515] rockchip-i2s ff890000.i2s: Fail to set mclk -22
-
7 hours ago, piter75 said:
@belfastraven thanks for testing!
Would you be also able to test SPI/NVMe with one of the official Armbian images?
v20.11.3 already have the rkspi_loader.img bundled ;-)
I will test later today with an official image
7 hours ago, piter75 said:I
I will verify the not found spi flash scenario. Do you mean that the SPI chip was not recognised and there was no error in the nand-sata-install?
No I mean that you will get an error if the device doesn't have (pysically) an API_FLASH unit,
Do you mean it does not work without manual clearing the SPI before nand-sata-install?
Yes--I believe that to be the case. You certainly know more about this than I do, but I found that if I already had something written to SPI_FLASH ( I was playing with sigmaris's build) the if I used the NAND_SATA_INSTALL update the SPI_FLASH. It would return almost immediately with no error and obviously not having written the flash.... If I cleared it first, it did come back after a while that it had written the flash. I can certainly try again and see what happens.
7 hours ago, piter75 said:Strange, I specifically chosen to use dd with /dev/mtdblock0 for writing so that mtd-utils dependency was not needed and verified that it clears the blocks before writing new content.
But still... this is pretty fresh so maybe I missed something.
-
@Piter75, Just FYI, Booting a a Samsumg pm980 nvme from spi_flash with your new 20.10 u-boot (from your
rockchip64-u-boot-v2020.10 branch ) works most of the time. This is a build made from playing with the desktop stuff, hirsute with gnome...
SpoilerU-Boot TPL 2020.10-armbian (Jan 01 2021 - 16:45:25)
Channel 0: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
Channel 1: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
256B stride
lpddr4_set_rate: change freq to 400000000 mhz 0, 1
lpddr4_set_rate: change freq to 800000000 mhz 1, 0
Trying to boot from BOOTROM
Returning to boot ROM...U-Boot SPL 2020.10-armbian (Jan 01 2021 - 16:45:25 -0500)
Trying to boot from SPI
NOTICE: BL31: v1.3(debug):42583b6
NOTICE: BL31: Built : 07:55:13, Oct 15 2019
NOTICE: BL31: Rockchip release version: v1.1
INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3
INFO: Using opteed sec cpu_context!
INFO: boot cpu mask: 0
INFO: If lpddr4 need support multi frequency,
INFO: please update loader!
INFO: Current ctl index[0] freq=400MHz
INFO: Current ctl index[1] freq=800MHz
INFO: plat_rockchip_pmu_init(1190): pd status 3e
INFO: BL31: Initializing runtime services
WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK
ERROR: Error initializing runtime service opteed_fast
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x200000
INFO: SPSR = 0x3c9
U-Boot 2020.10-armbian (Jan 01 2021 - 16:45:25 -0500)SoC: Rockchip rk3399
Reset cause: POR
Model: Pine64 RockPro64 v2.1
DRAM: 3.9 GiB
PMIC: RK808
MMC: mmc@fe310000: 2, mmc@fe320000: 1, sdhci@fe330000: 0
Loading Environment from SPIFlash... Invalid bus 0 (err=-19)
*** Warning - spi_flash_probe_bus_cs() failed, using default environmentIn: serial
Out: vidconsole
Err: vidconsole
Model: Pine64 RockPro64 v2.1
Net: eth0: ethernet@fe300000
starting USB...
Bus usb@fe380000: USB EHCI 1.00
Bus usb@fe3a0000: USB OHCI 1.0
Bus usb@fe3c0000: USB EHCI 1.00
Bus usb@fe3e0000: USB OHCI 1.0
Bus dwc3: usb maximum-speed not found
Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus usb@fe380000 for devices... 3 USB Device(s) found
scanning bus usb@fe3a0000 for devices... 1 USB Device(s) found
scanning bus usb@fe3c0000 for devices... 1 USB Device(s) found
scanning bus usb@fe3e0000 for devices... 1 USB Device(s) found
scanning bus dwc3 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot: 0 Timeout poll on interrupt endpointTimeout poll on interrupt endpoint
Card did not respond to voltage select!
Timeout poll on interrupt endpoint
Card did not respond to voltage select!
Timeout poll on interrupt endpointDevice 0: Vendor: 0x144d Rev: EXD7101Q Prod: S444NE0K603440
Type: Hard Disk
Capacity: 244198.3 MB = 238.4 GB (500118192 x 512)
... is now current device
Timeout poll on interrupt endpoint
Scanning nvme 0:1...
Timeout poll on interrupt endpoint
Timeout poll on interrupt endpoint
Timeout poll on interrupt endpoint
Timeout poll on interrupt endpoint
Timeout poll on interrupt endpoint
Timeout poll on interrupt endpoint
Timeout poll on interrupt endpoint
Found U-Boot script /boot/boot.scr
3185 bytes read in 2 ms (1.5 MiB/s)
## Executing script at 00500000
Boot script loaded from nvme 0
165 bytes read in 2 ms (80.1 KiB/s)
15062500 bytes read in 28 ms (513 MiB/s)
28449280 bytes read in 51 ms (532 MiB/s)
75990 bytes read in 3 ms (24.2 MiB/s)
Timeout poll on interrupt endpoint
Timeout poll on interrupt endpoint
2698 bytes read in 3 ms (877.9 KiB/s)
Applying kernel provided DT fixup script (rockchip-fixup.scr)
## Executing script at 09000000
Moving Image from 0x2080000 to 0x2200000, end=3dc0000
## Loading init Ramdisk from Legacy Image at 06000000 ...
Image Name: uInitrd
Image Type: AArch64 Linux RAMDisk Image (gzip compressed)
Data Size: 15062436 Bytes = 14.4 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 01f00000
Booting using the fdt blob at 0x1f00000
Loading Ramdisk to f10b2000, end f1f0f5a4 ... OK
Loading Device Tree to 00000000f1037000, end 00000000f10b1fff ... OKStarting kernel ...
Armbian 21.02.0-trunk Hirsute ttyS2rockpro64 login:
It normally works--every once in a while it seems to not get past
Booting using the fdt blob at 0x1f00000
not sure what is causing that yet, or the constant :
Timeout poll on interrupt endpoint
I did manually clear previous spi_flash and used nand-sata-install to install the build and new spi flash.
I've also noticed that when asked to update spi flash, it seems like the script will error if it doesn't find an spi_flash, but does not try to erase it if it has been written, andwill fail without any error message if a program already exists there...
I apologize in advance if the spoiler is not hide-able--I can't seem to make that happen
-
@Igor, I am happy to help with documentation--I have been playing with the desktop branch (I'm now running hirsute with gnome on wayland on my pinebook pro--which I doubt you will be recommending to users, (but have tried various other combinations). I still don't understand whether this desktop/package flexibility is just for builders or will in someway available to people who would normally be downloading just images, or perhaps assembling pre-built images using native builds? Anyway, I am volunteering documentation assistance...
-
Re building different desktops: The capability to build various desktops through the build system is being worked on and tested now. From my initial look, it seems like many desktops including gnome, kde, cinnamon, lxde xfce and various others are being thought about for inclusion. I just started to try to play a bit with desktop (as opposed to master) branch of the github. Obviously, this is not released yet...
-
Hmmm if your Ctrl-Alt-F2 prints a #, I believe it is somehow using the us (or perhaps ANSI) keyboard layout. That is what all of my other keyboards show by default--the PBP is my only ISO keyboard device. I'm certainly not an expert on any of this. If you want to build groovy, I believe you need to used EXPERT=yes on the ./compile.sh command. I have done a dev build, which builds kernel 5.9(.1 right now) . I did a console rather than a desktop build so I could play with installing a different desktop. Groovy runs very well so far for me. I am booting the NVME from SPI flash. I installed an armbian uboot myself on on SPI flash ,, but I can see that armbian-config is being enabled to do that, too.
Right now, I am running without sound, since I have the UART switch flipped, and am very much "over" removing 10 tiny screws every time I want to open the back. Someone on the Pine64 forum just posted that he had been able to use a spare internal uart and a micro usb-uart adapter to bring uart out without using the switch. I think THAT would be really advantageous:-)
-
When you speak about opening a terminal window, do you mean on the desktop? or do you mean opening a terminal console with CNTL-ALT-F(some-number). The mechanisms are different. For the CNTL-ALT-F(some-number) , if I set the /etc/default/keyboard file so that
XDBMODEL="pc105"
XDBLAYOUT="gb"
XDBVARIANT="intl"
I get the pound sign at shift-3.
For the desktop console, it is controlled by whatever desktop manager you are using, I believe. So if in the desktop settings you have the pc105 UK keyboard selected, that should be working. If it works elsewhere on the desktop, but not in the desktop terminal--could it have something to do with the particular font or character set used for the terminal?
just FYI I am using groovy with a cinnamon desktop, I have an ISO keyboard, and I can indeed display the GBP
-
Are you trying to build a kind of "kiosk" application? XFCE is a much less resource intensive desktop than gnome and it actually has a kiosk mode-- you also have the capability of controlling the color of the desktop and what appears on a panel: see here: https://docs.xfce.org/xfce/xfconf/start.
I am excited about the project that @Igor has mentioned; for now, I tend to build a "server" version of software and then install a desktop on the running system. I imagine that would not work for you even if you used clonezilla or a like program to copy the configured image, since you may need different network parameters for each installation... but I thought I would mention it.
-
Given the gsettings you are running, I assume you are using a GNOME desktop?
if so can you try,
gsettings set org.gnome.desktop.background picture-options 'none'
gsettings set org.gnome.desktop.background primary-color '#000000'
Assuming that since you know the user and you are using autologin ( as that won't change the background for the display manager) that will set a black background.
If this is e.g. an xfce, lxde , etc. desktop, that will not work.
there are other gsettings keys that you can set to eliminate desktop icons, etc. Your best bet would be to google gsettings
-
If anyone wants instructions for updating on debian/ubuntu as well as arch see:
latest keyboard updater with instructions for debian and arch..
Also, I have been running the pcm720 u-boot that @lanefu mentioned since the end of July, since it allows me to boot my nvme. I have played a bit with trying to work the patches/versions into the build system, but haven't been successful as of yet.
.
See here for the source https://github.com/pcm720/u-boot-build-scripts. There is one atf patch (which we may already have) and 4 u-boot patches. It is using u-boot 20.07, and a reasonably recent atf. I am rather confused about in which confs/patch directories I need to make the changes for current and dev builds. Is it possible for someone more up on the build system to take a look?
-
I can test, too. I have been running with (currently) an armbian dev build with 5.8.9 kernel on focal with a gnome desktop and pcm720's uboot on spi flash, botting an nvme. The only strangeness that I have been running across is that if I boot off of an SD card, rebooting without shutting down seems to boot the NVME. I haven't spent much time investigating, though--I was just so excited to be using armbian builds again..:-)
-
Thanks for your response.
I thought it that was so, but then, perhaps that test for it should be removed from main.sh. ? Otherwise, the build system will go ahead and download the sources anyway, even though it had said previously it would not., so the user documentation doesn't match what is happening. (this is not theoretical--it happened to me--twice before I figured out what was happening--:-) )
If you are using BUILD_ALL, what would now be considered the proper way to avoid having sources downloaded?.. If everyone who builds anything is just supposed to use OFFLINE_WORK, I could try making the change in main.sh (pull request) , but as you know, I am not very good with shell scripts , and the build system isn't simple.
-
I've noticed that in order to be able to build offline, I need not only to specify OFFLINE_WORK=yes as per this documentation:
OFFLINE_WORK ( yes | no ): skip downloading and updating sources as well as time and host check. Set to “yes” and you can collect packages without accessing the internet
but also IGNORE_UPDATES=yes.
Probably because of this is main.sh:
# ignore updates help on building all images - for internal purposes
if [[ $IGNORE_UPDATES != yes ]]; then
display_alert "Downloading sources" "" "info"I don't see here in main.sh where is is checking for build-all..... so it seems that unless i specify IGNORE_UPDATES=yes, the system still downloads sources.
No big problem, but I thought someone more familiar with how the scripts are supposed to work could look into it....
-
@Igor, I've been playing with the Cubox builds and everything is working well. On WIndows, I am thinking about suggesting the built-in powershell tool Get-FIlehash for verification and explaining how to write the hash into a file to check it. gnupg, which installs gpg, and gpg4win, its windows graphic frontend with extra bells and whistles, work fine for authentication, and the command line use is the same as on linux. If we have any windows experts here who would like to weigh in, I'd love to here from them. Of course, if people are running WSL , they can just do this with the linux commands anyway...
I will see what I come up with over the weekend and THEN make the pull request. :-)
-
@igor, I'm very glad you finished it--I don't think anyone wants me to mess around with the build system
.
I am back to working on the doc. I'm trying to determine the best tool to use on windows to shasum the xz file. certutil, e.g. expects the user to compare the hashes (not very friendly, I think) , Microsoft has a tool which I haven't tried yet, but will try tonight.
Also, the doc still says builds for supported desktops are bionic and buster--wasn't sure that was still true.
This is where I am currently, if anyone wants to look: https://github.com/belfastraven/documentation/blob/patch-2/docs/User-Guide_Getting-Started.md
If I check tomorrow, I'm assuming that I will see the newly generated dowload files? I will test again.
P.S. I'm just trying to help. I am never offended about code, documentation changes, etc. I dual boot my desktop Ubuntu and Windows, but don't have a Mac, so when this is finalized, perhaps someone with a Mac can test....
-
@Igor (and anyone else who wants to weigh in on the changes for xz compression)
Could you take a look here https://github.com/belfastraven/build/blob/pre-new-doc/lib/debootstrap.sh at the section toward which you pointed me. This now will do compression first and then the shasum and gpg stuff. The shasum stuff is working (I tried it twice :-) ) I left "the "yes" option and the "no compression" options the way they were. I wasn't sure what everyone wanted --whether we should now use xz,sha,gpg by default, or what. I was not able to properly test the asc file generation because I am apparently not setting GPG_PASS properly. Perhaps I will figure that out tomorrow.
I realize that I propabably should have given the branch the Atlassian assignment number. I'll do better next time....
-
@Igor one last issue. When I downloaded the odroid 4c files ,(The .img.xz, .asc and .sha for bionic current desktop) I realized that no program that i can find will verify/validate the download or authenticity of the xz when the sha or asc generation is run against the uncompressed image , which seems to have been the case.
Is it possible to generate the sha and asc file using the .img.xz files? If not, is it the intention the users should uncompress the xz files before running the checks? They obviously don't need to do that to write the file with Etcher or USBImager. Once I know what the intention is here, I can finish this piece of documentation. By the way, those builds seemed to be using 20.02. When I build locally, the build does seem to use 20.05. I found (grep is my friend) that I could specify xz on the COMPRESS_IMAGE
build parameter but it does seem that the sha and asc files are generated from the .img file, not the compressed file....but shell scripts are not my strong point....
-
Okay, thanks Igor, I am working on it and I did sign up for the Alsassian project management stuff.
-
OK sorry--brain obviously not working. So am I understanding correctly that three files will need to be downloaded, the .img.xz, the .asc. and the .sha and that the new way of checking authentity and validating are
gpg --verify "some-name".img.asc
sha256sum --check "some-name".img.sha ?
Also, the page I saw only mentioned etcher and not USBImager. SHould it also mention USBImager?
Could someone point me to a download that has everything in place for the new system: I'd like to test what I am writing. I normally build things and when I tried to download some RockPro64 files I was getting Nginx errors for the SAH and ASC files. Any board with the new setup will do, its just for documentation testing purposes....
thanks.
-
Igor, re your first request, I looked at the linked page, but didn't see anywhere there anything that indicates that the compressed file would be 7z. It says to use 7-zip or p7zip to uncompress the file, which should also work for xz files. Did you want to indicate that the compressed files would be .xz? Do you have a preference that a different tool be used?
Changing the serial console on the Rockpi 4B
in Rockchip
Posted
It looks like you are using the dts name from the kernel rather than u-boot. I believe for u-boot the dts name is something like
arch/arm/dts/rk3399-rock-pi-4.dtsi -- it looks like there are a couple that might be the one you want--.
The kernel dts files and u-boot dts files don't use the same paths .... You created a patch for the kernel, not u-boot.....