Brief explanation of some input/outputs of RISC-V Core - caching

I am trying to analyze the code of fetch.v file from (https://github.com/ultraembedded/riscv/tree/master/core/riscv), but the designer has no documentation explaining anything and I am very beginner at the world of Verilog and digital design. What do these mean and do ?
,input fetch_accept_i
,input icache_accept_i
,input icache_valid_i
,input icache_error_i
,input [ 31:0] icache_inst_i
,input icache_page_fault_i
,input fetch_invalidate_i
,input branch_request_i
,input [ 31:0] branch_pc_i
,input [ 1:0] branch_priv_i
// Outputs
,output fetch_valid_o
,output [ 31:0] fetch_instr_o
,output [ 31:0] fetch_pc_o
,output fetch_fault_fetch_o
,output fetch_fault_page_o
,output icache_rd_o
,output icache_flush_o
,output icache_invalidate_o
,output [ 31:0] icache_pc_o
,output [ 1:0] icache_priv_o
,output squash_decode_o
The design is very complex. I wish there is a good resource I could read to understand his design

This is a file that describe the fetch unit of the core.
input means that's a input wire of the unit and output an output one.
The goal of this stage is to fetch instructions from the cache/memory and to send it to the decod unit.
Problem is that every implementation is different but basically :
,input fetch_accept_i : fetch is accepted by fetch stage (signal come from decode)
,input icache_accept_i : instruction cache accept the request from fetch unit
,input icache_valid_i : icache answer is valid
,input icache_error_i : icache answer made an error
,input [ 31:0] icache_inst_i : instruction fetch by the cache
,input icache_page_fault_i : cache did a page fault exception\
,input fetch_invalidate_i : fetch was invalid
,input branch_request_i : fetch unit made a branch request
,input [ 31:0] branch_pc_i : branch address of pc
,input [ 1:0] branch_priv_i : current priviledge of the core (M, S or U)
// Outputs
,output fetch_valid_o : fetch request is valid
,output [ 31:0] fetch_instr_o : ?
,output [ 31:0] fetch_pc_o : current pc which is fetch
,output fetch_fault_fetch_o : fetch did a fault
,output fetch_fault_page_o : fault did a page fault
,output icache_rd_o : ?
,output icache_flush_o : flush request to the cache
,output icache_invalidate_o : invalidate request to the cache
,output [ 31:0] icache_pc_o : current pc
,output [ 1:0] icache_priv_o : priviledge mode
,output squash_decode_o : ?
I'm not sure with my answer but according to the name of the signal i can do these assumptions

Related

Why does my service activator poll multiple messages?

Given the setup https://gist.github.com/gel-hidden/0a8627cf93f5396d6b73c2a6e71aad3e, I would expect when I send a message that the ServiceActivator would be called with a delay of 10 000 between messages.
The first channel takes in a list, then split the messages and then call another QueueChannel. But for some reason each pull polls all the split messages. I know I am missing something stupid, or I'm just too stupid to understand whats happening.
Related test case: https://gist.github.com/gel-hidden/de7975fffd0853ec8ce49f9d6fa6531d
Output:
2022-10-26 15:22:02.708 INFO 78647 --- [ scheduling-1] com.example.demo.DemoApplicationTests : Received message Hello
2022-10-26 15:22:02.708 INFO 78647 --- [ scheduling-1] com.example.demo.UpdateLocationFlow : Doing some work for model with id 2
2022-10-26 15:22:03.009 INFO 78647 --- [ scheduling-1] com.example.demo.UpdateLocationFlow : Completed some work for model with id 2
2022-10-26 15:22:03.017 INFO 78647 --- [ scheduling-1] com.example.demo.DemoApplicationTests : Received message World
2022-10-26 15:22:03.018 INFO 78647 --- [ scheduling-1] com.example.demo.UpdateLocationFlow : Doing some work for model with id 3
2022-10-26 15:22:03.319 INFO 78647 --- [ scheduling-1] com.example.demo.UpdateLocationFlow : Completed some work for model with id 3
2022-10-26 15:22:04.322 INFO 78647 --- [ scheduling-1] o.s.i.a.AggregatingMessageHandler : Expiring MessageGroup with correlationKey[1]
My thoughts is that the messages should be something like:
00:01 Doing some work for model with id 2
00:02 Completed some work for model with id 2
00:12 Doing some work for model with id 3
00:13 Completed some work for model it id 3
So, it is a bug in the Spring Integration around lifecycle management for the IntegrationFlowAdapter management. It just starts twice.
As a workaround I suggest to pull your #ServiceActivator handle() into an individual component with its own #Poller configuration and an inputChannel and outputChannel. In other words int must go outside of your UpdateLocationFlow. This way the IntegrationFlowAdapter won't have a control for its lifecycle and won't start it twice.
Meanwhile I'm looking how to fix it.
Thank you for reporting this!

Radis Caching Issue (Time Out issue)

I am facing radis issue. I have implemented centeralized radis cluster approch. But whenever the maximum number of services data get cached in the radis it causes an issue, "Read time out" occured.
Please anyone can give me suggestions what can i do?
Please find below properties:
spring :
redis :
database : ${redis.database}
#host : ${redis.host}
#port : ${redis.port}
password : ${redis.password}
pool :
max-active : 8
max-wait : 10000
max-idle : 8
min-idle : 1
timeout : 10000
redis :
cluster :
nodes : 10.xxx.x.xx:1234,10.xxx.x.xx:12365
database : 0
password : 'xxxxxx'
Error Logs:
2022-02-11 13:59:59,996 ERROR [nio-9120-exec-1008] c.h.l.framework.aop.ControllerAspect - [AGW2202111359590622605456]:
redis.clients.jedis.exceptions.JedisDataException: ERR Error running script (call to f_e78e961698f118a64316964cac1ca9e6008c29da): #user_script:34: #user_script: 34: -OOM command not allowed when used memory > 'maxmemory'.
at redis.clients.jedis.Protocol.processError(Protocol.java:127)
at redis.clients.jedis.Protocol.process(Protocol.java:161)
at redis.clients.jedis.Protocol.read(Protocol.java:215)
at redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:340)
at redis.clients.jedis.Connection.getOne(Connection.java:322)
at redis.clients.jedis.BinaryJedis.evalsha(BinaryJedis.java:3142)
at redis.clients.jedis.BinaryJedis.evalsha(BinaryJedis.java:3135)
at redis.clients.jedis.BinaryJedisCluster$119.execute(BinaryJedisCluster.java:1270)
at redis.clients.jedis.JedisClusterCommand.runWithRetries(JedisClusterCommand.java:120)
at redis.clients.jedis.JedisClusterCommand.runBinary(JedisClusterCommand.java:81)
at redis.clients.jedis.BinaryJedisCluster.evalsha(BinaryJedisCluster.java:1272)
at com.hisun.lemon.framework.jedis.JedisClusterConnection.evalSha(JedisClusterConnection.java:67)
at sun.reflect.GeneratedMethodAccessor1795.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.springframework.data.redis.core.CloseSuppressingInvocationHandler.invoke(CloseSuppressingInvocationHandler.java:57)
at com.sun.proxy.$Proxy537.evalSha(Unknown Source)

