Forum Replies Created

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • in reply to: Molex to SATA power adapter #806
    umiddelb
    Participant

    see here for a Molex gender changer …

    in reply to: Issues with mainline (4.12-rc7) #747
    umiddelb
    Participant

    You may have a look at your booti command sequence
    booti 0x02000000 - 0x01000000 - 0x03000000
    and replace it with
    booti 0x02000000 0x03000000 0x01000000

    and see what happens then

    in reply to: Issues with mainline (4.12-rc7) #744
    umiddelb
    Participant

    > To be honest, I tried for several hours to get initrd running. It was easy to get uboot to load the image, but I could never get the kernel to pick it up. It was really strange. I tried the stock ARCH linux image, and a custom one. No luck.

    booti ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}, e.g.
    booti 0x02000000 0x03000000 0x01000000

    will do the job.
    There are other benefits when using a initrd as well, e.g. set the rootfs to a device independent UUID and better systemd incorporation.

    in reply to: Issues with mainline (4.12-rc7) #738
    umiddelb
    Participant

    > Yes, initrd gets around the problem. No I did not want to go through the effort of building one.

    It’s damn easy, just make sure that the kernel config matching to your kernel revision (config-uname -r) can be found in /boot, than

    sudo update-initramfs -c -k uname -r
    sudo mkimage -A arm64 -O linux -T ramdisk -a 0x0 -e 0x0 -n initrd.img-uname -r -d /boot/initrd.img-uname -r /boot/uInitrd

    (the markup engine here is eating all the backticks …)

    in reply to: Issues with mainline (4.12-rc7) #735
    umiddelb
    Participant

    > I was able to debug the boot from mmc on the 4.12.1 issue and found that the sdhc support was not able to be compiled in. Only option was a module.
    You might try to use an Initrd, this allowed me to boot from mmcblk0.

    > CPUFreq not working. Might have missed a module in my kernel compile.
    Ack. The dts doesn’t contain necessary declarations to make cpu frequency scaling work.

    > XOR raid engine crashing
    Could you describe how to provoke/repeat this crash.

    > All NICs coming in with the same MAC (uBoot setting, not kernel problem??):
    It seems to be a randomly chosen address. u-boot has some distinct addresses defined but they aren’t used.

    > Really poor onboard NIC performance. 921 Mbits/sec @ 100% CPU usage.
    Ack.

    I’ll try to run some tests against the kernel image provided in the buildroot environment

    in reply to: Issues with mainline (4.12-rc7) #712
    umiddelb
    Participant

    … and they refer to a different SoC (ap806 <> 88F3720)

    in reply to: Source for pcie8879/mlan driver #710
    umiddelb
    Participant

    The buildroot “image” (is this what you mean with Globalscale’s kernel?) uses the MWLWIFI driver which is out of tree (https://github.com/kaloz/mwlwifi). IHMO there is no 3rd Marvell driver. My be they use a different firmware blob, you may check this.

    in reply to: Issues with mainline (4.12-rc7) #690
    umiddelb
    Participant

    Merci beaucoup

    in reply to: Source for pcie8879/mlan driver #689
    umiddelb
    Participant

    The in-tree mwifiex_pcie driver works out of the box (4.12).

    [    6.443748] mwifiex_pcie: try set_consistent_dma_mask(32)
    [    6.443832] mwifiex_pcie: PCI memory map Virt0: ffff000009700000 PCI memory map Virt2: ffff000009900000
    [    6.443984] mwifiex: rx work enabled, cpus 2
    ...
    [    7.864608] mwifiex_pcie 0000:00:00.0: info: FW download over, size 803884 bytes
    [    8.618814] mwifiex_pcie 0000:00:00.0: WLAN FW is active
    [    8.689914] mwifiex_pcie 0000:00:00.0: CMD_RESP: cmd 0x242 error, result=0x2
    [    8.689932] mwifiex_pcie 0000:00:00.0: mwifiex_process_cmdresp: cmd 0x242 failed during      initialization
    [    8.720109] mwifiex_pcie 0000:00:00.0: info: MWIFIEX VERSION: mwifiex 1.0 (15.68.7.p53)
    [    8.720120] mwifiex_pcie 0000:00:00.0: driver_version = mwifiex 1.0 (15.68.7.p53)
    in reply to: Troubleshooting ESPRESSObin kernel crashes #682
    umiddelb
    Participant

    I’ve had the same issue and switched over to a 4.12 mainline kernel.

    in reply to: Issues with mainline (4.12-rc7) #681
    umiddelb
    Participant

    I’d appreciate if you could open a PR against this kernel tree (or point me to your commits/patches). I’m collecting all stuff concerning my several boards there.

Viewing 11 posts - 1 through 11 (of 11 total)
Signup to our newsletter

Technical specification tables can not be displayed on mobile. Please view on desktop