[U-Boot] [PATCH 0/2] sunxi: musb: Fix usb reset handling
Hi Ian, Paul,
Here is a patch to fix the problems where most usb devices will no longer
work after a usb reset , when connected to the otg controller in host
mode + a related cleanup patch.
Ian I would like to send out a PR with these 2 as fixed for v2015.07, can
you review them please? Note I've not tested this with the otg in gadget
mode, but we do not have gadget mode enabled by default anywhere atm, so
I still consider this suitable as a bugfix for v2015.07.
Paul, can you test these with gadget mode? Specifically if they help the
problem you were seeing when switching roles?
Also this bit from the kernel code for the sunxi glue may be relevant
to your problems:
if ((musb-int_usb MUSB_INTR_RESET) !is_host_active(musb)) {
/* ep0 FADDR must be 0 when (re)entering peripheral mode */
musb_ep_select(musb-mregs, 0);
musb_writeb(musb-mregs, MUSB_FADDR, 0);
}
This is from the interrupt handler in the sunxi-musb glue in the kernel,
maybe we can do the same, and/or maybe we need to do:
/* ep0 FADDR must be 0 when (re)entering peripheral mode */
musb_ep_select(musb-mregs, 0);
musb_writeb(musb-mregs, MUSB_FADDR, 0);
From sunxi_musb_disable?
From my experience sofar we should avoid doing a full reset from musb_stop /
sunxi_musb_disable as musb_init_controller never gets re-run, so doing a
full reset leaves things in a bad state where only ep0 still seems to work,
this may be what you were seeing before.
Regards,
Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] sunxi: musb: Remove unused sunxi_musb_exit method
Remove the unused sunxi_musb_exit method, there is no code in u-boot
calling the exit method, and our implementation was broken as it did
not disable the clocks and asserted reset.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/usb/musb-new/sunxi.c | 34 --
1 file changed, 34 deletions(-)
diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
index 42c6725..052e065 100644
--- a/drivers/usb/musb-new/sunxi.c
+++ b/drivers/usb/musb-new/sunxi.c
@@ -105,16 +105,6 @@ static void USBC_EnableIdPullUp(__iomem void *base)
musb_writel(base, USBC_REG_o_ISCR, reg_val);
}
-static void USBC_DisableIdPullUp(__iomem void *base)
-{
- u32 reg_val;
-
- reg_val = musb_readl(base, USBC_REG_o_ISCR);
- reg_val = ~(1 USBC_BP_ISCR_ID_PULLUP_EN);
- reg_val = USBC_WakeUp_ClearChangeDetect(reg_val);
- musb_writel(base, USBC_REG_o_ISCR, reg_val);
-}
-
static void USBC_EnableDpDmPullUp(__iomem void *base)
{
u32 reg_val;
@@ -125,16 +115,6 @@ static void USBC_EnableDpDmPullUp(__iomem void *base)
musb_writel(base, USBC_REG_o_ISCR, reg_val);
}
-static void USBC_DisableDpDmPullUp(__iomem void *base)
-{
- u32 reg_val;
-
- reg_val = musb_readl(base, USBC_REG_o_ISCR);
- reg_val = ~(1 USBC_BP_ISCR_DPDM_PULLUP_EN);
- reg_val = USBC_WakeUp_ClearChangeDetect(reg_val);
- musb_writel(base, USBC_REG_o_ISCR, reg_val);
-}
-
static void USBC_ForceIdToLow(__iomem void *base)
{
u32 reg_val;
@@ -292,22 +272,8 @@ static int sunxi_musb_init(struct musb *musb)
return 0;
}
-static int sunxi_musb_exit(struct musb *musb)
-{
- pr_debug(%s():\n, __func__);
-
- USBC_DisableDpDmPullUp(musb-mregs);
- USBC_DisableIdPullUp(musb-mregs);
- sunxi_usb_phy_power_off(0);
- sunxi_usb_phy_exit(0);
-
- return 0;
-}
-
const struct musb_platform_ops sunxi_musb_ops = {
.init = sunxi_musb_init,
- .exit = sunxi_musb_exit,
-
.enable = sunxi_musb_enable,
.disable= sunxi_musb_disable,
};
--
2.4.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] sunxi: musb: Do not fully reset the controler from sunxi_musb_disable
Fully resetting the controller is a too big hammer, and the musb_core will
then afterwards fail to communicate with any endpoints other then 0 as
too much state was cleared.
Instead report vbus low for 200ms which will effectively end the current
session without needing to do a full reset.
This fixes usb mass-storage devices no longer working after a usb reset
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/usb/musb-new/sunxi.c | 52 ++--
1 file changed, 31 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
index e8a3a23..42c6725 100644
--- a/drivers/usb/musb-new/sunxi.c
+++ b/drivers/usb/musb-new/sunxi.c
@@ -157,6 +157,17 @@ static void USBC_ForceIdToHigh(__iomem void *base)
musb_writel(base, USBC_REG_o_ISCR, reg_val);
}
+static void USBC_ForceVbusValidToLow(__iomem void *base)
+{
+ u32 reg_val;
+
+ reg_val = musb_readl(base, USBC_REG_o_ISCR);
+ reg_val = ~(0x03 USBC_BP_ISCR_FORCE_VBUS_VALID);
+ reg_val |= (0x02 USBC_BP_ISCR_FORCE_VBUS_VALID);
+ reg_val = USBC_WakeUp_ClearChangeDetect(reg_val);
+ musb_writel(base, USBC_REG_o_ISCR, reg_val);
+}
+
static void USBC_ForceVbusValidToHigh(__iomem void *base)
{
u32 reg_val;
@@ -205,42 +216,41 @@ static irqreturn_t sunxi_musb_interrupt(int irq, void
*__hci)
return retval;
}
+/* musb_core does not call enable / disable in a balanced manner sigh */
+static bool enabled = false;
+
static void sunxi_musb_enable(struct musb *musb)
{
pr_debug(%s():\n, __func__);
+ if (enabled)
+ return;
+
/* select PIO mode */
musb_writeb(musb-mregs, USBC_REG_o_VEND0, 0);
- if (is_host_enabled(musb)) {
- /* port power on */
- sunxi_usb_phy_power_on(0);
- }
+ if (is_host_enabled(musb))
+ sunxi_usb_phy_power_on(0); /* port power on */
+
+ USBC_ForceVbusValidToHigh(musb-mregs);
+
+ enabled = true;
}
static void sunxi_musb_disable(struct musb *musb)
{
- struct sunxi_ccm_reg *ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
-
pr_debug(%s():\n, __func__);
- /* Put the controller back in a pristane state for usb reset */
- if (musb-is_active) {
- sunxi_usb_phy_exit(0);
-#ifdef CONFIG_SUNXI_GEN_SUN6I
- clrbits_le32(ccm-ahb_reset0_cfg, 1 AHB_GATE_OFFSET_USB0);
-#endif
- clrbits_le32(ccm-ahb_gate0, 1 AHB_GATE_OFFSET_USB0);
+ if (!enabled)
+ return;
- mdelay(10);
+ if (is_host_enabled(musb))
+ sunxi_usb_phy_power_off(0); /* port power off */
- setbits_le32(ccm-ahb_gate0, 1 AHB_GATE_OFFSET_USB0);
-#ifdef CONFIG_SUNXI_GEN_SUN6I
- setbits_le32(ccm-ahb_reset0_cfg, 1 AHB_GATE_OFFSET_USB0);
-#endif
- sunxi_usb_phy_init(0);
- musb-is_active = 0;
- }
+ USBC_ForceVbusValidToLow(musb-mregs);
+ mdelay(200); /* Wait for the current session to timeout */
+
+ enabled = false;
}
static int sunxi_musb_init(struct musb *musb)
--
2.4.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [RFC 11/11] mtd/nand: Sunxi NAND boot partition definitions
Hi Michal, On Sun, 7 Jun 2015 18:48:26 +0200 Michal Suchanek hramr...@gmail.com wrote: Hello, On 5 June 2015 at 13:52, Roy Spliet r.spl...@ultimaker.com wrote: Based on the default layout of the android image used at least on Olimex Lime Signed-off-by: Roy Spliet r.spl...@ultimaker.com --- include/configs/sunxi-common.h | 9 + 1 file changed, 9 insertions(+) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index ec28c40..b38f2f5 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -404,8 +404,15 @@ extern int soft_i2c_gpio_scl; #define BOOT_TARGET_DEVICES_USB(func) #endif +#ifdef CONFIG_NAND +#define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand , 0) +#else +#define BOOT_TARGET_DEVICES_NAND(func) +#endif + #define BOOT_TARGET_DEVICES(func) \ BOOT_TARGET_DEVICES_MMC(func) \ + BOOT_TARGET_DEVICES_NAND(func) \ BOOT_TARGET_DEVICES_SCSI(func) \ BOOT_TARGET_DEVICES_USB(func) \ func(PXE, pxe, na) \ @@ -441,6 +448,8 @@ extern int soft_i2c_gpio_scl; MEM_LAYOUT_ENV_SETTINGS \ fdtfile= CONFIG_DEFAULT_DEVICE_TREE .dtb\0 \ console=ttyS0,115200\0 \ + mtdids=nand0=mtd2\0 \ + mtdparts=mtdparts=mtd2:0xffc0@0x40(nand0_main)\0 \ BOOTENV From what I heard the nand boot partition size should be specified in nand pages rather than bytes because the boot rom loads a fixed number of pages and just uses the start of each page regardless of page size. AFAIK, the mtdparts format only allows you to express partition offsets and sizes in bytes, and even if we had to change for something else, we should choose NAND blocks rather than NAND pages. The reason partitions should be block aligned in because the you can't erase specific pages in a block, which means that if you define 2 partitions sharing the same block, you won't be able to update one partition without potentially corrupting the other one. I did not find any document regarding the nand boot partition layout so I would like to see some input from somebody familiar with the driver. AFAIR, the mtd partition code checks for block alignment anyway, so you shouldn't be allowed to create two partitions sharing the same block. While it is fine for testing to hand-edit the environment the final nand support should have 1) way to express the boot partition size in nand pages Why should we add that ? The conversion from a number of blocks to a number bytes is pretty straightforward (number_of_blocks * block_size_in_bytes). 2) way to make the main partition start at the end of boot partition and extend to the end of the flash Again, that's not a good idea, the main partition should be aligned on a block (see the above explanation). Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 07/11] mtd/nand Add Sunxi NAND driver
On Fri, 5 Jun 2015 13:52:40 +0200 Roy Spliet r.spl...@ultimaker.com wrote: Heavily based on BBrezillon's (downstream) driver. Most noticable differences - No per-partition ECC settings. Partitions in U-boot are quite different from Linux - U-boot register definitions, shared with sunxi_nand_spl - FDT parsing in-line, there's no framework method yet I'll try to review this driver next week. -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 03/11] mtd/nand: support ONFI timing mode retrieval for non-ONFI
On Fri, 5 Jun 2015 13:52:36 +0200
Roy Spliet r.spl...@ultimaker.com wrote:
That one has been accepted, so I guess it will be taken by Scott during
his sync with the last mainline kernel.
From: yassin yassinjaf...@gmail.com
Signed-off-by: Roy Spliet r.spl...@ultimaker.com
---
drivers/mtd/nand/nand_base.c | 1 +
include/linux/mtd/nand.h | 7 +++
2 files changed, 8 insertions(+)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index c0e381a..dbeb092 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3709,6 +3709,7 @@ static bool find_full_id_nand(struct mtd_info *mtd,
struct nand_chip *chip,
chip-options |= type-options;
chip-ecc_strength_ds = NAND_ECC_STRENGTH(type);
chip-ecc_step_ds = NAND_ECC_STEP(type);
+ chip-onfi_timing_mode_ds = type-onfi_timing_mode_ds;
*busw = type-options NAND_BUSWIDTH_16;
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index abda5c3..0cdb3b9 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -634,6 +634,7 @@ struct nand_buffers {
* @ecc_step_ds: [INTERN] ECC step required by the @ecc_strength_ds,
* also from the datasheet. It is the recommended ECC
step
* size, if known; if unknown, set to zero.
+ * @onfi_timing_mode_ds:[INTERN] ONFI timing mode deduced from datasheet.
* @numchips:[INTERN] number of physical chips
* @chipsize:[INTERN] the size of one chip for multichip
arrays
* @pagemask:[INTERN] page number mask = number of (pages /
chip) - 1
@@ -718,6 +719,7 @@ struct nand_chip {
uint8_t bits_per_cell;
uint16_t ecc_strength_ds;
uint16_t ecc_step_ds;
+ int onfi_timing_mode_ds;
int badblockpos;
int badblockbits;
@@ -822,6 +824,10 @@ struct nand_chip {
* @ecc_step_ds in nand_chip{}, also from the datasheet.
* For example, the 4bit ECC for each 512Byte can be set with
* NAND_ECC_INFO(4, 512).
+ * @onfi_timing_mode_ds: the ONFI timing mode supported by this NAND chip.
This
+ * should be deduced from timings described in the
+ * datasheet.
+ *
*/
struct nand_flash_dev {
char *name;
@@ -842,6 +848,7 @@ struct nand_flash_dev {
uint16_t strength_ds;
uint16_t step_ds;
} ecc;
+ int onfi_timing_mode_ds;
};
/**
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MSI_Primo81_defconfig: enable USB OTG port and keyboard support
The MSI Primo 81 is an Allwinner A31s-based tablet on which the OTG port is the only accessible USB interface. The existing defconfig had VGA console on the LCD enabled, but was missing keyboard support because the prerequisites for that (sunxi MUSB support and AXP221 GPIO support) had not been available before. All previously missing dependencies are available now, so this patch enables keyboard support and its prerequisites in the defconfig. Signed-off-by: Karsten Merker mer...@debian.org --- configs/MSI_Primo81_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/configs/MSI_Primo81_defconfig b/configs/MSI_Primo81_defconfig index 83a95cb..8ae8c71 100644 --- a/configs/MSI_Primo81_defconfig +++ b/configs/MSI_Primo81_defconfig @@ -17,3 +17,9 @@ CONFIG_VIDEO_LCD_SPI_CS=PH9 CONFIG_VIDEO_LCD_SPI_SCLK=PH10 CONFIG_VIDEO_LCD_SPI_MOSI=PH11 CONFIG_VIDEO_LCD_SPI_MISO=PH12 +CONFIG_AXP_GPIO=y +CONFIG_DM_GPIO=y +CONFIG_USB0_VBUS_PIN=AXP0-VBUS-ENABLE +CONFIG_USB0_VBUS_DET=AXP0-VBUS-DETECT +CONFIG_USB_MUSB_SUNXI=y +CONFIG_USB_KEYBOARD=y -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 04/11] mtd/nand: add page status table (pst)
On Fri, 5 Jun 2015 13:52:37 +0200
Roy Spliet r.spl...@ultimaker.com wrote:
Ditto (this work hasn't been accepted in Linux).
From: yassin yassinjaf...@gmail.com
Signed-off-by: Roy Spliet r.spl...@ultimaker.com
---
drivers/mtd/nand/nand_base.c | 154
+++
include/linux/mtd/nand.h | 21 ++
2 files changed, 175 insertions(+)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index dbeb092..1c514a0 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -1185,6 +1185,138 @@ EXPORT_SYMBOL(nand_lock);
#endif
/**
+ * nand_page_is_empty - check wether a NAND page contains only FFs
+ * @mtd: mtd info
+ * @data:data buffer
+ * @oob: oob buffer
+ *
+ * Reads the data stored in the databuf buffer and check if it contains only
+ * FFs.
+ *
+ * Return true if it does else return false.
+ */
+bool nand_page_is_empty(struct mtd_info *mtd, void *data, void *oob)
+{
+ u8 *buf;
+ int length;
+ u32 pattern = 0x;
+ int bitflips = 0;
+ int cnt;
+
+ buf = data;
+ length = mtd-writesize;
+ while (length) {
+ cnt = length sizeof(pattern) ? length : sizeof(pattern);
+ if (memcmp(pattern, buf, cnt)) {
+ int i;
+ for (i = 0; i cnt * 8; i++) {
+ if (!(buf[i / 8]
+ (1 (i % 8 {
+ bitflips++;
+ if (bitflips mtd-ecc_strength)
+ return false;
+ }
+ }
+ }
+
+ buf += sizeof(pattern);
+ length -= sizeof(pattern);
+ }
+
+ buf = oob;
+ length = mtd-oobsize;
+ while (length) {
+ cnt = length sizeof(pattern) ? length : sizeof(pattern);
+ if (memcmp(pattern, buf, cnt)) {
+ int i;
+ for (i = 0; i cnt * 8; i++) {
+ if (!(buf[i / 8]
+ (1 (i % 8 {
+ bitflips++;
+ if (bitflips mtd-ecc_strength)
+ return false;
+ }
+ }
+ }
+
+ buf += sizeof(pattern);
+ length -= sizeof(pattern);
+ }
+
+ return true;
+}
+EXPORT_SYMBOL(nand_page_is_empty);
+
+/**
+ * nand_page_get_status - retrieve page status from the page status table
(pst)
+ * @mtd: mtd info
+ * @page:page you want to get status on
+ *
+ * Return the page status.
+ */
+int nand_page_get_status(struct mtd_info *mtd, int page)
+{
+ struct nand_chip *chip = mtd-priv;
+ u8 shift = (page % 4) * 2;
+ uint64_t offset = page / 4;
+ int ret = NAND_PAGE_STATUS_UNKNOWN;
+
+ if (chip-pst)
+ ret = (chip-pst[offset] shift) 0x3;
+
+ return ret;
+}
+EXPORT_SYMBOL(nand_page_get_status);
+
+/**
+ * nand_page_set_status - assign page status from in the page status table
+ * @mtd: mtd info
+ * @page:page you want to get status on
+ * @status: new status to assign
+ */
+void nand_page_set_status(struct mtd_info *mtd, int page,
+ enum nand_page_status status)
+{
+ struct nand_chip *chip = mtd-priv;
+ u8 shift;
+ uint64_t offset;
+
+ if (!chip-pst)
+ return;
+
+ shift = (page % 4) * 2;
+ offset = page / 4;
+ chip-pst[offset] = ~(0x3 shift);
+ chip-pst[offset] |= (status 0x3) shift;
+}
+EXPORT_SYMBOL(nand_page_set_status);
+
+/**
+ * nand_pst_create - create a page status table
+ * @mtd: mtd info
+ *
+ * Allocate a page status table and assign it to the mtd device.
+ *
+ * Returns 0 in case of success or -ERRNO in case of error.
+ */
+int nand_pst_create(struct mtd_info *mtd)
+{
+ struct nand_chip *chip = mtd-priv;
+
+ if (chip-pst)
+ return 0;
+
+ chip-pst = kzalloc(mtd-size
+ (chip-page_shift + mtd-subpage_sft + 2),
+ GFP_KERNEL);
+ if (!chip-pst)
+ return -ENOMEM;
+
+ return 0;
+}
+EXPORT_SYMBOL(nand_pst_create);
+
+/**
* nand_read_page_raw - [INTERN] read raw page data without ecc
* @mtd: mtd info structure
* @chip: nand chip info structure
@@ -2521,6 +2653,7 @@ static int nand_do_write_ops(struct mtd_info *mtd,
loff_t to,
int bytes = mtd-writesize;
int cached = writelen bytes page != blockmask;
uint8_t *wbuf = buf;
+ int subpage;
WATCHDOG_RESET();
/* Partial page write? */
@@ -2547,6 +2680,14 @@ static int
Re: [U-Boot] [RFC 05/11] mtd/nand: take nand_ecc_ctrl initialization out of nand_scan_tail
On Fri, 5 Jun 2015 13:52:38 +0200
Roy Spliet r.spl...@ultimaker.com wrote:
Ditto (work not mainlined yet, so we'd better either get rid of it).
BTW, a commit message would help understanding what you're doing in
this patch (even if I'm probably the one who omit the commit message in
the first place, that doesn't mean you should do the same ;-))
From: yassin yassinjaf...@gmail.com
Signed-off-by: Roy Spliet r.spl...@ultimaker.com
---
drivers/mtd/nand/nand_base.c | 101
++-
1 file changed, 61 insertions(+), 40 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 1c514a0..83586cc 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -4114,47 +4114,15 @@ int nand_scan_ident(struct mtd_info *mtd, int
maxchips,
}
EXPORT_SYMBOL(nand_scan_ident);
-
-/**
- * nand_scan_tail - [NAND Interface] Scan for the NAND device
- * @mtd: MTD device structure
- *
- * This is the second phase of the normal nand_scan() function. It fills out
- * all the uninitialized function pointers with the defaults and scans for a
- * bad block table if appropriate.
+/*
+ * Initialize ECC struct:
+ * - fill ECC struct with default function/values when these ones are
undefined
+ * - fill ECC infos based on MTD device
*/
-int nand_scan_tail(struct mtd_info *mtd)
+static int nand_ecc_ctrl_init(struct mtd_info *mtd, struct nand_ecc_ctrl
*ecc)
{
int i;
- struct nand_chip *chip = mtd-priv;
- struct nand_ecc_ctrl *ecc = chip-ecc;
- struct nand_buffers *nbuf;
- /* New bad blocks should be marked in OOB, flash-based BBT, or both */
- BUG_ON((chip-bbt_options NAND_BBT_NO_OOB_BBM)
- !(chip-bbt_options NAND_BBT_USE_FLASH));
-
- if (!(chip-options NAND_OWN_BUFFERS)) {
-#ifndef __UBOOT__
- nbuf = kzalloc(sizeof(*nbuf) + mtd-writesize
- + mtd-oobsize * 3, GFP_KERNEL);
- if (!nbuf)
- return -ENOMEM;
- nbuf-ecccalc = (uint8_t *)(nbuf + 1);
- nbuf-ecccode = nbuf-ecccalc + mtd-oobsize;
- nbuf-databuf = nbuf-ecccode + mtd-oobsize;
-#else
- nbuf = kzalloc(sizeof(struct nand_buffers), GFP_KERNEL);
-#endif
-
- chip-buffers = nbuf;
- } else {
- if (!chip-buffers)
- return -ENOMEM;
- }
-
- /* Set the internal oob buffer location, just after the page data */
- chip-oob_poi = chip-buffers-databuf + mtd-writesize;
/*
* If no default placement scheme is given, select an appropriate one.
@@ -4180,9 +4148,6 @@ int nand_scan_tail(struct mtd_info *mtd)
}
}
- if (!chip-write_page)
- chip-write_page = nand_write_page;
-
/*
* Check ECC mode, default to software if 3byte/512byte hardware ECC is
* selected and we have 256 byte pagesize fallback to software ECC
@@ -4349,6 +4314,62 @@ int nand_scan_tail(struct mtd_info *mtd)
}
ecc-total = ecc-steps * ecc-bytes;
+ return 0;
+}
+
+/**
+ * nand_scan_tail - [NAND Interface] Scan for the NAND device
+ * @mtd: MTD device structure
+ *
+ * This is the second phase of the normal nand_scan() function. It fills out
+ * all the uninitialized function pointers with the defaults and scans for a
+ * bad block table if appropriate.
+ */
+int nand_scan_tail(struct mtd_info *mtd)
+{
+ int ret;
+ struct nand_chip *chip = mtd-priv;
+ struct nand_ecc_ctrl *ecc = chip-ecc;
+ struct nand_buffers *nbuf;
+
+ /* New bad blocks should be marked in OOB, flash-based BBT, or both */
+ BUG_ON((chip-bbt_options NAND_BBT_NO_OOB_BBM)
+ !(chip-bbt_options NAND_BBT_USE_FLASH));
+
+ if (!(chip-options NAND_OWN_BUFFERS)) {
+#ifndef __UBOOT__
+ nbuf = kzalloc(sizeof(*nbuf) + mtd-writesize
+ + mtd-oobsize * 3, GFP_KERNEL);
+ if (!nbuf)
+ return -ENOMEM;
+ nbuf-ecccalc = (uint8_t *)(nbuf + 1);
+ nbuf-ecccode = nbuf-ecccalc + mtd-oobsize;
+ nbuf-databuf = nbuf-ecccode + mtd-oobsize;
+#else
+ nbuf = kzalloc(sizeof(struct nand_buffers), GFP_KERNEL);
+#endif
+
+ chip-buffers = nbuf;
+ } else {
+ if (!chip-buffers)
+ return -ENOMEM;
+ }
+
+ /* Set the internal oob buffer location, just after the page data */
+ chip-oob_poi = chip-buffers-databuf + mtd-writesize;
+
+ if (!chip-write_page)
+ chip-write_page = nand_write_page;
+
+ /* Initialize ECC struct */
+ ret = nand_ecc_ctrl_init(mtd, ecc);
+ if (ret) {
+ if (!(chip-options NAND_OWN_BUFFERS))
+ kfree(chip-buffers);
+
+ return ret;
+ }
+
[U-Boot] [PATCH] imx: imximage: add new CHECK/CLR BIT command
Since rom code supports the following commands, add new commands support in
imximage.
1. CHECK_BITS_SET 4 [address] [mask bit]
means:
while ((*address mask) != mask);
2. CHECK_BITS_CLR 4 [address] [mask bit]
means:
while ((*address ~mask) != 0);
2. CLR_BIT 4 [address] [mask bit]
means:
*address = *address ~mask;
dcd_v2_t is redefined, because there may not be only one write data command,
there may be many different commands like CHECK_BITS_SET, CHECK_BITS_CLR and
CLR_BIT.
dcd_len is still leaved there, since changing it needs changes for dcd v1.
For v2, we check whether dcd size is larger than MAX_DCD_SIZE_V2, but not
dcd_len.
Signed-off-by: Peng Fan peng@freescale.com
---
tools/imximage.c | 129 ++-
tools/imximage.h | 24 +--
2 files changed, 119 insertions(+), 34 deletions(-)
diff --git a/tools/imximage.c b/tools/imximage.c
index 6f469ae..1c0225d 100644
--- a/tools/imximage.c
+++ b/tools/imximage.c
@@ -22,6 +22,9 @@ static table_entry_t imximage_cmds[] = {
{CMD_BOOT_FROM, BOOT_FROM,boot command, },
{CMD_BOOT_OFFSET, BOOT_OFFSET, Boot offset,},
{CMD_DATA, DATA, Reg Write Data, },
+ {CMD_CLR_BIT, CLR_BIT, Reg clear bit, },
+ {CMD_CHECK_BITS_SET,CHECK_BITS_SET, Reg Check bits set, },
+ {CMD_CHECK_BITS_CLR,CHECK_BITS_CLR, Reg Check bits clr, },
{CMD_CSF, CSF, Command Sequence File, },
{CMD_IMAGE_VERSION, IMAGE_VERSION,image version, },
{-1,, , },
@@ -84,6 +87,7 @@ static set_imx_hdr_t set_imx_hdr;
static uint32_t max_dcd_entries;
static uint32_t *header_size_ptr;
static uint32_t *csf_ptr;
+static uint32_t dataindex;
static uint32_t get_cfg_value(char *token, char *name, int linenr)
{
@@ -129,7 +133,7 @@ static void err_imximage_version(int version)
}
static void set_dcd_val_v1(struct imx_header *imxhdr, char *name, int lineno,
- int fld, uint32_t value, uint32_t off)
+ int fld, int cmd, uint32_t value, uint32_t off)
{
dcd_v1_t *dcd_v1 = imxhdr-header.hdr_v1.dcd_table;
@@ -157,16 +161,47 @@ static void set_dcd_val_v1(struct imx_header *imxhdr,
char *name, int lineno,
}
static void set_dcd_val_v2(struct imx_header *imxhdr, char *name, int lineno,
- int fld, uint32_t value, uint32_t off)
+ int fld, int cmd, uint32_t value, uint32_t off)
{
dcd_v2_t *dcd_v2 = imxhdr-header.hdr_v2.dcd_table;
+ dcd_command_t *dcd_command_block = (dcd_command_t *)
+ dcd_v2-dcd_data[dataindex];
switch (fld) {
+ case CFG_COMMAND:
+ /* update header */
+ if (cmd == CMD_DATA) {
+ dcd_command_block-tag = DCD_WRITE_DATA_COMMAND_TAG;
+ dcd_command_block-length = cpu_to_be16(off *
+ sizeof(dcd_addr_data_t) + 4);
+ dcd_command_block-param = DCD_WRITE_DATA_PARAM;
+ } else if (cmd == CMD_CLR_BIT) {
+ dcd_command_block-tag = DCD_WRITE_DATA_COMMAND_TAG;
+ dcd_command_block-length = cpu_to_be16(off *
+ sizeof(dcd_addr_data_t) + 4);
+ dcd_command_block-param = DCD_CLR_BIT_PARAM;
+ } else if (cmd == CMD_CHECK_BITS_SET) {
+ dcd_command_block-tag = DCD_CHECK_DATA_COMMAND_TAG;
+ /*
+* check data command only supports one entry,
+* so use 0xC = size(address + value + command).
+*/
+ dcd_command_block-length = cpu_to_be16(0xC);
+ dcd_command_block-param = DCD_CHECK_BITS_SET_PARAM;
+ } else if (cmd == CMD_CHECK_BITS_CLR) {
+ dcd_command_block-tag = DCD_CHECK_DATA_COMMAND_TAG;
+ /*
+* check data command only supports one entry,
+* so use 0xC = size(address + value + command).
+*/
+ dcd_command_block-length = cpu_to_be16(0xC);
+ dcd_command_block-param = DCD_CHECK_BITS_CLR_PARAM;
+ }
case CFG_REG_ADDRESS:
- dcd_v2-addr_data[off].addr = cpu_to_be32(value);
+ dcd_command_block-addr_data[off].addr = cpu_to_be32(value);
break;
case CFG_REG_VALUE:
- dcd_v2-addr_data[off].value = cpu_to_be32(value);
+ dcd_command_block-addr_data[off].value = cpu_to_be32(value);
break;
Re: [U-Boot] [RFC] Sunxi NAND support for U-Boot
Hi All, I'm eventually joining the discussion (better late than never ;-)). You'll find my comments in each patch (or answers to those patches). On Fri, 5 Jun 2015 13:52:33 +0200 Roy Spliet r.spl...@ultimaker.com wrote: Following up on earlier SPL patches, here a series based on Yassin Jaffer's work to bring NAND support to U-boot. RFC because I know that the sunxi nand configuration options are dependent on a work-in-progress by Daniel - trying to deliver a single SPL for both MMC and NAND boot. Given I have spent the past few weeks learning how Boris' original driver works, I have probably grown a bit blind for potentially existing issues. Please provide plenty of feedback so I can bring this in good shape. Patches tested on an Olimex Lime with 4GB Hynix nand. Has a partition as defined in sunxi-common.h with two UBIFS partitions (boot, rootfs) set up in Linux. To me it feels self-explanatory how to set this up, but I've spent the last few weeks full-time on this, implying my view of the world and how it revolves around MTD is rather distorted. Feel free to ask directed questions if you desire assistance in setting up and/or testing. Thanks! That would be great to have a summary of the changelog in the cover letter (you can generate it with --cover-letter when you generate your patches using git format-patch). Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 08/11] mtd/nand: Add DT definitions for Olimex Lime
On Fri, 5 Jun 2015 13:52:41 +0200
Roy Spliet r.spl...@ultimaker.com wrote:
Signed-off-by: Roy Spliet r.spl...@ultimaker.com
---
arch/arm/dts/sun7i-a20-olinuxino-lime.dts | 41 ++
arch/arm/dts/sun7i-a20.dtsi | 90
+++
2 files changed, 131 insertions(+)
diff --git a/arch/arm/dts/sun7i-a20-olinuxino-lime.dts
b/arch/arm/dts/sun7i-a20-olinuxino-lime.dts
index 6592cb2..cc5e65d 100644
--- a/arch/arm/dts/sun7i-a20-olinuxino-lime.dts
+++ b/arch/arm/dts/sun7i-a20-olinuxino-lime.dts
@@ -181,3 +181,44 @@
usb2_vbus-supply = reg_usb2_vbus;
status = okay;
};
+
+nfc {
+ pinctrl-names = default;
+ pinctrl-0 = nand_pins_a nand_cs0_pins_a nand_rb0_pins_a;
+ status = okay;
+
+ nand@0 {
+ #address-cells = 2;
+ #size-cells = 2;
+ reg = 0;
+ allwinner,rb = 0;
+ nand-ecc-mode = hw;
+ nand-ecc-strength = 40;
+ nand-ecc-step-size = 1024;
+ nand-rnd-mode = hw;
+ nand-randomizer-seeds = /bits/ 16
+ 0x2b75 0x0bd0 0x5ca3 0x62d1 0x1c93 0x07e9 0x2162 0x3a72
+ 0x0d67 0x67f9 0x1be7 0x077d 0x032f 0x0dac 0x2716 0x2436
+ 0x7922 0x1510 0x3860 0x5287 0x480f 0x4252 0x1789 0x5a2d
+ 0x2a49 0x5e10 0x437f 0x4b4e 0x2f45 0x216e 0x5cb7 0x7130
+ 0x2a3f 0x60e4 0x4dc9 0x0ef0 0x0f52 0x1bb9 0x6211 0x7a56
+ 0x226d 0x4ea7 0x6f36 0x3692 0x38bf 0x0c62 0x05eb 0x4c55
+ 0x60f4 0x728c 0x3b6f 0x2037 0x7f69 0x0936 0x651a 0x4ceb
+ 0x6218 0x79f3 0x383f 0x18d9 0x4f05 0x5c82 0x2912 0x6f17
+ 0x6856 0x5938 0x1007 0x61ab 0x3e7f 0x57c2 0x542f 0x4f62
+ 0x7454 0x2eac 0x7739 0x42d4 0x2f90 0x435a 0x2e52 0x2064
+ 0x637c 0x66ad 0x2c90 0x0bad 0x759c 0x0029 0x0986 0x7126
+ 0x1ca7 0x1605 0x386a 0x27f5 0x1380 0x6d75 0x24c3 0x0f8e
+ 0x2b7a 0x1418 0x1fd1 0x7dc1 0x2d8e 0x43af 0x2267 0x7da3
+ 0x4e3d 0x1338 0x50db 0x454d 0x764d 0x40a3 0x42e6 0x262b
+ 0x2d2e 0x1aea 0x2e17 0x173d 0x3a6e 0x71bf 0x25f9 0x0a5d
+ 0x7c57 0x0fbe 0x46ce 0x4939 0x6b17 0x37bb 0x3e91
0x76db;
+ onfi,nand-timing-mode = 0x1f;
Can we use the same binding we have in mainline Linux (not my branch).
In mainline, the onfi,nand-timing-mode has been dropped in favor of
ONFI timing mode definition in the nand_ids table.
ECC strength and step size should also be extracted from the nand_ids
table, unless you want to force something different (which doesn't seem
to be the case here).
Moreover, the randomizer stuff haven't been reviewed/accepted yet.
To support the randomizer stuff in the meantime, you could define the
randomizer-seeds table in the board config header and use sunxi
specific commands to select the randomizer mode and randomizer seeds
table (if you have several tables).
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 06/11] mtd/nand: Add randomisation layer
On Fri, 5 Jun 2015 13:52:39 +0200 Roy Spliet r.spl...@ultimaker.com wrote: Based on BBrezillons work, minus per-partition support. Changes to support that would be quite invasive while it hasn't been solved yet for Linux. Same comment as in other patches: this work hasn't been accepted yet in mainline Linux, so maybe we should keep this code in the sunxi-nand driver until it is merged in Linux. -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] sunxi: musb: Remove unused sunxi_musb_exit method
On Sun, 2015-06-14 at 12:40 +0200, Hans de Goede wrote: Remove the unused sunxi_musb_exit method, there is no code in u-boot calling the exit method, and our implementation was broken as it did not disable the clocks and asserted reset. Seems to me the call should either be called (and the hooks fixed) or removed from the core but so far as sunxi goes: Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [RFC 11/11] mtd/nand: Sunxi NAND boot partition definitions
On Sun, 14 Jun 2015 13:56:56 +0200 Michal Suchanek hramr...@gmail.com wrote: On 14 June 2015 at 13:25, Boris Brezillon boris.brezil...@free-electrons.com wrote: Hi Michal, On Sun, 7 Jun 2015 18:48:26 +0200 Michal Suchanek hramr...@gmail.com wrote: Hello, On 5 June 2015 at 13:52, Roy Spliet r.spl...@ultimaker.com wrote: Based on the default layout of the android image used at least on Olimex Lime Signed-off-by: Roy Spliet r.spl...@ultimaker.com --- include/configs/sunxi-common.h | 9 + 1 file changed, 9 insertions(+) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index ec28c40..b38f2f5 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -404,8 +404,15 @@ extern int soft_i2c_gpio_scl; #define BOOT_TARGET_DEVICES_USB(func) #endif +#ifdef CONFIG_NAND +#define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand , 0) +#else +#define BOOT_TARGET_DEVICES_NAND(func) +#endif + #define BOOT_TARGET_DEVICES(func) \ BOOT_TARGET_DEVICES_MMC(func) \ + BOOT_TARGET_DEVICES_NAND(func) \ BOOT_TARGET_DEVICES_SCSI(func) \ BOOT_TARGET_DEVICES_USB(func) \ func(PXE, pxe, na) \ @@ -441,6 +448,8 @@ extern int soft_i2c_gpio_scl; MEM_LAYOUT_ENV_SETTINGS \ fdtfile= CONFIG_DEFAULT_DEVICE_TREE .dtb\0 \ console=ttyS0,115200\0 \ + mtdids=nand0=mtd2\0 \ + mtdparts=mtdparts=mtd2:0xffc0@0x40(nand0_main)\0 \ BOOTENV From what I heard the nand boot partition size should be specified in nand pages rather than bytes because the boot rom loads a fixed number of pages and just uses the start of each page regardless of page size. AFAIK, the mtdparts format only allows you to express partition offsets and sizes in bytes, and even if we had to change for something else, we should choose NAND blocks rather than NAND pages. The reason partitions should be block aligned in because the you can't erase specific pages in a block, which means that if you define 2 partitions sharing the same block, you won't be able to update one partition without potentially corrupting the other one. However, if the number of pages the boot0 partition takes up is not block aligned it means we cannot use the medium for booting and can just use 1 big partition anyway. Hm, I don't get your point. You can have a boot0 partition taking one NAND block, and several other partitions used for other purpose (though having a single UBI partition is a better approach). I did not find any document regarding the nand boot partition layout so I would like to see some input from somebody familiar with the driver. AFAIR, the mtd partition code checks for block alignment anyway, so you shouldn't be allowed to create two partitions sharing the same block. While it is fine for testing to hand-edit the environment the final nand support should have 1) way to express the boot partition size in nand pages Why should we add that ? The conversion from a number of blocks to a number bytes is pretty straightforward (number_of_blocks * block_size_in_bytes). Because the block size is not the same on all flash chips, obviously. And that's why partitions are defined in the board dts, and not the SoC dtsi... If there is only one block size that can ever be reasonably supported due to other constraints then it's fine to just hardcode it. I think we already had this discussion on the #linux-sunxi channel, and you're trying to use a generic config from things that are really board specific. What's the problem with having different partition layout depending on the board ? Note that once you have defined your boot0 + u-boot + u-boot-env + UBI partitions, if you want to have a generic layout in the UBI device, you can define standard names for you UBI volumes. 2) way to make the main partition start at the end of boot partition and extend to the end of the flash Again, that's not a good idea, the main partition should be aligned on a block (see the above explanation). Since these are block aligned anyway there should be no problem. And if you can express the size in blocks you can just make the main partition start the next block after boot0. What is missing is the ability to extend to the end of medium to be feature compatible with Chinese software that uses this to flash same firmware to tablets with different nand size. I think this is generally desirable anyway. If they decide to use one single dtb for all their board revisions (even when they decide to change the NAND chip type), then yes, they should define a boot0 partition taking at least the size of the maximum block size. But that's only my opinion, so if MTD maintainers (both u-boot and linux ones) accept to support MTD partition offsets and sizes defined in
Re: [U-Boot] [linux-sunxi] [RFC 11/11] mtd/nand: Sunxi NAND boot partition definitions
Roy, Yassin, On Mon, 08 Jun 2015 13:35:04 +0200 Roy Spliet r.spl...@ultimaker.com wrote: Hello Yassin, Op 08-06-15 om 12:48 schreef Yassin: Hi Roy Thank you for working on this, I would like to suggest if you could implement separate control commands to switch ECC and Randomisation modes per partitions. I know this is not the best approach but it will provide more controls. Thanks for the suggestion. However, for now I do not see the immediate need for this in U-boot. U-boot should really only care about one thing: load Linux. Therefore, the only partition it needs to be able to read is whatever partition is used for storing boot data on. And if we only care about one NAND partition, we don't need per-partition settings. I agree that it would be nice to have eventually, but I think this problem first needs to be solved in Linux properly. Then in U-boot we can sync MTD up with Linux and we get the support we need for free. I'd personally recommend to take this approach over now first hacking up all sorts of new commands in U-boot, as the latter will create more problems with syncing up MTD and doing the right thing on the longer run. Actually, the more I think about the more I agree with Yassin's suggestion. We currently don't have any standard way to attach a specific setting to a partition (even in Linux, and I hope I'll be able to work on this aspect soon). So for now, I really think we should reuse the existing/standard way of declaring partitions in u-boot (mtdparts + mtdids variables + the mtdparts command) and a sunxi specific commands to configure the ECC and Randomizer config. Once we have settled on something in Linux, we will be able to port it to u-boot and get rid of these sunxi specific command, but in the meantime this will allow us to boot a linux kernel (and even flash an SPL) from u-boot without introducing heavy changes in the u-boot MTD layer. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] sunxi: musb: Do not fully reset the controler from sunxi_musb_disable
On Sun, 2015-06-14 at 12:40 +0200, Hans de Goede wrote: Fully resetting the controller is a too big hammer, and the musb_core will then afterwards fail to communicate with any endpoints other then 0 as too much state was cleared. Instead report vbus low for 200ms which will effectively end the current session without needing to do a full reset. This fixes usb mass-storage devices no longer working after a usb reset Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk One question (which turned into two) (both more for the musb maint than you): +/* musb_core does not call enable / disable in a balanced manner sigh */ +static bool enabled = false; Is this sufficient, or should we be reference counting? Or should the core be fixed? Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 07/11] mtd/nand Add Sunxi NAND driver
On Sun, 14 Jun 2015 13:42:12 +0200 Boris Brezillon boris.brezil...@free-electrons.com wrote: On Fri, 5 Jun 2015 13:52:40 +0200 Roy Spliet r.spl...@ultimaker.com wrote: Heavily based on BBrezillon's (downstream) driver. Most noticable differences - No per-partition ECC settings. Partitions in U-boot are quite different from Linux - U-boot register definitions, shared with sunxi_nand_spl - FDT parsing in-line, there's no framework method yet I'll try to review this driver next week. BTW, I don't know if you've based you work on Yassin's work, but if that's the case, then you should at least mention it in the license header, and maybe you should consider adding a S-o-B line with his name. -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [RFC 11/11] mtd/nand: Sunxi NAND boot partition definitions
On 14 June 2015 at 13:25, Boris Brezillon boris.brezil...@free-electrons.com wrote: Hi Michal, On Sun, 7 Jun 2015 18:48:26 +0200 Michal Suchanek hramr...@gmail.com wrote: Hello, On 5 June 2015 at 13:52, Roy Spliet r.spl...@ultimaker.com wrote: Based on the default layout of the android image used at least on Olimex Lime Signed-off-by: Roy Spliet r.spl...@ultimaker.com --- include/configs/sunxi-common.h | 9 + 1 file changed, 9 insertions(+) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index ec28c40..b38f2f5 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -404,8 +404,15 @@ extern int soft_i2c_gpio_scl; #define BOOT_TARGET_DEVICES_USB(func) #endif +#ifdef CONFIG_NAND +#define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand , 0) +#else +#define BOOT_TARGET_DEVICES_NAND(func) +#endif + #define BOOT_TARGET_DEVICES(func) \ BOOT_TARGET_DEVICES_MMC(func) \ + BOOT_TARGET_DEVICES_NAND(func) \ BOOT_TARGET_DEVICES_SCSI(func) \ BOOT_TARGET_DEVICES_USB(func) \ func(PXE, pxe, na) \ @@ -441,6 +448,8 @@ extern int soft_i2c_gpio_scl; MEM_LAYOUT_ENV_SETTINGS \ fdtfile= CONFIG_DEFAULT_DEVICE_TREE .dtb\0 \ console=ttyS0,115200\0 \ + mtdids=nand0=mtd2\0 \ + mtdparts=mtdparts=mtd2:0xffc0@0x40(nand0_main)\0 \ BOOTENV From what I heard the nand boot partition size should be specified in nand pages rather than bytes because the boot rom loads a fixed number of pages and just uses the start of each page regardless of page size. AFAIK, the mtdparts format only allows you to express partition offsets and sizes in bytes, and even if we had to change for something else, we should choose NAND blocks rather than NAND pages. The reason partitions should be block aligned in because the you can't erase specific pages in a block, which means that if you define 2 partitions sharing the same block, you won't be able to update one partition without potentially corrupting the other one. However, if the number of pages the boot0 partition takes up is not block aligned it means we cannot use the medium for booting and can just use 1 big partition anyway. I did not find any document regarding the nand boot partition layout so I would like to see some input from somebody familiar with the driver. AFAIR, the mtd partition code checks for block alignment anyway, so you shouldn't be allowed to create two partitions sharing the same block. While it is fine for testing to hand-edit the environment the final nand support should have 1) way to express the boot partition size in nand pages Why should we add that ? The conversion from a number of blocks to a number bytes is pretty straightforward (number_of_blocks * block_size_in_bytes). Because the block size is not the same on all flash chips, obviously. If there is only one block size that can ever be reasonably supported due to other constraints then it's fine to just hardcode it. 2) way to make the main partition start at the end of boot partition and extend to the end of the flash Again, that's not a good idea, the main partition should be aligned on a block (see the above explanation). Since these are block aligned anyway there should be no problem. And if you can express the size in blocks you can just make the main partition start the next block after boot0. What is missing is the ability to extend to the end of medium to be feature compatible with Chinese software that uses this to flash same firmware to tablets with different nand size. I think this is generally desirable anyway. Thanks Michal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] Re: [RFC 02/11] mtd/nand: add ONFI timing mode to nand_timings converter
On Mon, 08 Jun 2015 10:41:28 +0200 Roy Spliet r.spl...@ultimaker.com wrote: Hello Michal, Op 08-06-15 om 10:34 schreef Michal Suchanek: On 8 June 2015 at 10:11, Roy Spliet r.spl...@ultimaker.com wrote: Hello Scott et al., Op 06-06-15 om 00:02 schreef Scott Wood: On Fri, 2015-06-05 at 13:52 +0200, Roy Spliet wrote: From: yassin yassinjaf...@gmail.com Signed-off-by: Roy Spliet r.spl...@ultimaker.com --- drivers/mtd/nand/Makefile | 2 +- drivers/mtd/nand/nand_timings.c | 252 include/linux/mtd/nand.h| 3 + 3 files changed, 256 insertions(+), 1 deletion(-) create mode 100644 drivers/mtd/nand/nand_timings.c This code comes from Linux and yet I see no acknowledgement of that, much less a statement of which version of Linux this was pulled from. Correct, my apologies as I should have clarified that work by Boris Brezillon does not mean upsteam work. The code comes from Boris' github tree[1] and contains work that was not yet brought upstream, yet is required for NAND on sunxi to work. It would probably be better to handle this as part of a general sync with the Linux mtd code. Ideally yes, but. In upstream Linux MTD we have a few issues to address as shown by Boris' patch-set, most importantly: - NAND chip timings (patch 1 to 3) - Randomisation support (patch 6) - Per-partition settings for ECC and randomisation (left out of my RFC, highly desirable but not strictly required for U-boot booting) Hello, as I understand it the ECC and randomisation settings for the bootloader part of the nand are suboptimal or unusable for ubifs so if u-boot SPL is to read the u-boot binary and later u-boot the kernel from an ubifs volume it has to support non-uniform settings. Alternatively the bootloader part can be extended to contain partitions for u-boot binary and kernel image written to raw partition without filesystem much like what Andriod usually does. SPL does not read U-boot from UBI. The SPL driver is separate, much smaller and only reads in the same way BROM does. U-boot itself is not bound by the limitations imposed by BROM, which means proper randomisation and ECC settings can be used for the UBI partition. Yep, I agree with Roy here: we shouldn't use the BROM config except for the SPL partition. Defining the same randomizer seed for all the pages in a given block is pretty much useless since it won't prevent the reproducible pattern issue, which is one of the cause of excessive bitblits in MLC NANDs. The same goes for the ECC config used by the BROM, because in some cases it might prevent using the whole page (ECC config is stronger than required, and thus ECC bytes take more than what's available in the OOB area). -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] sun6i: cpu_reset: Do not return from cpu_reset()
Currently on sun6i after a reset the prompt returns and the user can
even type stuff until the watchdog triggers and does the actual reset.
This is somewhat unexpected behavior for the reset command, this
commit adds an endless loop to wait for the watchdog to trigger so that
we do not return to the prompt.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/cpu/armv7/sunxi/board.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arch/arm/cpu/armv7/sunxi/board.c
index bd0d819..0fe641f 100644
--- a/arch/arm/cpu/armv7/sunxi/board.c
+++ b/arch/arm/cpu/armv7/sunxi/board.c
@@ -220,6 +220,7 @@ void reset_cpu(ulong addr)
writel(WDT_CFG_RESET, wdog-cfg);
writel(WDT_MODE_EN, wdog-mode);
writel(WDT_CTRL_KEY | WDT_CTRL_RESTART, wdog-ctl);
+ while (1) { }
#endif
}
--
2.3.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-marvell master
Hi Tom, this series contains patches from Kevin and Stefan and it would be great if you could pull them in this release. The following changes since commit 64d16706a052553c85d2f8f4c741879a4e3e6116: Nokia RX-51: Fix calculating return address in save_boot_params (2015-06-12 08:11:18 -0400) are available in the git repository at: git://git.denx.de/u-boot-marvell.git for you to fetch changes up to 1c0df9ef6ed03baf6fd325dac546290f80c7fd09: tools/kwboot: Add parameters to set delay and timeout via cmdline (2015-06-14 17:48:28 +0200) Kevin Smith (2): tools/kwbimage.c: Correct header size for SPI boot arm: mvebu: Update CBAR with SOC regs base Stefan Roese (2): arm: mvebu: Disable L2 cache before enabling d-cache tools/kwboot: Add parameters to set delay and timeout via cmdline arch/arm/mach-mvebu/cpu.c | 15 +++ tools/kwbimage.c | 22 -- tools/kwboot.c| 14 -- 3 files changed, 39 insertions(+), 12 deletions(-) Regards, Luka ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sun6i: cpu_reset: Do not return from cpu_reset()
On Sun, 2015-06-14 at 16:58 +0200, Hans de Goede wrote:
Currently on sun6i after a reset the prompt returns and the user can
even type stuff until the watchdog triggers and does the actual reset.
This is somewhat unexpected behavior for the reset command,
It certainly is!
this
commit adds an endless loop to wait for the watchdog to trigger so that
we do not return to the prompt.
Signed-off-by: Hans de Goede hdego...@redhat.com
Acked-by: Ian Campbell i...@hellion.org.uk
Might be worth throwing a cpu_relax or some such in there too?
---
arch/arm/cpu/armv7/sunxi/board.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/cpu/armv7/sunxi/board.c
b/arch/arm/cpu/armv7/sunxi/board.c
index bd0d819..0fe641f 100644
--- a/arch/arm/cpu/armv7/sunxi/board.c
+++ b/arch/arm/cpu/armv7/sunxi/board.c
@@ -220,6 +220,7 @@ void reset_cpu(ulong addr)
writel(WDT_CFG_RESET, wdog-cfg);
writel(WDT_MODE_EN, wdog-mode);
writel(WDT_CTRL_KEY | WDT_CTRL_RESTART, wdog-ctl);
+ while (1) { }
#endif
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] sunxi: musb: Do not fully reset the controler from sunxi_musb_disable
Hi, On 06/14/2015 01:46 PM, Ian Campbell wrote: On Sun, 2015-06-14 at 12:40 +0200, Hans de Goede wrote: Fully resetting the controller is a too big hammer, and the musb_core will then afterwards fail to communicate with any endpoints other then 0 as too much state was cleared. Instead report vbus low for 200ms which will effectively end the current session without needing to do a full reset. This fixes usb mass-storage devices no longer working after a usb reset Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk One question (which turned into two) (both more for the musb maint than you): +/* musb_core does not call enable / disable in a balanced manner sigh */ +static bool enabled = false; Is this sufficient, or should we be reference counting? Or should the core be fixed? The u-boot musb-new code is a copy of the kernel code, and both are of, ah, interesting quality. One problem is that the core calls musb_platform_disable as part of musb_init_controller and thus before musb_platform_enable is ever called. Ideally the core would not do this, but in u-boot it is used on 4 different SoCs and in the kernel even more, and chances are that that call was added to put the hw in a clean state on some SoC... Basically my approach for these kind of problems in the musb core so far has been to work around them were possible, so as to not cause any regressions on other SoCs. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [RFC 11/11] mtd/nand: Sunxi NAND boot partition definitions
On 14 June 2015 at 14:18, Boris Brezillon boris.brezil...@free-electrons.com wrote: On Sun, 14 Jun 2015 13:56:56 +0200 Michal Suchanek hramr...@gmail.com wrote: On 14 June 2015 at 13:25, Boris Brezillon boris.brezil...@free-electrons.com wrote: Hi Michal, On Sun, 7 Jun 2015 18:48:26 +0200 Michal Suchanek hramr...@gmail.com wrote: Hello, On 5 June 2015 at 13:52, Roy Spliet r.spl...@ultimaker.com wrote: Based on the default layout of the android image used at least on Olimex Lime Signed-off-by: Roy Spliet r.spl...@ultimaker.com --- include/configs/sunxi-common.h | 9 + 1 file changed, 9 insertions(+) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index ec28c40..b38f2f5 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -404,8 +404,15 @@ extern int soft_i2c_gpio_scl; #define BOOT_TARGET_DEVICES_USB(func) #endif +#ifdef CONFIG_NAND +#define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand , 0) +#else +#define BOOT_TARGET_DEVICES_NAND(func) +#endif + #define BOOT_TARGET_DEVICES(func) \ BOOT_TARGET_DEVICES_MMC(func) \ + BOOT_TARGET_DEVICES_NAND(func) \ BOOT_TARGET_DEVICES_SCSI(func) \ BOOT_TARGET_DEVICES_USB(func) \ func(PXE, pxe, na) \ @@ -441,6 +448,8 @@ extern int soft_i2c_gpio_scl; MEM_LAYOUT_ENV_SETTINGS \ fdtfile= CONFIG_DEFAULT_DEVICE_TREE .dtb\0 \ console=ttyS0,115200\0 \ + mtdids=nand0=mtd2\0 \ + mtdparts=mtdparts=mtd2:0xffc0@0x40(nand0_main)\0 \ BOOTENV From what I heard the nand boot partition size should be specified in nand pages rather than bytes because the boot rom loads a fixed number of pages and just uses the start of each page regardless of page size. AFAIK, the mtdparts format only allows you to express partition offsets and sizes in bytes, and even if we had to change for something else, we should choose NAND blocks rather than NAND pages. The reason partitions should be block aligned in because the you can't erase specific pages in a block, which means that if you define 2 partitions sharing the same block, you won't be able to update one partition without potentially corrupting the other one. However, if the number of pages the boot0 partition takes up is not block aligned it means we cannot use the medium for booting and can just use 1 big partition anyway. Hm, I don't get your point. You can have a boot0 partition taking one NAND block, and several other partitions used for other purpose (though having a single UBI partition is a better approach). and how do you tell the kernel that these partitions follow the boot0 taking up one block when you only count in bytes? I did not find any document regarding the nand boot partition layout so I would like to see some input from somebody familiar with the driver. AFAIR, the mtd partition code checks for block alignment anyway, so you shouldn't be allowed to create two partitions sharing the same block. While it is fine for testing to hand-edit the environment the final nand support should have 1) way to express the boot partition size in nand pages Why should we add that ? The conversion from a number of blocks to a number bytes is pretty straightforward (number_of_blocks * block_size_in_bytes). Because the block size is not the same on all flash chips, obviously. And that's why partitions are defined in the board dts, and not the SoC dtsi... If there is only one block size that can ever be reasonably supported due to other constraints then it's fine to just hardcode it. I think we already had this discussion on the #linux-sunxi channel, and you're trying to use a generic config from things that are really board specific. What's the problem with having different partition layout depending on the board ? Why do we have nand chip detection then? We can just write the chip parameters in DT and have everything in one place at least. If we cannot use the detected parameters to infer the related values in DT then the detection is useless for DT based archs. Thanks Michal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] d.bfd: error: /.../libgcc.a(_udivdi3.o) uses VFP register arguments, u-boot does not
I just cloned the repo (top commit: 64d16706a052553c85d2f8f4c741879a4e3e6116) and run on a bananapi (armv7): # make Bananapi_defconfig # make The second command fails with errors like: ld.bfd: error: /usr/lib/gcc/armv7l-unknown-linux-gnueabihf/4.9.2/libgcc.a(_udivdi3.o) uses VFP register arguments, u-boot does not Any suggestion? Thanks a lot Fabio -- View this message in context: http://u-boot.10912.n7.nabble.com/d-bfd-error-libgcc-a-udivdi3-o-uses-VFP-register-arguments-u-boot-does-not-tp217065.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Reproducible-builds] [PATCH] build: create time and date independent binary
Hi Paul, thanks for contacting us! On Freitag, 12. Juni 2015, Paul Kocialkowski wrote: I think a bit more is needed to get truly reproducible builds in U-Boot, but this is a first good step! you've seen https://reproducible.debian.net/u-boot ? I have been thinking about bringing reproducible builds to U-Boot for a little while, but never got around actually doing it. Are you interested in helping me on that? I have some free time these days, so I could do some work on this. cool! It would certainly be relevant to get in touch with the people working on reproducing builds for Debian (I know Lunar is involved with this), since Debian packages U-Boot for many devices and they're apparently willing to help upstream with automated tests, as they're doing with coreboot and OpenWRT! we're definitly happy to help! that said, I'm not sure I want to treat uboot like openwrt or coreboot, simply because uboot is packaged for several distributions, so (in my maybe naive assumptions) it should be tested within those distros. coreboot is really exceptional here, as it doesn't make much sense to package it as part of a distro. (though this could also change, at least sources could be shipped...) but maybe you can explain why u-boot needs more reproducibility testing than what there currently is. i'm definitly interested and not opposed, even though I think there shoukd be good reasons to treat some software specially. (also please note that we currently only have amd64 hw to run our tests on.) In a similar way I have for now decided that I'm not interested in adding tests of libreboot, as it's basically just a fork of coreboot, so the reproducibility issues should be the same. OTOH libreboot releases images (which coreboot doesnt do) so that might become interesting to validate. But there I think that the validation should be done as part of that project (=libreboot), and not as part of reproducible.debian.net, which I mostly see as a.) effort to test and push Debians reproducibility effort and b.) show that this is possible for other distros too - but I think in long term that should move to a setup located+maintained at those other distros. (because we lack the *human*power to look after too/so many things...) (And really, testing on reproducible.debian.net is not enough, it's just the first step: now we know that coreboot is 100% reproducible, now what? This what needs to happen on the coreboot side...) So it's not (so much or maybe at all) a question of hardware ressources, which we can scale up rather easily, but mostly human ressources maintaining the hw+sw *and* translating this into meaningful action for the project tested. All this said, if you send me patches, I will probably deploy them as I'm very curious and more reproducibility efforts are good :-) We can can always decide to remove or move them later. cheers, Holger signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,7/8] ARM: highbank: remove DRAM bank setup
On Fri, 12 Jun 2015 22:10:07 -0400 Tom Rini tr...@konsulko.com wrote: On Fri, Jun 05, 2015 at 12:58:48AM +0100, Andre Przywara wrote: From: Rob Herring r...@kernel.org On the highbank platform the SoC's management controller firmware will probe the DRAM modules and populates the initial device tree with the correct values. Therefore the memory sizes in are already correct, so remove U-Boot's DRAM bank setup so the memory node is not fixed up by u-boot. Signed-off-by: Rob Herring r...@kernel.org Signed-off-by: Andre Przywara o...@andrep.de Applied to u-boot/master, thanks! Hi Tom, thanks for applying the patches! I sent out a reworked version of patch 6/8, which saw a comment from Simon. Please consider applying the new one _or_ revert this very patch here (7/8), as it alone breaks Calxeda machines (which now end up with an empty memory/reg property instead of an untouched one). Sorry for the mess! Cheers, Andre. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] spi: fsl_espi.c: fix checkpatch.pl erorrs/warnings
This patch clears the errors found by running checkpatch.pl on file
drivers/spi/fsl_espi.c
Signed-off-by: Chakra Divi cd...@openedev.com
---
drivers/spi/fsl_espi.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/spi/fsl_espi.c b/drivers/spi/fsl_espi.c
index 375dc07..9d9a6e0 100644
--- a/drivers/spi/fsl_espi.c
+++ b/drivers/spi/fsl_espi.c
@@ -92,11 +92,12 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
unsigned int cs,
pm = spibrg / (max_hz * 16 * 2);
if (pm 16) {
pm = 16;
- debug(Requested speed is too low: %d Hz, %ld Hz
- is used.\n, max_hz, spibrg / (32 * 16));
+ debug(Requested speed is too low: %d Hz, %ld Hz
+ is used.\n, max_hz, spibrg / (32 * 16));
}
- } else
+ } else {
pm = spibrg / (max_hz * 2);
+ }
if (pm)
pm--;
fsl-pm = pm;
@@ -121,7 +122,7 @@ void spi_free_slave(struct spi_slave *slave)
void spi_init(void)
{
-
+ ; /* Do nothing */
}
int spi_claim_bus(struct spi_slave *slave)
@@ -177,7 +178,7 @@ int spi_claim_bus(struct spi_slave *slave)
void spi_release_bus(struct spi_slave *slave)
{
-
+ ; /* Do nothing */
}
static void fsl_espi_tx(struct fsl_spi_slave *fsl, const void *dout)
@@ -264,7 +265,8 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
const void *data_out,
max_tran_len = fsl-max_transfer_length;
switch (flags) {
case SPI_XFER_BEGIN:
- cmd_len = fsl-cmd_len = data_len;
+ fsl-cmd_len = data_len;
+ cmd_len = fsl-cmd_len;
memcpy(cmd_buf, data_out, cmd_len);
return 0;
case 0:
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] This patch clears the errors found my running checkpatch.pl on file drivers/spi/fsl_espi.c
Signed-off-by: Chakra Divi cd...@openedev.com
---
drivers/spi/fsl_espi.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/spi/fsl_espi.c b/drivers/spi/fsl_espi.c
index 375dc07..9d9a6e0 100644
--- a/drivers/spi/fsl_espi.c
+++ b/drivers/spi/fsl_espi.c
@@ -92,11 +92,12 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
unsigned int cs,
pm = spibrg / (max_hz * 16 * 2);
if (pm 16) {
pm = 16;
- debug(Requested speed is too low: %d Hz, %ld Hz
- is used.\n, max_hz, spibrg / (32 * 16));
+ debug(Requested speed is too low: %d Hz, %ld Hz
+ is used.\n, max_hz, spibrg / (32 * 16));
}
- } else
+ } else {
pm = spibrg / (max_hz * 2);
+ }
if (pm)
pm--;
fsl-pm = pm;
@@ -121,7 +122,7 @@ void spi_free_slave(struct spi_slave *slave)
void spi_init(void)
{
-
+ ; /* Do nothing */
}
int spi_claim_bus(struct spi_slave *slave)
@@ -177,7 +178,7 @@ int spi_claim_bus(struct spi_slave *slave)
void spi_release_bus(struct spi_slave *slave)
{
-
+ ; /* Do nothing */
}
static void fsl_espi_tx(struct fsl_spi_slave *fsl, const void *dout)
@@ -264,7 +265,8 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
const void *data_out,
max_tran_len = fsl-max_transfer_length;
switch (flags) {
case SPI_XFER_BEGIN:
- cmd_len = fsl-cmd_len = data_len;
+ fsl-cmd_len = data_len;
+ cmd_len = fsl-cmd_len;
memcpy(cmd_buf, data_out, cmd_len);
return 0;
case 0:
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [RFC 11/11] mtd/nand: Sunxi NAND boot partition definitions
On Sun, 14 Jun 2015 19:42:58 +0200 Michal Suchanek hramr...@gmail.com wrote: On 14 June 2015 at 14:18, Boris Brezillon boris.brezil...@free-electrons.com wrote: On Sun, 14 Jun 2015 13:56:56 +0200 Michal Suchanek hramr...@gmail.com wrote: On 14 June 2015 at 13:25, Boris Brezillon boris.brezil...@free-electrons.com wrote: Hi Michal, On Sun, 7 Jun 2015 18:48:26 +0200 Michal Suchanek hramr...@gmail.com wrote: Hello, On 5 June 2015 at 13:52, Roy Spliet r.spl...@ultimaker.com wrote: Based on the default layout of the android image used at least on Olimex Lime Signed-off-by: Roy Spliet r.spl...@ultimaker.com --- include/configs/sunxi-common.h | 9 + 1 file changed, 9 insertions(+) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index ec28c40..b38f2f5 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -404,8 +404,15 @@ extern int soft_i2c_gpio_scl; #define BOOT_TARGET_DEVICES_USB(func) #endif +#ifdef CONFIG_NAND +#define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand , 0) +#else +#define BOOT_TARGET_DEVICES_NAND(func) +#endif + #define BOOT_TARGET_DEVICES(func) \ BOOT_TARGET_DEVICES_MMC(func) \ + BOOT_TARGET_DEVICES_NAND(func) \ BOOT_TARGET_DEVICES_SCSI(func) \ BOOT_TARGET_DEVICES_USB(func) \ func(PXE, pxe, na) \ @@ -441,6 +448,8 @@ extern int soft_i2c_gpio_scl; MEM_LAYOUT_ENV_SETTINGS \ fdtfile= CONFIG_DEFAULT_DEVICE_TREE .dtb\0 \ console=ttyS0,115200\0 \ + mtdids=nand0=mtd2\0 \ + mtdparts=mtdparts=mtd2:0xffc0@0x40(nand0_main)\0 \ BOOTENV From what I heard the nand boot partition size should be specified in nand pages rather than bytes because the boot rom loads a fixed number of pages and just uses the start of each page regardless of page size. AFAIK, the mtdparts format only allows you to express partition offsets and sizes in bytes, and even if we had to change for something else, we should choose NAND blocks rather than NAND pages. The reason partitions should be block aligned in because the you can't erase specific pages in a block, which means that if you define 2 partitions sharing the same block, you won't be able to update one partition without potentially corrupting the other one. However, if the number of pages the boot0 partition takes up is not block aligned it means we cannot use the medium for booting and can just use 1 big partition anyway. Hm, I don't get your point. You can have a boot0 partition taking one NAND block, and several other partitions used for other purpose (though having a single UBI partition is a better approach). and how do you tell the kernel that these partitions follow the boot0 taking up one block when you only count in bytes? Oh come on! You just specify the appropriate size and offset in bytes. I did not find any document regarding the nand boot partition layout so I would like to see some input from somebody familiar with the driver. AFAIR, the mtd partition code checks for block alignment anyway, so you shouldn't be allowed to create two partitions sharing the same block. While it is fine for testing to hand-edit the environment the final nand support should have 1) way to express the boot partition size in nand pages Why should we add that ? The conversion from a number of blocks to a number bytes is pretty straightforward (number_of_blocks * block_size_in_bytes). Because the block size is not the same on all flash chips, obviously. And that's why partitions are defined in the board dts, and not the SoC dtsi... If there is only one block size that can ever be reasonably supported due to other constraints then it's fine to just hardcode it. I think we already had this discussion on the #linux-sunxi channel, and you're trying to use a generic config from things that are really board specific. What's the problem with having different partition layout depending on the board ? Why do we have nand chip detection then? There are a lot of other stuff detected from the NAND chip ID (or ONFI or JEDEC standard), but remember that the partition stuff are supposed to be common to all the MTD devices, and I'm not sure all of them can use the erase size (or block size unit) to express their partitions offsets/sizes. Moreover, having the partition layout expressed in bytes is IMO clearer than having it expressed in blocks. We can just write the chip parameters in DT and have everything in one place at least. Yes, and we could also declare USB devices in the DT. If we cannot use the detected parameters to infer the related values in DT then the detection is useless for DT based
Re: [U-Boot] d.bfd: error: /.../libgcc.a(_udivdi3.o) uses VFP register arguments, u-boot does not
fabioca fabio_cannizzo at yahoo.com writes: I just cloned the repo (top commit: 64d16706a052553c85d2f8f4c741879a4e3e6116) and run on a bananapi (armv7): # make Bananapi_defconfig # make The second command fails with errors like: ld.bfd: error: /usr/lib/gcc/armv7l-unknown-linux-gnueabihf/4.9.2/libgcc.a(_udivdi3.o) uses VFP register arguments, u-boot does not Any suggestion? Thanks a lot Fabio Hi Fabio! Try this patch, and see if that solves the issue: http://lists.denx.de/pipermail/u-boot/2015-June/216480.html Regards, B. Nortmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] d.bfd: error: /.../libgcc.a(_udivdi3.o) uses VFP register arguments, u-boot does not
Yes it solves the issue. Thanks for speedy reply! -- View this message in context: http://u-boot.10912.n7.nabble.com/d-bfd-error-libgcc-a-udivdi3-o-uses-VFP-register-arguments-u-boot-does-not-tp217065p217077.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