IOLock crashes mac OS when locking from IOUserService

We're using a data structure that requires locking and want to access it from an IOUserClient thread that runs when probing for a PCI device using PCIDriverKit.
Is using IOLock not allowed in this kind of thread? When trying to use IOLock from an IOUserClient thread that is not using an IOPCIDevice provider, it worked without a crash.
Is there any other ways to use locks from PCIDriverKit? Linking with pthreads.h seems pretty impossible (keep on getting errors as it is not part of the framework).
When calling IOLockLock we get a kernel crash stating:
panic(cpu 3 caller 0xffffff801a9c58f6): Kernel trap at 0xffffff801d6cbb33, type 14=page fault, registers:
CR0: 0x0000000080010033, CR2: 0x0000000000000028, CR3: 0x000000010cc6a074, CR4: 0x00000000000606e0
RAX: 0x0000000000000000, RBX: 0xffffff9359970250, RCX: 0xffffff86902e0c90, RDX: 0x0000000000000008
RSP: 0xffffffa05ff5bc60, RBP: 0xffffffa05ff5bc70, RSI: 0x0000000000000006, RDI: 0xffffff9359765000
R8: 0xffffff801b879b80, R9: 0xffffffc69a7581e0, R10: 0xffffff9359703800, R11: 0x0000000f9358cf60
R12: 0x000000000000001e, R13: 0x0000000000000046, R14: 0xffffff93596ee600, R15: 0xffffff8696094068
RFL: 0x0000000000010286, RIP: 0xffffff801d6cbb33, CS: 0x0000000000000008, SS: 0x0000000000000010
Fault CR2: 0x0000000000000028, Error code: 0x0000000000000000, Fault CPU: 0x3 VMM, PL: 0, VF: 0
Backtrace (CPU 3), Frame : Return Address
0xffffffa05ff5b680
Return Address
0xffffffa05ff5b680 : 0xffffff801a88e0dd mach_kernel : _handle_debugger_trap + 0x3fd
0xffffffa05ff5b6d0 : 0xffffff801a9d4f33 mach_kernel : _kdp_i386_trap + 0x143
0xffffffa05ff5b710 : 0xffffff801a9c552a mach_kernel : _kernel_trap + 0x55a
0xffffffa05ff5b760 : 0xffffff801a832a2f mach_kernel : _return_from_trap + 0xff
0xffffffa05ff5b780 : 0xffffff801a88d8fd mach_kernel : _DebuggerTrapWithState + 0xad
0xffffffa05ff5b8a0 : 0xffffff801a88dbf3 mach_kernel : _panic_trap_to_debugger + 0x273
0xffffffa05ff5b910 : 0xffffff801b09d81a mach_kernel : _panic + 0x54
0xffffffa05ff5b980 : 0xffffff801a9c58f6 mach_kernel : _sync_iss_to_iks + 0x2c6
0xffffffa05ff5bb00 : 0xffffff801a9c55dd mach_kernel : _kernel_trap + 0x60d
0xffffffa05ff5bb50 : 0xffffff801a832a2f mach_kernel : _return_from_trap + 0xff
0xffffffa05ff5bb70 : 0xffffff801d6cbb33 com.apple.iokit.IOUSBHostFamily : __ZN15IOUSBHostDevice4freeEv + 0x133
0xffffffa05ff5bc70 : 0xffffff801d69824d com.apple.iokit.IOUSBHostFamily : __ZN24AppleUSBHostLegacyClient4freeEv + 0x1b
0xffffffa05ff5bc90 : 0xffffff801d603c05 com.apple.iokit.IOUSBFamily : __ZN14AppleUSBDevice4freeEv + 0xf9
0xffffffa05ff5bce0 : 0xffffff801a97b7a1 mach_kernel : _iokit_notify + 0x141
0xffffffa05ff5bd20 : 0xffffff801a8935c2 mach_kernel : _ipc_kobject_server + 0x162
0xffffffa05ff5bd90 : 0xffffff801a869cf5 mach_kernel : _ipc_kmsg_send + 0x115
0xffffffa05ff5bdf0 : 0xffffff801a89489c mach_kernel : _mach_msg_send_from_kernel_proper + 0xbc
0xffffffa05ff5be20 : 0xffffff801a877f4a mach_kernel : _ipc_right_dealloc + 0x56a
0xffffffa05ff5bea0 : 0xffffff801a8821b8 mach_kernel : _mach_port_deallocate + 0x88
0xffffffa05ff5bed0 : 0xffffff801a87f1e3 mach_kernel : __kernelrpc_mach_port_deallocate_trap + 0x43
0xffffffa05ff5bef0 : 0xffffff801a9a982d mach_kernel : _mach_call_munger64 + 0x29d
0xffffffa05ff5bfa0 : 0xffffff801a833216 mach_kernel : _hndl_mach_scall64 + 0x16
Kernel Extensions in backtrace:
com.apple.iokit.IOUSBHostFamily(1.2)[BD7179E5-F2E2-3E86-83D5-F3EA5EE1EE3F]#0xffffff801d688000->0xffffff801d716fff
dependency: com.apple.driver.AppleBusPowerController(1.0)[C9BC6F50-42B7-3CD3-8608-B8F8236D3243]#0xffffff801bc2e000->0xffffff801bc31fff
dependency: com.apple.driver.AppleSMC(3.1.9)[1CE81438-E589-30EA-B40B-615AC3BDBED4]#0xffffff801bf56000->0xffffff801bf6efff
dependency: com.apple.driver.usb.AppleUSBCommon(1.0)[A8CD0277-B482-3874-8AA0-C7177FE83D1E]#0xffffff801c0a6000->0xffffff801c0a9fff
dependency: com.apple.driver.AppleUSBHostMergeProperties(1.2)[6086D16D-B5BA-3D7F-9EAD-F6E9E56459E4]#0xffffff801d783000->0xffffff801d783fff
dependency: com.apple.iokit.IOACPIFamily(1.4)[1B2FE91E-3EC7-3ED3-AF6B-E9C4BE29D5E3]#0xffffff801ce42000->0xffffff801ce43fff
com.apple.iokit.IOUSBFamily(900.4.2)[7215E3ED-95C3-3298-BB93-2458C14F1DAF]#0xffffff801d5e1000->0xffffff801d646fff
dependency: com.apple.driver.usb.AppleUSBCommon(1.0)[A8CD0277-B482-3874-8AA0-C7177FE83D1E]#0xffffff801c0a6000->0xffffff801c0a9fff
dependency: com.apple.iokit.IOPCIFamily(2.9)[99A70889-A31C-3B25-8E88-ADD3F317E4E4]#0xffffff801d36a000->0xffffff801d392fff
dependency: com.apple.iokit.IOUSBHostFamily(1.2)[BD7179E5-F2E2-3E86-83D5-F3EA5EE1EE3F]#0xffffff801d688000->0xffffff801d716fff
Process name corresponding to current thread: airportd
Boot args: -v keepsyms=1 tlbto_us=0 vti=9
Thanks
Update:
Eventually the crash was from a null pointer exception in my DEXT. My lesson is that such an exception in a DEXTs can crash your Mac completely, and the logs won't be informative at all (as you see). Best thing to do is debug with LLDB.
If you're hitting a kernel panic without loading any 3rd party kexts, that's a bug in macOS, and you should report it to Apple. This is irrespective of anything I say below. Trigger a panic without kernel code? Not your fault, this shouldn't be possible, report it or it won't be fixed. Especially if you have a way to trigger it fairly reliably. File a DTS TSI if this issue is costing you money.
That crash stack doesn't look like it's directly triggered by a call from a dext. So if your lock is indeed causing the crash, it's somehow incidental - probably a memory corruption issue - so it's hard to say what specifically about your code is triggering the problem. Just because it turns up when you lock in a certain place, that doesn't mean it's caused by that. It could also be caused by the resulting timing changes.
In dexts, consider using OSAction for synchronisation, and note that you can schedule to handle methods on a specific dispatch queue by marking the method with the QUEUENAME macro in the .iig file. Unfortunately, all external methods are dispatched through the single ExternalMethod method, so if you need a single user client to execute external methods on different threads, you can't do that as far as I'm aware.
Make sure you haven't hit a race condition inside your dext (again, it shouldn't KP if you have, but bear with me) - by default, each object has its own unique default queue - this means that methods in the main driver object and in the user client object will run on different threads so if the two objects access each other, that must be done in a threadsafe way, or you need to explicitly use the same queue as the driver service for all user client instances.

No i2c nodes coming in linux sysfs, required kernel configs?

I have a Hikey LeMaker 620 on which I am trying to enable I2C as currently I am not getting /dev/i2c* nodes.
I am using the docs here : https://github.com/96boards/documentation/blob/master/consumer/hikey/hikey620/build/linux-kernel.md
I see that
I2C_DESIGNWARE_PLATFORM
I2C_CHARDEV
are already enabled, still I do not see anything in /sys/bus/i2c/devices/ and as a result my i2cdetect fails saying “/dev/i2c/0 : No such file or directory”
Are there any kernel configs which I am missing?
EDIT
Here are the dmesg logs
/ # dmesg | grep i2c
[ 0.251154] i2c-core: driver [dummy] registered
[ 0.284233] i2c-core: driver [pca953x] registered
[ 0.286078] i2c-core: driver [sec_pmic] registered
[ 0.287137] i2c_designware f7100000.i2c: could not find pctldev for node /soc/pinmux#f7010000/i2c0_pmx_func, deferring probe
[ 0.287167] i2c_designware f7101000.i2c: could not find pctldev for node /soc/pinmux#f7010000/i2c1_pmx_func, deferring probe
[ 0.287188] i2c_designware f7102000.i2c: could not find pctldev for node /soc/pinmux#f7010000/i2c2_pmx_func, deferring probe
[ 0.323590] i2c-core: driver [cs2000-cp] registered
[ 0.328647] i2c-core: driver [fan53555-regulator] registered
[ 0.340913] i2c-core: driver [cros-ec-i2c] registered
[ 0.341005] i2c-core: driver [max77620] registered
[ 0.341054] i2c-core: driver [rk808] registered
[ 0.351637] i2c-core: driver [usb3503] registered
[ 0.353610] i2c-core: driver [rtc-ds3232] registered
[ 0.354842] i2c /dev entries driver
[ 0.355782] i2c-core: driver [pca954x] registered
[ 0.356294] i2c-core: driver [bq27xxx-battery] registered
[ 0.501408] i2c-core: driver [hmc5843] registered
[ 2.209817] i2c_designware f7100000.i2c: Unknown Synopsys component type: 0x00000000
[ 2.218809] i2c_designware f7101000.i2c: Unknown Synopsys component type: 0x00000000
[ 2.227621] i2c_designware f7102000.i2c: Unknown Synopsys component type: 0x00000000
This turned out to be a bug.
More discussion here : https://discuss.96boards.org/t/kernel-configuration-for-enabling-i2c-on-hikey-lemaker-620/7517

