Jump to content

Roland G

Members
  • Posts

    11
  • Joined

  • Last visited

Everything posted by Roland G

  1. Hi Myy, I have applied your solution to the current kernel (5.8.16) and it worked perfectly. The AP came up and I connected 2 clients to it without a problem. This is the first time the AP worked since 4.4.y. Well done. The only thing that was missing for the AP to work (after applying your fix) was to install dnsmasq (so that the clients could be assigned an IP).
  2. Wifi AP access point broken in Linux tinkerboard 5.4.44-rockchip #20.05.2 SMP PREEMPT Wed Jun 3 10:43:15 CEST 2020 armv7l armv7l armv7l GNU/Linux [ 456.873025] ------------[ cut here ]------------ [ 456.878198] kernel BUG at mm/slub.c:3968! [ 456.882680] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM [ 456.889200] Modules linked in: xt_MASQUERADE xt_conntrack ipt_REJECT iptable_filter nf_nat_h323 nf_conntrack_h323 nf_nat_pptp nf_conntrack_pptp nf_nat_tftp nf_conntrack_tftp nf_nat_sip nf_conntrack_sip nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_conntrack_ftp iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 fuse zstd snd_soc_hdmi_codec zram snd_soc_simple_card snd_soc_simple_card_utils gpio_keys panfrost dw_hdmi_i2s_audio gpu_sched snd_usb_audio snd_soc_rockchip_i2s snd_soc_rockchip_pcm snd_hwdep snd_usbmidi_lib rockchip_rga snd_rawmidi snd_soc_core snd_seq_device snd_pcm_dmaengine videobuf2_dma_sg v4l2_mem2mem snd_pcm videobuf2_memops videobuf2_v4l2 snd_timer rk_crypto snd videobuf2_common soundcore syscon_reboot_mode dw_wdt reboot_mode rk3288_gpiomem r8723bs(C) rockchip_thermal cpufreq_dt sch_fq_codel ip_tables hid_logitech_hidpp hid_logitech_dj realtek [ 456.975109] CPU: 1 PID: 1564 Comm: RTW_CMD_THREAD Tainted: G C 5.4.44-rockchip #20.05.2 [ 456.985512] Hardware name: Rockchip (Device Tree) [ 456.990779] PC is at kfree+0x2dc/0x308 [ 456.994974] LR is at nl80211_send_station+0x954/0xfc4 [ 457.000621] pc : [<c02b81c0>] lr : [<c0e2a470>] psr: 400b0013 [ 457.007625] sp : e8edfd28 ip : e8edfd58 fp : e8edfd54 [ 457.013464] r10: c1606788 r9 : eccca0c0 r8 : e8edfec0 [ 457.019304] r7 : e8edfec0 r6 : c0e2a470 r5 : ef3bb75c r4 : 00000000 [ 457.026601] r3 : 00000100 r2 : 00000024 r1 : ea678d61 r0 : e8edfec0 [ 457.033901] Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 457.041878] Control: 10c5387d Table: 2965806a DAC: 00000051 [ 457.048303] Process RTW_CMD_THREAD (pid: 1564, stack limit = 0x081ec079) [ 457.055796] Stack: (0xe8edfd28 to 0xe8ee0000) [ 457.060669] fd20: ea678cdc c07996bc e8edfe00 e80a9480 00000011 00000000 [ 457.069818] fd40: e8edfec0 eccca0c0 e8edfdb4 e8edfd58 c0e2a470 c02b7ef0 00000005 00000013 [ 457.078967] fd60: c0276534 00000000 c1606788 eccca030 eccca0c0 eccca014 00000000 00000000 [ 457.088115] fd80: 0086c550 e9c85a1a 000101dc ec46d9e0 ec46d000 00000000 00000a20 ea678cca [ 457.097263] fda0: e8edfe00 e80a9480 e8edfdfc e8edfdb8 c0e2b18c c0e29b28 00000000 ec46d800 [ 457.106411] fdc0: ec46d000 ea678cca e8edfe00 00000001 e8edfdec c1606788 0000001c 00000000 [ 457.115560] fde0: 00000000 bf091050 e85b9d80 00009930 e8edfeec e8edfe00 bf086684 c0e2b108 [ 457.124708] fe00: 00000000 00000000 000fffff c02b72e4 c010d6a0 c1606788 e9c85a1a c02b73bc [ 457.133856] fe20: 0000000a 00000000 e8edfebc e8edfe38 c02b73bc c0151ec8 bf069230 bf068f24 [ 457.143004] fe40: e816fc00 c1606788 c010d6a0 00210d00 8015000a 00000001 00000001 e816fc00 [ 457.152153] fe60: ffffe000 600b0013 e8edfeac e8edfe78 ea678cdc 00000085 e8edfec4 8015000a [ 457.161301] fe80: c02b5990 c0277ffc e8edfef0 e9c85a1a 000000a1 ee401c00 ef39d39c bf03df0c [ 457.170450] fea0: e816fc00 c012bf24 ffffe000 000000a1 e8edfed4 e8edfec0 c012bf24 c0151ec8 [ 457.179598] fec0: bf03df20 f1225f84 e8edfeec e9c85a1a f086b000 f1225f84 000000a1 ea678cc0 [ 457.188746] fee0: e8edff0c e8edfef0 bf03df38 bf086610 f086c000 00000000 f086c4b8 c1604900 [ 457.197894] ff00: e8edff24 e8edff10 bf048e4c bf03dd7c f086c000 f086e000 e8edff74 e8edff28 [ 457.207042] ff20: bf03693c bf048dcc e8edff4c e8edff38 f086c49c f086b000 bf099000 ec46f200 [ 457.216190] ff40: e8ede000 f086c480 c014902c e8369900 e9975200 00000000 e8ede000 f086b000 [ 457.225339] ff60: bf0367a4 ed7a57e8 e8edffac e8edff78 c014a214 bf0367b0 e8369928 e8369928 [ 457.234486] ff80: 00000000 e9975200 c014a0a4 00000000 00000000 00000000 00000000 00000000 [ 457.243626] ffa0: 00000000 e8edffb0 c01010e8 c014a0b0 00000000 00000000 00000000 00000000 [ 457.252752] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 457.261879] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [ 457.271004] Backtrace: [ 457.273733] [<c02b7ee4>] (kfree) from [<c0e2a470>] (nl80211_send_station+0x954/0xfc4) [ 457.282481] r9:eccca0c0 r8:e8edfec0 r7:00000000 r6:00000011 r5:e80a9480 r4:e8edfe00 [ 457.291132] [<c0e29b1c>] (nl80211_send_station) from [<c0e2b18c>] (cfg80211_new_sta+0x90/0x1cc) [ 457.300850] r10:e80a9480 r9:e8edfe00 r8:ea678cca r7:00000a20 r6:00000000 r5:ec46d000 [ 457.309586] r4:ec46d9e0 [ 457.312433] [<c0e2b0fc>] (cfg80211_new_sta) from [<bf086684>] (rtw_cfg80211_indicate_sta_assoc+0x80/0x9c [r8723bs]) [ 457.324095] r10:00009930 r9:e85b9d80 r8:bf091050 r7:00000000 r6:00000000 r5:0000001c [ 457.332831] r4:c1606788 [ 457.335692] [<bf086604>] (rtw_cfg80211_indicate_sta_assoc [r8723bs]) from [<bf03df38>] (rtw_stassoc_event_callback+0x1c8/0x1d4 [r8723bs]) [ 457.349489] r7:ea678cc0 r6:000000a1 r5:f1225f84 r4:f086b000 [ 457.355845] [<bf03dd70>] (rtw_stassoc_event_callback [r8723bs]) from [<bf048e4c>] (mlme_evt_hdl+0x8c/0xb4 [r8723bs]) [ 457.367601] r7:c1604900 r6:f086c4b8 r5:00000000 r4:f086c000 [ 457.373959] [<bf048dc0>] (mlme_evt_hdl [r8723bs]) from [<bf03693c>] (rtw_cmd_thread+0x198/0x3d8 [r8723bs]) [ 457.384744] r5:f086e000 r4:f086c000 [ 457.388754] [<bf0367a4>] (rtw_cmd_thread [r8723bs]) from [<c014a214>] (kthread+0x170/0x174) [ 457.398083] r10:ed7a57e8 r9:bf0367a4 r8:f086b000 r7:e8ede000 r6:00000000 r5:e9975200 [ 457.406828] r4:e8369900 [ 457.409653] [<c014a0a4>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c) [ 457.417718] Exception stack(0xe8edffb0 to 0xe8edfff8) [ 457.423356] ffa0: 00000000 00000000 00000000 00000000 [ 457.432492] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 457.441618] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 457.449006] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c014a0a4 [ 457.457750] r4:e9975200 [ 457.460574] Code: 1a000003 e5953004 e3130001 1a000000 (e7f001f2) [ 457.467381] ---[ end trace 4acbc8c15e9e6aa7 ]---
  3. Actually, I have found a similar topic question in the forum. "Add: KERNELBRANCH='tag:v4.14.52' to build/userpatches/lib.config" I will give this one a go. ---------- Looks like this was a red herring. I had a look at the relevant git repo and it reports: root@ubuntu:~/build# git ls-remote -t https://github.com/rockchip-linux/kernel.git cde3c3fdf278bbf3edc895667a65c0cc16daee0c refs/tags/release-20161011 028bc40a6d227cb553236588c43f35ad7ae2af97 refs/tags/release-20161015 3e00738277533382e6a17148b80b09a8fabea268 refs/tags/release-20170220 49c16833b723b2c4fd0768483790a4f890cf2e10 refs/tags/release-20170417 3467c559d82943f7339578f92b0817b63b8b7ddc refs/tags/release-20170705 5ab215ee7f902201d4830b0b9536135143666b42 refs/tags/release-20171015 2801809213b2ebda0ab877ede0354d48fe95cde1 refs/tags/release-20171213 So the correct structure should be KERNELBRANCH='tag:release-yyyymmdd'. More on rockwell branches/tags: https://github.com/rockchip-linux/kernel
  4. Actually, I have found a similar topic question in the forum. "Add: KERNELBRANCH='tag:v4.14.52' to build/userpatches/lib.config" I will give this one a go.
  5. I downloaded the kernel source and kernel headers on a rk3288 rockchip (tinkerboardS) and noticed there was a mismatch between kernel version, armbian release and chipset (rockchip64) - see below. root@tinkerboard:~# uname -a Linux tinkerboard 4.4.174-rockchip #7 SMP Sun Feb 10 11:57:26 CET 2019 armv7l armv7l armv7l GNU/Linux root@tinkerboard:~# cat /etc/armbian-release # PLEASE DO NOT EDIT THIS FILE BOARD=tinkerboard BOARD_NAME="Tinkerboard" BOARDFAMILY=rockchip VERSION=5.75 LINUXFAMILY=rockchip BRANCH=default ARCH=arm IMAGE_TYPE=stable BOARD_TYPE=conf INITRD_ARCH=arm KERNEL_IMAGE_TYPE=zImage root@tinkerboard:/usr/src# ls * linux-rockchip64-default_4.4.178_5.85_config.xz linux-source-4.4.178-rockchip64.tar.xz
  6. I have spent a considerable amount reading docs and getting my head around building a custom default kernel & desktop image. Patching the kernel and optimising the desktop environment is working well. The remaining question is: How do I select a specific - kernel 4.4.174 (based on armbian-release 5.75) ? It defaults to 4.4.176 and 5.86.
  7. I have tried K5.x but the problem persists. It works on 4.4.y but that creates problems with other peripheral devices. I would like to use armbian with the tinkerboardS but for this the hotspot issue needs to be resolved. Due to time constraints this would have to be resolved quickly. Would you be interested in fixing this as a commercial engagement?
  8. When connecting to the built-in wifi adapter (wlan0) on the tinkerboard S (rockchip 3288), the kernel produces a stacktrace and clients can't connect. [ 839.074341] kernel BUG at mm/slub.c:3904! [ 839.078825] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM - (see http://ix.io/1J1n) Is there a fix for this?
  9. ok. so it looks like /sources/linux-mainline/linux-4.19.y/arch/arm/boot/dts/rk3288-tinker.dts sets stdout to serial2 (see below). I have changed it to serial1, then tried to recompile armbian with "compile.sh" but the dts reverts back to original during the process. How do I stop the automatic update of this file? chosen { stdout-path = "serial2:115200n8"; };
  10. Thanks for the prompt reply. Can you point me to some documentation on how to change console UART in DT? I would not know where to start here.
  11. We are looking at replacing the raspi3b+ with the tinkerboardS (rockchip 3288) in an embedded system, running armbian (bionic-4.19). Initial tests show that OS stability, board performance and form factor make the tinkerboardS a good substitute for the raspi. However, one issue we have run into is a conflict with pin 32 of the GPIO which is used by the hostboard for managing output devices. We have tried to turn off serial2 by removing the UART2 overlay and adding 'console=display' in /boot/armbianEnv.txt and also disabling & masking serial-getty@ttyS2.service but that hasn't stopped pin 32 from being chatty when connected to the hostboard. Is this possible that u-boot keeps writing/reading to and from ttyS2 (pin 32/33) regardless of the set kernel parameters? If so, how do we disable that?
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines