-
Posts
3633 -
Joined
-
Last visited
Reputation Activity
-
zador.blood.stained got a reaction from willmore in SPI+USB boot (Orange PI PC2 )
Now it's also included in Armbian sources so following builds will have this fix already.
-
zador.blood.stained got a reaction from tkaiser in Pinebook install to eMMC?
mmc-utils is already present in Stretch, and we could probably build it for older releases too, but can't give any ETA due to some HW related issues.
-
zador.blood.stained got a reaction from willmore in Orange Pi One bootlooping with current armbian
No, most likely some dtc or environment commands changes that were made recently. Now that we have a test case I will try to bisect the sources.
-
zador.blood.stained got a reaction from tkaiser in Orange Pi Plus 2E - Turning off the Serial Monitor
To disable all serial output u-boot recompilation is required, it's easier to use other UART ports and leave ttyS0 as is.
-
zador.blood.stained got a reaction from infinity in ROCK64
Getting back to development related news - basic Rock64 support was added to the mainline tree starting with 4.14-rc1: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts?h=v4.14-rc1&id=955bebde057e71b6f29b97b78c027efdd596e62d
-
zador.blood.stained got a reaction from willmore in ROCK64
Getting back to development related news - basic Rock64 support was added to the mainline tree starting with 4.14-rc1: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts?h=v4.14-rc1&id=955bebde057e71b6f29b97b78c027efdd596e62d
-
zador.blood.stained reacted to Igor in Armbian build farm
I found out that I can upgrade to 300/50 for no extra money or hardware upgrade and I did it a week ago. Upload is now 5x faster and can be further upgraded but I think there is no need. Daily kernel recompilation is present on the download/repository server until morning - recompilation starts at 00.01. Hopefully, there should be less different kernels to build, so this setup should last. Only server memory is getting low at the moment since we get new sources - I tend to cache them to gain some speed and save SSD. Building utilisation is low at .deb packing and EXTRA packages building as Zador already explained ...
-
zador.blood.stained got a reaction from tkaiser in XU4 next + nand-sata-install + USB disk --> rootfs not found
Maybe this has something to do with it
Processing file /home/zador/armbian/patch/u-boot/u-boot-odroidxu4-next/cfgload-support-ext4.patch 1 out of 2 hunks FAILED -- saving rejects to file cmd/cfgload.c.rej I'll update the patch and push the fixes a bit later.
-
zador.blood.stained reacted to martinayotte in Orange Pi Lite KERNEL_TARGET next
Ok ! I've done a glitch in DT, I've found it and fix it !
Now my OPiPlus2E has WiFi in Next-4.13 ...
I will start new build for PC+ and Lite to verify that it is working there too, and then patches will be committed later.
-
zador.blood.stained got a reaction from Patrick Frank in Banana Pi M1 and custom boot options
AFAIK it may be possible to load UEFI GRUB bro u-boot, but it would probably need some work to make a working configuration for it.
You can check /boot/boot.cmd to check what it does exactly.
-
zador.blood.stained reacted to jernej in H3/H5/A64 DRM display driver
But is needed anyway.
My findings also.
I hope I can play a bit with Mali in the evening.
-
zador.blood.stained reacted to jernej in H3/H5/A64 DRM display driver
I think you must go trough all uargs->... references and replace it to job->uargs->... except for https://github.com/Icenowy/sunxi-mali/blob/master/r6p0/src/devicedrv/mali/common/mali_gp_job.c#L93, obviously.
-
zador.blood.stained reacted to martinayotte in Trying to boot NanoPi-K2
I wished to have the AP6212 WiFi working on my NanoPi-K2 !
BTW, it is a AP6212 Non-A ...
So, at first it didn't work. After investigation and few tries, I figured out that a another firmware was needed :
as discuss by Hans back in June https://patchwork.kernel.org/patch/9791523/
http://jwrdegoede.danny.cz/brcm-firmware/brcmfmac43430a0-sdio.bin.7.10.1.244.ucode940.1020
to be rename as brcmfmac43430a0-sdio.bin
http://jwrdegoede.danny.cz/brcm-firmware/brcmfmac43430a0-sdio.txt.jumper-ezpad-mini3
to be rename as brcmfmac43430a0-sdio.txt
Hans patch is already merged in 4.13...
-
zador.blood.stained got a reaction from Igor in Changed policy? Password required on desktop shutdown
Should be fixed by this already, but I didn't test building images from scratch yet.
-
zador.blood.stained reacted to jernej in H3/H5/A64 DRM display driver
Some clock patches are also needed. Take a look at my patches from 1. Avgust here: https://github.com/jernejsk/linux-1/commits/h3_hdmi_audio_v1/drivers/clk/sunxi-ng
Without them, resolution switching to resolutions like 1080p or 720p won't work.
-
zador.blood.stained got a reaction from jernej in H3/H5/A64 DRM display driver
Did a quick test on OPi+2E. Video works, HDMI sound works, so that's a great work, thanks! Will try to do more tests (like resolution switching) later.
Small note - framebuffer switching from u-boot to kernel (at least without simplefb nodes in the DT) displays a distorted picture for several seconds. Is this something that will need fixes/workarounds for mainlining?
Also you added DT nodes to sun8i-h3.dtsi - so how big will be the differences for H5? Currently (for other hardware) some common properties are defined in sunxi-h3-h5.dtsi and then specific properties are added in sun8i-h3.dtsi and sun50i-h5.dtsi (including clocks, interrupts, "compatible" strings, etc.).
-
zador.blood.stained reacted to jernej in H3/H5/A64 DRM display driver
Yes, but I have missed one patch which may or may not be important. It will have to wait till tomorrow.
For now, yes. I guess this doesn't really matter since we could squash all HDMI patches to one?
Driver should work (not tested), but DT must be updated.
Once everything works, I was thinking about adding Mali driver. Fortunately, we could borrow properly licensed X11 driver from CHIP.
-
zador.blood.stained got a reaction from willmore in Boot questions from a noob
To (try to) display a boot logo
The logo patch contains 2 parts: extra commands in the boot sequence and a configuration patch to compile in BMP support code: https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-sunxi/sunxi-boot-splash.patch
Obviously "unknown command "bmp"" error means that one part of the patch doesn't work.
boot.scr is boot.cmd packaged with a special header that contains the image type, checksum and similar things.
U-boot sets some variables during the boot sequence, some of them come from platform specific include files, others come from generic distro_bootmd support. You can check the u-boot environment with "env print", it will contain most of the boot sequence commands and variables, you'll just have to trace how commands are calling other commands while setting some variables in the process.
-
zador.blood.stained reacted to James Kingdon in Quick Pinebook Preview / Review
The fix for the 64G eMMC module looks promising - the module is now recognized when I boot armbian from sd card using the modified kernel. It's currently formatting the eMMC as the first stage of nand-sata-install...
The fix is trivial. In drivers/mmc/core/mmc.c, remove or comment out the conditional block at line 317
card->ext_csd.rev = ext_csd[EXT_CSD_REV]; /** if (card->ext_csd.rev > 7) { pr_err("%s: unrecognised EXT_CSD revision %d\n", mmc_hostname(card->host), card->ext_csd.rev); err = -EINVAL; goto out; } */ This test has been removed from later releases of the driver and a comment added to indicate that the cards should be backwards compatible so the test is unnecessary.
-
zador.blood.stained got a reaction from aidanc11 in Orange Pi (One) Hardware reset
Q9, C301 and R346 are located in the corner near USB port
-
zador.blood.stained got a reaction from Elliot Woods in Orange Pi Zero random MAC address (split from BPi R1 ...)
Apart from some migration issues, the hash from a fixed serial will be constant (Edit: well, it's not a hash in the true sense of the word since it uses part of the SID directly and crc32 of another part of the SID). Whether MAC address will be generated using that hash or not is the question, and, as I said, if the MAC is random, then it's due to the Device Tree configuration, and it is a board specific problem since each board uses its own Device Tree.
Just for the reference: http://git.denx.de/?p=u-boot.git;a=blob;f=board/sunxi/board.c;h=800f412b383ddf9ac90972e50a684c534d40fea4;hb=HEAD#l656
Random ones are not generated from a hash, obviously.
For some reason I've spent wasted some time and found the exact reason why the MAC is random in some cases. I guess blaming systemd and NetworkManager without trying to understand and debug the problem is easier.
Are you talking about stability in images that are marked "development" and "provided with no support"? For testing/development purposes random MAC is not an issue, completely broken Ethernet is not an issue, even missing CPU frequency scaling and thermal protection is not an issue. As long as it builds without issues and boots to a command prompt on a serial console it's working as intended, everything else is a nice bonus.
-
zador.blood.stained got a reaction from StuxNet in Armbian for OrangePi PC2, AllWinner H5
And AFAIK this (freezing the u-boot and kernel packages) was also implemented in the armbian-config.
-
zador.blood.stained got a reaction from valant in ROCK64
Example from lshw for an UAS capable USB to SATA bridge:
*-usb description: Mass storage device product: USB to ATA/ATAPI Bridge vendor: JMicron physical id: 2 bus info: usb@1:2 logical name: scsi5 version: 81.05 serial: [REMOVED] capabilities: usb-2.10 scsi configuration: driver=uas maxpower=500mA speed=480Mbit/s
Usually if it doesn't have any bugs (like some GL* controllers), passes trough SMART data and SCSI commands and has UAS capabilities (not blacklisted anywhere), it's good enough and who cares about how exactly it is represented.
AFAIK their nature should be interpreted as "devices that implement (a subset of) SCSI". USB BOT hides that nature under the "block device" abstraction, and UAS uses the SCSI command set. I think you can make a controller that would bypass SATA and instead of "storage->SATA->SCSI over USB/UAS" you would get "storage->SCSI over USB/UAS", so exposing their SATA nature is not mandatory.
-
zador.blood.stained reacted to tkaiser in ODROID HC1 / HC2
IMO there's no need to reference legacy kernel at all. With HC1 we're talking about Hardkernel's 4.9 or mainline
-
zador.blood.stained got a reaction from tkaiser in UAS + mainline kernel + coherent-pool memory size
It should be SZ_2M instead of SZ_2048K - the latter is not a predefined constant.