Thanks!
> -Original Message-
> From: Ahmad Fatoum
> Sent: Thursday, November 30, 2023 9:28 AM
> To: Lior Weintraub ; barebox@lists.infradead.org
> Subject: Re: Pass user defines for Barebox build
>
> CAUTION: External Sender
>
> Hi,
>
> On 29.11.23 11:13, Lior Weintraub wrote:
> > Than
Hi,
On 29.11.23 11:13, Lior Weintraub wrote:
> Thanks Ahmad,
>
> On our Barebox porting we have a small piece of code that needs different
> coding if we build it for QEMU or for the real HW.
> We are used to pass build defines in other projects so that is way we took
> this approach.
>
> I
We currently conflate flags for *.dtb and *.dtbo targets:
- -@ doesn't make sense for overlays, but is used there anyway when
CONFIG_OF_OVERLAY_LIVE
- DTC_CPP_FLAGS_basetarget.dtbo and DTC_CPP_FLAGS_basetarget.dtb are
interchangeable
Fix this by allowing flags to be specific to eithe
Overlays, especially new style ones, are prone to trigger the reg
formatting warnings if fragments add node with reg properties without
also patching the parent:
&phy0 {
reg = <7>;
};
In order to add #address-cells and #size-cells, the parent would need to
be overlaid, which is a bad
U-Boot interprets "kernel_noload" to mean that the load and entry
addresses shall be ignored[1] and that the kernel image should be executed
in-place, unless compressed[2]. The entry and load addresses are still
mandatory and need to be initialized to some dummy value according to
spec[3].
barebox
Hi,
On 29.11.23 12:33, Steffen Trumtrar wrote:
> dma_sync_single_for_cpu(macb->dev,
> macb->rx_buffer_phys +
> macb->rx_buffer_size * macb->rx_tail,
> length, DMA_FROM_DEVICE);
> @@ -198,6 +190,7 @@ static i
On 29.11.23 12:33, Steffen Trumtrar wrote:
> @@ -181,14 +189,15 @@ static int gem_recv(struct eth_device *edev)
> barrier();
> status = macb->rx_ring[macb->rx_tail].ctrl;
> length = MACB_BFEXT(RX_FRMLEN, status);
> - buffer = macb->rx_buffer + m
barebox images are designed to be chainloadable and can be loaded as if
they were a kernel by other bootloaders. The documentation lists
examples for two ways to achieve this with U-Boot preinstalled on the
board. They are not as clear as they could be as the resulting uImage
is called image in the
We don't use the DCD table for RAM setup on i.MX8M, so no special
barebox binary is needed for USB upload.
CONFIG_HABV4_IMAGE_SIGNED_USB is already i.MX6-specific, but point this
out in the documentation explicitly as well.
Signed-off-by: Ahmad Fatoum
---
Documentation/boards/imx.rst | 2 +-
1
Instead of directly reading from memory addresses and inserting
sw barriers to be sure that the compiler will not move loads/stores
behind this point, just use proper volatile writel/readl accesses.
Signed-off-by: Steffen Trumtrar
---
drivers/net/macb.c | 53 +
rx_buffer gets dma_alloc'ed but is never dma_map'ed and therefor not
flushed before it is initially used.
Map the rx_buffer when the macb is initialized and unmap it on ether_halt.
While at it, cleanup the dma_alloc_coherent rx_ring/tx_ring, too.
Signed-off-by: Steffen Trumtrar
---
drivers/net
https://lore.barebox.org/20231129-v2023-08-0-topic-macb-v2-0-4dc2cb4d5...@pengutronix.de
Changes in v2:
- change dma_map_single to DMA_FROM_DEVICE
- drop (unsigned long) casts in dma_sync_*
- rework writel/setbits/clearbits to keep semantics
- Link to v1:
https://lore.barebox.org/20231128-v2023-08-0-topic
On 29.11.23 10:54, Steffen Trumtrar wrote:
> Instead of directly reading from memory addresses and inserting
> sw barriers to be sure that the compiler will not move loads/stores
> behind this point, just use proper volatile writel/readl accesses.
>
> Signed-off-by: Steffen Trumtrar
> ---
> driv
Thanks Ahmad,
On our Barebox porting we have a small piece of code that needs different
coding if we build it for QEMU or for the real HW.
We are used to pass build defines in other projects so that is way we took this
approach.
I assume the official way would be to set a new defconfig and de
The rx_buffer is only dma_alloc'ed but never properly flushed.
Fix that.
While at it, also use proper volatile access instead of sw barriers.
Signed-off-by: Steffen Trumtrar
---
Changes in v2:
- change dma_map_single to DMA_FROM_DEVICE
- drop (unsigned long) casts in dma_sync_*
- rework writel/s
rx_buffer gets dma_alloc'ed but is never dma_map'ed and therefor not
flushed before it is initially used.
Map the rx_buffer when the macb is initialized and unmap it on ether_halt.
While at it, cleanup the dma_alloc_coherent rx_ring/tx_ring, too.
Signed-off-by: Steffen Trumtrar
---
drivers/net
Instead of directly reading from memory addresses and inserting
sw barriers to be sure that the compiler will not move loads/stores
behind this point, just use proper volatile writel/readl accesses.
Signed-off-by: Steffen Trumtrar
---
drivers/net/macb.c | 52 +
eMMC specification JESD84-B51 states page 126
table 49 — Basic commands (class 0 and class 1) that
CMD12 (STOP_TRANSMISSION) response is R1 for read cases
and R1b for write cases.
Fix wrong reponse type in eMMC read cases.
Signed-off-by: Yann Sionneau
---
drivers/mci/mci-core.c | 3 ++-
1 file
Please disregard this patch, I'll re-send a new one that actually applies...
On 29/11/2023 10:36, Yann Sionneau wrote:
eMMC specification JESD84-B51 states page 126
table 49 — Basic commands (class 0 and class 1) that
CMD12 (STOP_TRANSMISSION) response is R1 for read cases
and R1b for write case
eMMC specification JESD84-B51 states page 126
table 49 — Basic commands (class 0 and class 1) that
CMD12 (STOP_TRANSMISSION) response is R1 for read cases
and R1b for write cases.
Fix wrong reponse type in eMMC read cases.
Signed-off-by: Yann Sionneau
---
drivers/mci/mci-core.c | 3 ++-
1 file
On Mon, Nov 27, 2023 at 07:35:54AM +0100, Ahmad Fatoum wrote:
> of_device_create_on_demand won't create a new device if the device tree
> node already has a device associated. What it will do however, is to
> create devices for all parent nodes in the device tree if they don't
> already exist. This
According to eMMC Protocol Specification JESD84-B51 Section 7.5
```
The writable 16-bit relative Device address (RCA) register carries the Device
address assigned by the host during the Device identification. This address is
used for the addressed host-Device communication after the Device identif
22 matches
Mail list logo
