Current kernel reboot once bcm firmware is in place. about linux

[kwizart]

BTW, I've also applied the serie from arnd/s3c-multiplatform
https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/

[PabloPL]

Hi @kwizart
I didn't had chance to test s3c-multiplatform patches, so could You try again without them?

About console over usb wire, there are many informations how to prepare such cable (for example https://redmine.replicant.us/projects/replicant/wiki/SamsungSerial).
You just need correct resistor (better stick with 523k or 619k, this would work also on other models. Tested on 7580 and 8890) between gnd and id usb pin + usb to uart adapter.

[xc-racer99]

Hello, I'm trying to debug the current issue I have with my kernel
While booting the device with the current galaxys-all branch on a fedora 31 userspace the device reboots while the NetworkManager takes over, I expect it's related to the wifi/bluetooth because it reboot once the related firmwares are in place.

Can you narrow it down to wifi or bluetooth (ie remove one of the firmwares)? The only thing "broken" with the setup in the DTS is that the enable GPIO for both is specified in the pinctrl for the wlan part.

I haven't had an issue with wifi on any of my branches for a long time, but I don't have the s3c-multiplatform patches (although the only thing this appears to touch for s5pv210 is the uarts which would lead me towards it being a BT problem)

[kwizart]

Okay, seems like there is a random effect. I've rebooted the device several time and it suddently worked. (I have reset to the same commit as the galaxys-all git repo).

The first time it worked, I have experienced a weird noise before booting to the display manager (was using lxde f31).

I have created a symlink to the appropriate txt file for :
brcm/brcmfmac4329-sdio.samsung,galaxys.txt (but it worked before the symlinks).

Now after few reboot I cannot boot to display manager, at some point the device restart.
Removing the brcm firmwares back and forth doesn't seem to help either.

Trying to boot from a cold boot (battery removed) doesn't always work...
I fear a mmc corruption, but a boot on another device works without issue.

It's going to be hard to debug without a serial...

The only error I see might be related to the mmc2 (externel mmc I'm using)
[ 141.533993] mmc2: ADMA error: 0x02000000
[ 141.535137] mmc2: sdhci: ============ SDHCI REGISTER DUMP ===========
[ 141.540246] mmc2: sdhci: Sys addr: 0x347e4cc4 | Version: 0x00002401
[ 141.545358] mmc2: sdhci: Blk size: 0x00007004 | Blk cnt: 0x0000fffc
[ 141.550470] mmc2: sdhci: Argument: 0x00000000 | Trn mode: 0x00000013
[ 141.555583] mmc2: sdhci: Present: 0x01fa0000 | Host ctl: 0x00000012
[ 141.560696] mmc2: sdhci: Power: 0x00000000 | Blk gap: 0x00000000
[ 141.565809] mmc2: sdhci: Wake-up: 0x00000000 | Clock: 0x0000010f
[ 141.570921] mmc2: sdhci: Timeout: 0x0000000a | Int stat: 0x00000003
[ 141.576034] mmc2: sdhci: Int enab: 0x03ff004b | Sig enab: 0x03ff004b
[ 141.581147] mmc2: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000001
[ 141.586259] mmc2: sdhci: Caps: 0x05e80080 | Caps_1: 0x00000000
[ 141.591372] mmc2: sdhci: Cmd: 0x0000163a | Max curr: 0x00000000
[ 141.596485] mmc2: sdhci: Resp[0]: 0x00000920 | Resp[1]: 0x00000000
[ 141.601597] mmc2: sdhci: Resp[2]: 0x00000000 | Resp[3]: 0x00000000
[ 141.606710] mmc2: sdhci: Host ctl2: 0x00000000
[ 141.609831] mmc2: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x349a3208
[ 141.614942] mmc2: sdhci: ============================================
[ 141.620057] mmc2: sdhci: 349a3200: DMA 0x347e4cc0, LEN 0x0004, Attr=0x23

[xc-racer99]

Yeah, the SDHCI errors appears to be "normal" - they're sometimes related to CONFIG_MMC_SDHCI_S3C_DMA being enabled but sometimes not. I haven't tried tracking them down. I've also appeared to have this MMC corruption bug, but I've tried so many different things/pulled the battery at weird times that I've simply put it down to user error. If we can find a repeatable case (doubtful, unfortunately), then we can debug it :)

The only weird noise I can think of is related to the audio commits if you have the wrong UCM files present (ie a high-pitched screech for a few seconds). This should be unrelated as I've had it several times without issue.

Symlinks shouldn't be needed for the brcm firmware file as it falls back to the generic name if the device specific one doesn't exist.

[xc-racer99]

@kwizart Is this still an issue? Please have a look at #42 for the MMC errors.

[kwizart]

For some reason I don't reproduce anymore this reboot issue with the current kernel (5.5.1-i9000+) and current initramfs.

I've created the initramfs using from the device.
dracut -H --no-early-microcode -f initramfs-5.5.1-i9000+.img 5.5.1-i9000+
ls : 15M ... initramfs-5.5.1-i9000+.img
Whereas "no host-only" initramfs are from 25M to 64M at the maximum size.

About the mmc2 ADMA error, I've managed to reproduce while runing "dnf update" on the device.
So maybe the clk patch isn't enough...

[xc-racer99]

For some reason I don't reproduce anymore this reboot issue with the current kernel (5.5.1-i9000+) and current initramfs.

Hmm, OK. I think I'll close this then.

About the mmc2 ADMA error, I've managed to reproduce while runing "dnf update" on the device.
So maybe the clk patch isn't enough...

Odd, I have yet to see it with the clk patch. Is it exactly the same error message or is it slightly different? ie an actual ADMA error?

[kwizart]

It looks similar, but the address is different.

[xc-racer99]

It looks similar, but the address is different.

Ok, can you please post it in #42 ?