Hi Ahmad,
On Wed, Dec 04, 2019 at 02:05:36PM +0100, Ahmad Fatoum wrote:
> Hello Sascha,
>
> On 11/15/19 2:33 PM, Sascha Hauer wrote:
> > On Thu, Nov 14, 2019 at 02:28:08PM +0100, Ahmad Fatoum wrote:
> >> The todo split comment is a left-over from refactoring. Remove it.
> >>
> >> Signed-off-by:
So far changing the DCD table didn't trigger a rerun of the i.MX
image utility. To fix this, we need to have the DCD table as prerequisite
to the .imximg rule. The file name is contained in $(CFG_$(@F)), but
can't be used directly because $@ (and by extension @F) has no value
when first expanded
The next patch will add the .imxcfg file as a rule prerequisite, so the
target is rebuilt if it changes. Instead of duplicating it in all rules,
factor out the common parts into a imx_image_rule variable.
No functional change.
Signed-off-by: Ahmad Fatoum
---
images/Makefile.imx | 32
The following commit will introduce a variable define to remove the
duplication in the different [supe]*imximg rules.
Prepare for this by rearranging the command line flags to line up with
the letters in the extension (i.e. -e -s for esimximg instead of -s -e)
and by splitting off a multi-target
On 12/4/19 3:07 PM, Ahmad Fatoum wrote:
> BIOS and barebox would only need to implement the H/W.
s{H/W}{interface}
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | https://www.pengutronix.de/ |
31137 Hildesheim, Germany
It makes sense to support some ACPI tables like the WDAT (Watchdog
Action Table) in barebox. To facilitate this add a ACPI bus and
the necessary bits to integrate ACPI tables into the barebox
device/driver model as devices. These devices are identified by the
four byte signature, which drivers can
Microsoft specifies an ACPI Watchdog Action Table for its server
offerings that abstracts away hardware-specifics of watchdog devices.
This can be an alternative to implementing many different watchdog
driver in barebox for x86 H/W, as the driver is implemented in the
BIOS and barebox would only
We have a bus driver for ACPI, but no drivers yet. Add a simple (rather
useless) driver that exercises the API, which future drivers can be
based on. As soon as we have proper ACPI drivers, this driver could be
removed again.
Signed-off-by: Ahmad Fatoum
---
drivers/misc/Kconfig | 6
Hello Sascha,
On 11/25/19 9:28 AM, Sascha Hauer wrote:
> I would assume that when I can stop the remote processor with this
> parameter I should be able to start it here as well, no?
I've yet to think some more about this, but could you merge the first
two commits now?
Cheers
Ahmad
--
Hello Sascha,
On 11/15/19 2:33 PM, Sascha Hauer wrote:
> On Thu, Nov 14, 2019 at 02:28:08PM +0100, Ahmad Fatoum wrote:
>> The todo split comment is a left-over from refactoring. Remove it.
>>
>> Signed-off-by: Ahmad Fatoum
>> ---
>> drivers/net/designware_stm32.c | 1 -
>> 1 file changed, 1
This ports over the Linux v5.4 8250_pci driver. Unlike Linux, the
barebox ns16550 implementation provides less hooks for covering all the
quirky behavior of all the different 8250-"compatible" hardware blocks.
The barebox driver matches against all serial port the Linux driver does,
but for
Linux PCI drivers, like the incoming 8250_pci, make use of these
helpers. Port them over from Linux v5.4.
Signed-off-by: Ahmad Fatoum
---
drivers/pci/bus.c | 26 ++
include/linux/pci.h | 34 ++
2 files changed, 60 insertions(+)
diff
Linux drivers have a driver data member in the struct to associate
variant specific driver data with each device id. Do likewise in
barebox.
Signed-off-by: Ahmad Fatoum
---
include/linux/mod_devicetable.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/mod_devicetable.h
We have at least two places where we check if a efidev has a particular
guid and a follow-up commit will introduce a third place.
So lets factor it out into a helper.
Signed-off-by: Ahmad Fatoum
---
drivers/block/efi-block-io.c | 11 ++-
drivers/efi/efi-device.c | 11 ++-
UEFI 2.1D specifies two protocols for abstracting both the PCI host bus
controller and for PCI devices. The protocol for PCI devices provides
function pointers for accessing IO Port, Memory and PCI configuration
space, among others. The protocol for bus controllers provides the
ability to read the
The second (end) parameter of mem_malloc_init() denotes the last address
in the malloc region, so we need to subtract one from the current value
to arrive at the correct end. So far this went not noticed, because iomem
doesn't yet display barebox malloc memory region.
Signed-off-by: Ahmad Fatoum
The incoming EFI PCI root bridge IO protocol driver will register
PCI fixups. Executing them will fail because the hook function's
relocation information is stripped from the final barebox.efi binary.
Instead of adding each section by name, just keep all .rela* sections
in the final binary.
This
Currently, the macro can't be used for more complex expressions
like _dev->dev. Fix this by adding the missing parentheses.
Signed-off-by: Ahmad Fatoum
---
include/driver.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/driver.h b/include/driver.h
index
This allows us to use enum types instead of plain integers ttypes to
hold the values, which is done in a follow up commit.
Signed-off-by: Ahmad Fatoum
---
include/efi.h | 42 +++---
1 file changed, 23 insertions(+), 19 deletions(-)
diff --git a/include/efi.h
This series adds support for reusing existing barebox PCI drivers under
EFI. This means implementation of the EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_GUID,
instead of EFI_PCI_IO_PROTOCOL_GUID, which abstracts the devices and
handles enumeration.
This was tested with the default QEMU x86_64 machine and
On Mon, Dec 02, 2019 at 07:19:42AM -0800, Andrey Smirnov wrote:
> Everyone:
>
> This series is an attempt to share as much functionality between PBL
> ESDHC code and PIO case of regular ESDHC driver as possible, since
> both implementations are identical in a lot of ways.
>
> Tested on RDU2
21 matches
Mail list logo
