Now that sequence numbers are set up when devices are bound, this code is
not needed. Also, we should use dev_seq() instead of req_seq. Update the
whole file accordingly.
Also fix up APL cpu while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use the new sequence number in all cases. Since all devices are assigned
a number when bound, this hack should not be needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
This hack cannot work in the new sequence-numbering scheme. Remove it
while we wait for the maintainer to complete DM conversion as noted in
the existing comment.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use the new sequence number in all cases. Drop the rockchip case because
the sequence number should be 0 anyway, and assigning to the sequence
number is not permitted.
Signed-off-by: Simon Glass <sjg@chromium.org>
Now that we know the sequence number at bind time, there is no need for
special-case code in dm_pci_hose_probe_bus().
Note: the PCI_CAP_ID_EA code may need a look, but there are no test
failures so I have left it as is.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some buses have their own rules which require assigning sequence numbers
with a bus-specific algorithm. For example, PCI requires that sub-buses
are numbered higher than their parent buses, meaning effectively that
parent buses must be numbered only after all of their child buses have
been numbered.
Add a uclass flag to indicate that driver model should not assign sequence
numbers. In this case, the uclass must do it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Checking for seq == -1 is effectively checking that the device is
activated. The new sequence numbers are never -1 for a bound device, so
update the check.
Also drop the note about valid sequence numbers so it is accurate with the
new approach.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use the new sequence number in all cases. Drop the logic to check for a
valid number in designware_i2c, since it will always be valid.
Also drop the numbering in the uclass, since we can rely on driver
model giving us the right sequence numbers.
Signed-off-by: Simon Glass <sjg@chromium.org>
Several Octeon drivers operate by setting the sequence number of their
device. This should not be needed with the new sequence number setup. Also
it is not permitted. Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Update the core logic to use the new approach. For now the old code is
left as is. Update one test so it still passes.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present each device has two sequence numbers, with 'req_seq' being
set up at bind time and 'seq' at probe time. The idea is that devices
can 'request' a sequence number and then the conflicts are resolved when
the device is probed.
This makes things complicated in a few cases, since we don't really know
what the sequence number will end up being. We want to honour the
bind-time requests if at all possible, but in fact the only source of
these at present is the devicetree aliases. Since we have the devicetree
available at bind time, we may as well just use it, in the hope that the
required processing will turn out to be useful later (i.e. the device
actually gets used).
Add a new 'sqq' member, the bind-time sequence number. It operates in
parallel to the old values for now. All devices get a valid sqq value,
i.e. it is never -1.
Drop an #ifdef while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present this is passed a uclass ID and it has to do a lookup. The
callers all have the uclass pointer, except for the I2C uclass where the
code will soon be deleted.
Update the argument to a uclass * instead of an ID since it is more
efficient.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present various drivers etc. access the device's 'seq' member directly.
This makes it harder to change the meaning of that member. Change access
to go through a function instead.
The drivers/i2c/lpc32xx_i2c.c file is left unchanged for now.
Signed-off-by: Simon Glass <sjg@chromium.org>
The linker script uses alphabetic sorting to group the different linker
lists together. Each group has its own struct and potentially its own
alignment. But when the linker packs the structs together it cannot ensure
that a linker list starts on the expected alignment boundary.
For example, if the first list has a struct size of 8 and we place 3 of
them in the image, that means that the next struct will start at offset
0x18 from the start of the linker_list section. If the next struct has
a size of 16 then it will start at an 8-byte aligned offset, but not a
16-byte aligned offset.
With sandbox on x86_64, a reference to a linker list item using
ll_entry_get() can force alignment of that particular linker_list item,
if it is in the same file as the linker_list item is declared.
Consider this example, where struct driver is 0x80 bytes:
ll_entry_declare(struct driver, fred, driver)
...
void *p = ll_entry_get(struct driver, fred, driver)
If these two lines of code are in the same file, then the entry is forced
to be aligned at the 'struct driver' alignment, which is 16 bytes. If the
second line of code is in a different file, then no action is taken, since
the compiler cannot update the alignment of the linker_list item.
In the first case, an 8-byte 'fill' region is added:
.u_boot_list_2_driver_2_testbus_drv
0x0000000000270018 0x80 test/built-in.o
0x0000000000270018 _u_boot_list_2_driver_2_testbus_drv
.u_boot_list_2_driver_2_testfdt1_drv
0x0000000000270098 0x80 test/built-in.o
0x0000000000270098 _u_boot_list_2_driver_2_testfdt1_drv
*fill* 0x0000000000270118 0x8
.u_boot_list_2_driver_2_testfdt_drv
0x0000000000270120 0x80 test/built-in.o
0x0000000000270120 _u_boot_list_2_driver_2_testfdt_drv
.u_boot_list_2_driver_2_testprobe_drv
0x00000000002701a0 0x80 test/built-in.o
0x00000000002701a0 _u_boot_list_2_driver_2_testprobe_drv
With this, the linker_list no-longer works since items after testfdt1_drv
are not at the expected address.
Ideally we would have a way to tell gcc not to align structs in this way.
It is not clear how we could do this, and in any case it would require us
to adjust every struct used by the linker_list feature.
One possible fix is to force each separate linker_list to start on the
largest possible boundary that can be required by the compiler. However
that does not seem to work on x86_64, which uses 16-byte alignment in this
case but needs 32-byte alignment.
So add a Kconfig option to handle this. Set the default value to 4 so
as to avoid changing platforms that don't need it.
Update the ll_entry_start() accordingly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Driver model big rename for consistency
Python 3 clean-ups for patman
Update sandbox serial driver to use membuff
-----BEGIN PGP SIGNATURE-----
iQFFBAABCgAvFiEEslwAIq+Gp8wWVbYnfxc6PpAIreYFAl/Xcu0RHHNqZ0BjaHJv
bWl1bS5vcmcACgkQfxc6PpAIreZGpQgAqD7JsdNRHVKe2LEnYBR0sY1hlPH0+fz/
UW9hjpp3DTHasFc5w1pa6GJjJvexc0PqQnN3TSRz6+bQyhtIyvJUbqCbU9g2ApBu
3NIHipAa2kqD8B5WpWX6mMkBH5Vx9pAmrTV6oGt+MurEWoQ0M4SnaAkcnZqqLdHf
+fpiIDB/Kw1dnpWaleZSdZIJ4bPQaBkLcYIE3+jGrmcX+S5G8ZMH59MfVNZuzxfE
GpD+oRhkhjdDRr9MyRoTPvvALzF3Q+uo1HYbyYmyoOG7h3xCzcDqmkO4/NlZmhbV
T295C70d5rVDb8LFxinXlQ7fMLajjrwL4FVYMYADKQKK/IiKb7BJBQ==
=5uBK
-----END PGP SIGNATURE-----
Merge tag 'dm-pull-14dec20' of git://git.denx.de/u-boot-dm into next
Driver model tidy-up for livetree
Driver model big rename for consistency
Python 3 clean-ups for patman
Update sandbox serial driver to use membuff
As a way of keeping the driver declarations more consistent, add a warning
if the struct used does not end with _priv or _plat.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fix up the code style for those declarations that should now fit onto one
line, which is all of them that currently do not.
This is needed for dtoc to detect the structs correctly, at present.
Signed-off-by: Simon Glass <sjg@chromium.org>
This name is far too long. Rename it to remove the 'data' bits. This makes
it consistent with the platdata->plat rename.
Signed-off-by: Simon Glass <sjg@chromium.org>
We use 'priv' for private data but often use 'platdata' for platform data.
We can't really use 'pdata' since that is ambiguous (it could mean private
or platform data).
Rename some of the latter variables to end with 'plat' for consistency.
Signed-off-by: Simon Glass <sjg@chromium.org>
This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.
Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.
Signed-off-by: Simon Glass <sjg@chromium.org>
Update this file to reduce the number of pylint warnings. Also add a few
missing comments while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
This doesn't need to be passed the devicetree anymore. Drop it.
Also rename the function to drop the _fdt suffix.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present there are two copies of this code. With ofnode we can combine
them to reduce duplication. Update the dm_scan_fdt_node() function and
adjust its callers.
Signed-off-by: Simon Glass <sjg@chromium.org>
This is needed in at least one place. Avoid the conditional code in root.c
by adding this inline function.
Signed-off-by: Simon Glass <sjg@chromium.org>
This function is not necessary anymore, since device_bind_ofnode() does
the same thing and works with both flattree and livetree.
Rename it to indicate that it is special.
Signed-off-by: Simon Glass <sjg@chromium.org>
Test that an exception SIGILL is answered by a reset on the sandbox if
CONFIG_SANDBOX_CRASH_RESET=y or by exiting to the OS otherwise.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Provide a unit test that causes an illegal instruction to occur.
The test can be run with the following commands:
=> setenv efi_selftest exception
=> bootefi selftest
This might be the output:
Executing 'exception'
EFI application triggers exception.
Illegal instruction
pc = 0x1444d016, pc_reloc = 0xffffaa078e8dd016
UEFI image [0x0000000000000000:0xffffffffffffffff] '/\selftest'
UEFI image [0x000000001444b000:0x0000000014451fff] pc=0x2016 '/bug.efi'
Resetting ...
It would tell us that the exception was triggered by an instruction
0x2016 bytes after the load address of the binary with filename /bug.efi.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Implement the commands
* exception undefined - execute an illegal instruction
* exception sigsegv - cause a segment violation
Here is a possible output:
=> exception undefined
Illegal instruction
pc = 0x55eb8d0a7575, pc_reloc = 0x57575
Resetting ...
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a handler for SIGILL, SIGBUS, SIGSEGV.
When an exception occurs print the program counter and the loaded
UEFI binaries and reset the system if CONFIG_SANDBOX_CRASH_RESET=y
or exit to the OS otherwise.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Rather than implementing our own circular queue, use membuff. This allows
us to read multiple bytes at once into the serial input.
Signed-off-by: Simon Glass <sjg@chromium.org>
CONFIG_OF_CONTROL is always enabled for sandbox (as it should be for all
boards), so we can drop it. Also use IS_ENABLED() for the SPL check.
Signed-off-by: Simon Glass <sjg@chromium.org>
Update this, mostly to add comments for argument and return types. It is
probably still too early to use type hinting since it was introduced in
3.5.
Signed-off-by: Simon Glass <sjg@chromium.org>
This is useful anymore, since we always want to call chr() in Python 3.
Drop it and adjust callers to use chr().
Also drop ToChars() which is no-longer used.
Signed-off-by: Simon Glass <sjg@chromium.org>
We don't need these now that everything uses Python 3. Remove them and
the extra code in GetBytes() and ToBytes() too.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use an Enum instead of the current ad-hoc constants, so that there is a
data type associated with each 'type' value.
Signed-off-by: Simon Glass <sjg@chromium.org>
