I'm writing a SNES emulator for fun, and I always wondered what is the name of the part that is not the bank:
Effective address: $80 $0000
^-- Bank ^-- ???
Per page 8 of the W65C816S data sheet:
During modes of operation, the 8-bit Data Bank Register holds the bank address for memory transfers. The 24-bit address is composed of the 16-bit instruction effective address and the 8-bit Data Bank address.
And, similarly, on page 9:
The 8-bit Program Bank Register holds the bank address for all instruction fetches. The 24-bit address consists of the 16-bit instruction effective address and the 8-bit Program Bank address.
So "instruction effective address" seems to be Western Digital's phrase for the low 16 bits.
I would dare imagine 'offset' is also commonly used though, through similarity to Intel's more-widely-familiar real mode segment:offset addressing scheme.
Related
I want to make a kernel module that read the DRAM counters to get the number of data read from DRAM (https://software.intel.com/en-us/articles/monitoring-integrated-memory-controller-requests-in-the-2nd-3rd-and-4th-generation-intel).
In that page, they say
"The BAR is available (in PCI configuration space) at Bus 0; Device 0; Function 0; Offset 048H", and UNC_IMC_DRAM_DATA_READS, which I want to read, is on "BAR + 0x5050".
Does it mean that I can get the physical address of DRAM Counter by typing
sudo setpci 00:00:0 48.L
and then + 0x5050 to get the address where the UNC_IMC_DRAM_DATA_READS?
Actually,
sudo setpci 00:00:0 48.L
outputs
fed10001
, and I accessed 0xfed15051 with busybox.
sudo busybox devmem 0xfed15051
However, the two leftmost bit, I mean "00" in 0x00123456, are always zero.
What was wrong, and how can I get the physical address correctly with Bus, Device, Function, and Offset.
Thank you :)
The low bit is an enable bit and should be excluded from the address you use. See for example https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/xeon-e3-1200v6-vol-2-datasheet.pdf (section 3.12 page # 57) -- where it's documented as the MCHBAREN flag.
This document also provides detailed register descriptions of the same registers mentioned in that tech note -- starting at section 7.43 page # 202.
In general, accesses to PCI registers are pretty much always done on 32-bit (DWORD) boundaries. You'll almost never find a counter that overlaps 32-bit words.
I'm trying to understand a little bit more about Linux kernel IPSec networking by looking at the kernel source. I understand conceptually that IPSec prevents replay attacks with a sequence number and a replay window, i.e. if a recipient receives a packet with a sequence number that is not within the replay window, or it has received before, then it drops that packet and increments the replay counter.
I'm trying to correlate this to the structure xfrm_replay_state_esn which is defined as such:
struct xfrm_replay_state_esn {
unsigned int bmp_len;
__u32 oseq;
__u32 seq;
__u32 oseq_hi;
__u32 seq_hi;
__u32 replay_window;
__u32 bmp[0];
};
I've tried searching for documentation, but it's scant and I haven't been able to find a man of the various functions and structures, so I don't understand what the individual fields relate to.
XFRM is an IPSec implementation for the Linux kernel. The name XFRM stands for "transform" referencing the transformation of IP packets as per the IPSec protocol.
The following RFCs are relevant for IPSec:
RFC4301: Definition of the IPSec protocol.
RFC4302: Definition of the Authentication Header (AH) sub-protocol for ensuring authenticity of IP packets.
RFC4303: Definition of the Encapsulating Security Payload (ESP) sub-protocol for ensuring authenticity and secrecy of IP packets.
The IPSec protocol allows for sequence numbers of size 32 bits or 64 bits. The 64 bit sequence numbers are referred to as Extended Sequence Numbers (ESN).
The anti-replay mechanism is defined in the RFCs for both AH and ESP. The mechanism keeps a window of acceptable sequence numbers of incoming packets. The window extends back from the highest sequence number received so far, defining a lower bound for the acceptable sequence numbers. When receiving a sequence number below that bound, it is rejected. When receiving a sequence number higher than the current highest sequence number, the window is shifted forward. When receiving a sequence number within the window, the mechanism will mark this sequence number in a checklist for ensuring that each sequence number in the window is only received once. If the sequence number has already been marked, it is rejected.
This checklist can be implemented as a bitmap, where each sequence number in the window is represented by a single bit, with 0 meaning this sequence number has not been received yet, and 1 meaning it has already been received.
Based on this information, the meaning of the fields in the xfrm_replay_state_esn struct can be given as follows.
The struct holds the state of the anti-replay mechanism with extended sequence numbers (64 bits):
The highest sequence number received so far is represented by seq and seq_hi. Each is a 32 bit integer, so together they can represent a 64 bit number, with seq holding the lower 32 bit and seq_hi holding the higher 32 bit. The reason for splitting the 64 bit value into two 32 bit values, instead of representing it as a single 64 bit variable, is that the IPSec protocol mandates an optimization where only the lower 32 bit of the sequence number are included in the package. For this reason, it is more convenient to have the lower 32 bits as a separate variable in the struct, so that it can be accessed directly without resorting to bit-operations.
The sequence number counter for outgoing packages is tracked in oseq and oseq_hi. As before, the 64 bit number is represented by two 32 bit variables.
The size of the window is represented by replay_window. The smallest acceptable sequence number if given by the sequence number expressed by seq and seq_hi minus replay_window plus one.
The bitmap for checking off received sequence numbers within the window is represented by bmp. It is defined as a zero-sized array, but when the memory for the struct is allocated, additional memory is reserved after the struct, which can then be accessed e.g. with bmp[i] (which is of course just syntactic sugar for *(bmp+i)). The size of the bitmap is held in bmp_len. It is of course related to the window size, i.e. window size divided by 8*sizeof(u32), rounded up. I would speculate that it is stored explicitly to avoid having to recalculate this value frequently.
What I understand so far is address width is the number of bits in an address.
For example, 4 bits width address can have 2^4 = 16 cases. And what I'm really uncertain is addressability. Based on what I learned is "the size of the most basic unit that can be named by address". So, if we have 4 bits address width and 2 bits addressability, what happens?
I've been really curious about it for a couple of weeks, but still bummer.
Could you guys explain those things by drawing or something?
I think you do get it. There is the number of address bits, the width if you will, and there is the size of the unit those things address. so 8 bits means you have 256 things, 16 bits of address 65536 things. The size of thing is completely independent of the number of address bits. From a programmers perspective almost always we deal in units of bytes, so 8 bits of address would be 256 bytes, 32 bits of address would be 4 gigabytes. As you dig into the logic it is often wasteful to use a byte based address, if you have a peripheral that has 32 bit wide registers and you can only access those as whole 32 bit registers then do you need to connect address line 0 or 1? often not. so at that peripheral the address bus however wide it is (often the whole address bus to the peripheral is a subset of the address bus higher up closer to the processor/software, and those address bits are in units of 32 bit words.
To make things even more confusing, memory parts are often defined in terms of bits, even if they have an 8 or 16 bit data bus. So you might have a 4M part but that is megabits not megabytes...
As I understand the term "word length" (spi_bits_per_word) in spi, defines the CS (chip select) active time.
It therefore seems that linux driver will function correctly when dealing with simple spi protocols which keeps word size constant.
But, How can we deal with spi protocols which use different spi size as part of protocol.
for example cs need to be active for sending spi word - 9 bits, and then reading spi - 8 bits or 24 bits (the length of the register read is different each time, depends on register)
How can we implement that using spi_write_then_read ?
Do we need to set bits_per_word size for the sending and then another bits_per_word for the receiving ?
Regards,
Ran
"word length" means number of bits you can send in one transaction. It doesn't defines the CS (chip select) active time. You can keep it active for whatever time you want(least is for word-length).
SPI has got some format. You cannot randomly read-write whatever number of bits you want.Most of SPI supports 4-bit, 8-bit, 16-bit and 32-bit mode. If the given mode doesn't satisfy your requirement then you need to break your requirement. For eg:- To read 24-bit data, we need to use 8-bit word-length transfer for 3 times.
Generally SPI is fullduplex means it will read at same time it will write.
I need to read serial number of MiFare card usin WinSCard. I am able to read 7B UID from the MiFare card.
The confusion is that i dont know if the UID and the serial number of
MiFare card are same?!!
I have googled the issue but only could get partial success. I found a question on stackoverflow also but it did not help.
I found a document of NXP online which says UID and serial number are different. (on page number 3, line number 5)
There is an application of OmniKey that reads the serial number of the card, and it also returns UID only.
NXP documentation says UID <> Serial Number and a other standard OmniKey application returns UID as Serial Number.
I have started pulling my hair off on the issue. I'd greatly appreciate if anyone could help.
Each smart card contains an integrated chip with a unique permanent identification (UID) number burned-in during the manufacturing process. This UID is often referred to as the Card Serial Number (CSN). The card serial number is not encrypted and any reader that is ISO compliant can read the card serial number.
Edit 1:
Mifare Card Serial Number is the unique identifier defined in ISO 14443-3A. There are 3 types of UID defined in the standard - single (4 bytes), double (7 bytes) and triple (10 bytes). Only in first versions of the Mifare card, the UID was 4 bytes but now have migrated to 7 bytes.
EDIT 2:
It might be helpful to you...
What is the difference between a 4 byte UID and a 4 byte ID?
A 4 byte UID is an identifier which has been assigned by the card
manufacturer using a controlled database. This database ensures that a
single identifier is not used twice. In contradiction, a 4 byte ID is an
identifier which may be assigned to more then one contactless chip over
the production time of a product so that more then one card with the same
identified may be deployed into one particular contactless system.
The differentiation in this case comes from the fact that a "Serial Number" implies that the numbers are a series, thus sequentially assigned.
MIFARE cards have Unique Identification Numbers (or in short UID), which are generated by an internal rule which is not necessarily sequential. This means that if you see a card with UID 01020304050607 it does not mean that there are at least that many cards produced so far.
If you ever see someone referring to the Card Serial Number, they are in fact referring to the UID.
The only last confusion can come from the fact that MIFARE cards can be configured to return Random IDs during activation. If that is the case, you would get different "UID" each time you activate the card. In that scenario you need to read the data contained in Block 0 (for which you will need to know the key to sector 0) to get the real UID of the card.
For DesFire cards:
UID is analogous to ethernet MAC address. It is assigned by the chip
manufacturer from a database. Everyone who creates applications for
the card has access to the UID.
The Card Serial Number is specific
to the application loaded on to the card. It can only be accessed by
that application via an encryption key. If the card had several applications loaded on to
it (unlikely but possible), then each could have a different CSN.