To read TMP adc sensor data over mcp3008 (spi) with the customised driver on raspberry pi

I am writing a mcp3008 device driver without iio support for learning purpose. I have followed this link for pin connections.
I have attached my source code.
Driver is successfully bound to spi subsys, dmesg is as
[ 9.053293] bus: 'platform': driver_probe_device: matched device soc:audio with driver bcm2835_AUD0
[ 9.053316] bus: 'platform': really_probe: probing driver bcm2835_AUD0 with device soc:audio
[ 9.103796] driver: 'bcm2835_AUD0': driver_bound: bound to device 'soc:audio'
[ 9.103843] bus: 'platform': really_probe: bound device soc:audio to driver bcm2835_AUD0
[ 11.703933] systemd-journald[116]: Received request to flush runtime journal from PID 1
[ 13.170530] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
[ 14.801684] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1
[ 16.057113] Adding 102396k swap on /var/swap. Priority:-1 extents:3 across:1773568k SSFS
[ 26.739940] random: crng init done
[ 66.338696] bus: 'spi': driver_probe_device: matched device spi0.1 with driver aartyaa_mcp3008
[ 66.338720] bus: 'spi': really_probe: probing driver aartyaa_mcp3008 with device spi0.1
[ 66.338831] aartyaa_mcp3008 spi0.1: aaartyaa came in probe, master dev = spi0
[ 66.338845] aartyaa_mcp3008 spi0.1: mcp3008_device_alloc : devres is allocated
[ 66.338855] aartyaa_mcp3008 spi0.1: mcp3008_device_alloc : dev is added to devres
[ 66.338864] aartyaa_mcp3008 spi0.1: mcp3008_probe : trasefer buffer is ready
[ 66.338871] aartyaa_mcp3008 spi0.1: mcp3008_probe : initing spi msg
[ 66.338881] aartyaa_mcp3008 spi0.1: mcp3008_probe : creating sysfs for mcp3008
[ 66.338912] driver: 'aartyaa_mcp3008': driver_bound: bound to device 'spi0.1'
[ 66.338946] bus: 'spi': really_probe: bound device spi0.1 to driver aartyaa_mcp3008
I have connected TMP36 to channel1 of mcp3008. I am trying to read analog value in a sysfs entry(/sys/bus/spi/devices/spi0.1/aartyaa_mcp3008).
I have tried with giving 3V3 to channel1 as well. But I am not able to read adc value. dmesg is as =>
[ 101.311640] aartyaa_mcp3008 spi0.1: mcp3008_aartyaa_show_data
[ 101.311807] aartyaa_mcp3008 spi0.1: mcp3008_conversion : ret = 0
[ 101.311822] aartyaa_mcp3008 spi0.1: mcp3008_aartyaa_show_data : ret = 0
How can I read a TMP36 adc value over mcp3008 using this driver.
Any help will be appreciated and thanks a lot.
regret for inconvenience.
CE and deferential pins were wrongly connected on the board.
Driver works fine as it was expected.
Thanks.

Resources