Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Current kernel reboot once bcm firmware is in place. #41

Closed
kwizart opened this issue Dec 19, 2019 · 10 comments
Closed

Current kernel reboot once bcm firmware is in place. #41

kwizart opened this issue Dec 19, 2019 · 10 comments

Comments

@kwizart
Copy link

kwizart commented Dec 19, 2019

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.

https://paste.centos.org/view/1dc19b8d

But nothing seems to be written to the journal.
Is there any way to debug further ? Can I setup a console over the usb wire ? How ?
Anything obviously wrong in the kernel configuration ?
https://paste.centos.org/view/b0ff2c25

@kwizart
Copy link
Author

kwizart commented Dec 19, 2019

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

@PabloPL
Copy link
Owner

PabloPL commented Dec 19, 2019

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
Copy link
Collaborator

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
Copy link
Author

kwizart commented Dec 19, 2019

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
Copy link
Collaborator

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
Copy link
Collaborator

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

@kwizart
Copy link
Author

kwizart commented Apr 26, 2020

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
Copy link
Collaborator

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
Copy link
Author

kwizart commented Apr 26, 2020

It looks similar, but the address is different.

@xc-racer99
Copy link
Collaborator

It looks similar, but the address is different.

Ok, can you please post it in #42 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants