Re: [U-Boot] u-boot on beagleboard finds incorrect memory size.
On Thu, Jan 26, 2012 at 5:21 PM, Tom Rini tom.r...@gmail.com wrote:
On Thu, Jan 26, 2012 at 12:35 PM, wilsonjonathan
piercing_m...@hotmail.com wrote:
On Thu, 2012-01-26 at 12:28 -0700, Tom Rini wrote:
On Thu, Jan 26, 2012 at 12:14 PM, wilsonjonathan
piercing_m...@hotmail.com wrote:
On Thu, 2012-01-26 at 10:08 -0700, Tom Rini wrote:
On Wed, Jan 25, 2012 at 1:06 PM, wilsonjonathan
piercing_m...@hotmail.com wrote:
The u-boot loader is showing an incorrect size in the memory, and
passing the invalid information to the kernel.
What revision of the board do you have? Is this a 'classic' rev C4?
Thanks.
As far as I'm aware yes, standard C4 from digikey.
I've done a little more searching, and found that adding #define DEBUG
to /arc/arm/lib/board.c brings up more detailed info.
I will re-confirm with mine then. Previous versions of U-Boot/MLO
report how much memory, 512MB?
I don't have an older version to hand, but according to the specs it
should be 256MB using a 2Gb MDDR SDRAM and I seem to recall it did
display that.
OK, thanks. Does the following fix it for you?
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index 5c04b34..1efdbb0 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -161,7 +161,7 @@ void get_board_mem_timings(u32 *mcfg, u32 *ctrla,
u32 *ctrlb, u32 *rfr_ctrl,
case REVISION_C4:
if (pop_mfr == NAND_MFR_STMICRO pop_id == 0xba) {
/* 512MB DDR */
- *mcfg = NUMONYX_V_MCFG_165(512 20);
+ *mcfg = NUMONYX_V_MCFG_165(256 20);
*ctrla = NUMONYX_V_ACTIMA_165;
*ctrlb = NUMONYX_V_ACTIMB_165;
*rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_165MHz;
Hi Tom,
No change on my c4:
(For reference, i've noticed my older B5,C2 are not affected by this bug..)
U-Boot 2011.12-4-g79b8c19 (Jan 27 2012 - 08:45:02)
OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 mHz
OMAP3 Beagle board + LPDDR/NAND
I2C: ready
DRAM: 1 GiB
NAND: 256 MiB
MMC: OMAP SD/MMC: 0
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index 6a457cb..9aa05d4 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -159,8 +159,8 @@ void get_board_mem_timings(u32 *mcfg, u32 *ctrla,
u32 *ctrlb, u32 *rfr_ctrl,
switch (get_board_revision()) {
case REVISION_C4:
if (pop_mfr == NAND_MFR_STMICRO pop_id == 0xba) {
- /* 512MB DDR */
- *mcfg = NUMONYX_V_MCFG_165(512 20);
+ /* Beagleboard Rev C4, 256MB DDR */
+ *mcfg = NUMONYX_V_MCFG_165(256 20);
*ctrla = NUMONYX_V_ACTIMA_165;
*ctrlb = NUMONYX_V_ACTIMB_165;
*rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_165MHz;
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot on beagleboard finds incorrect memory size.
On Fri, Jan 27, 2012 at 9:58 AM, Tom Rini tom.r...@gmail.com wrote:
On Fri, Jan 27, 2012 at 8:50 AM, wilsonjonathan
piercing_m...@hotmail.com wrote:
I think the area of code that needs investigating is in
arch/arm/cpu/armv7/omap3/sdrc.c
line 82 onwards :-
u32 get_sdr_cs_size(u32 cs)
{
u32 size;
/* get ram size field */
size = readl(sdrc_base-cs[cs].mcfg) 8;
size = 0x3FF; /* remove unwanted bits */
size = 21; /* multiply by 2 MiB to find size in MB */
return size;
}
Which I think is set in arc/arm/include/asm/arch-omap3/cpu.h but I don't
understand how the - stuff works.
This is all correct. However, what's going wrong is we're programming
the size of memory found incorrectly and we don't yet have a safe
method to probe how much memory is really there (aside:
get_ram_size(...) goes off into the weeds on omap3 and it's on my TODO
list, and rising fast, to get my flyswatter out, hooked up and see
what's really happening). So what I really need to know is which of
the cases in beagle.c this board is falling into (I suspect it's the
top half of that else, but it's 2x128MB not 1x256). Thanks again!
Okay, little bit more information is shown with printf's..
U-Boot SPL 2011.12-1-g35bbe6c-dirty (Jan 27 2012 - 10:15:33)
Texas Instruments Revision detection unimplemented
case REVISION_C4:
actual pop_id: 0xBA
actual pop_mfr: 0x2C
case REVISION_C4: Neither option was selected.
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img
using:
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index 9aa05d4..4c7bf94 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -158,7 +158,11 @@ void get_board_mem_timings(u32 *mcfg, u32 *ctrla,
u32 *ctrlb, u32 *rfr_ctrl,
*mr = MICRON_V_MR_165;
switch (get_board_revision()) {
case REVISION_C4:
+ printf(case REVISION_C4:\n);
+ printf(actual pop_id: 0x%02X \n, pop_id);
+ printf(actual pop_mfr: 0x%02X \n, pop_mfr);
if (pop_mfr == NAND_MFR_STMICRO pop_id == 0xba) {
+ printf(pop_id == 0xba (C4)\n);
/* Beagleboard Rev C4, 256MB DDR */
*mcfg = NUMONYX_V_MCFG_165(256 20);
*ctrla = NUMONYX_V_ACTIMA_165;
@@ -166,6 +170,7 @@ void get_board_mem_timings(u32 *mcfg, u32 *ctrla,
u32 *ctrlb, u32 *rfr_ctrl,
*rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_165MHz;
break;
} else if (pop_mfr == NAND_MFR_MICRON pop_id == 0xbc) {
+ printf(pop_id == 0xbc (c5)\n);
/* Beagleboard Rev C5, 256MB DDR */
*mcfg = MICRON_V_MCFG_200(256 20);
*ctrla = MICRON_V_ACTIMA_200;
@@ -173,6 +178,7 @@ void get_board_mem_timings(u32 *mcfg, u32 *ctrla,
u32 *ctrlb, u32 *rfr_ctrl,
*rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_200MHz;
break;
}
+ printf(case REVISION_C4: Neither option was selected.\n);
case REVISION_XM_A:
case REVISION_XM_B:
case REVISION_XM_C:
On my c4, it looks like neither option is selected for it..
./include/linux/mtd/nand.h:#define NAND_MFR_STMICRO 0x20
./include/linux/mtd/nand.h:#define NAND_MFR_MICRON 0x2c
looks like the RAM/NAND options might have been reversed for C4 and C5
in the IF statement.. but i dont' have a C5 to test..
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot on beagleboard finds incorrect memory size.
On Fri, Jan 27, 2012 at 10:25 AM, Tom Rini tom.r...@gmail.com wrote:
On Fri, Jan 27, 2012 at 9:23 AM, Robert Nelson robertcnel...@gmail.com
wrote:
On Fri, Jan 27, 2012 at 9:58 AM, Tom Rini tom.r...@gmail.com wrote:
On Fri, Jan 27, 2012 at 8:50 AM, wilsonjonathan
piercing_m...@hotmail.com wrote:
I think the area of code that needs investigating is in
arch/arm/cpu/armv7/omap3/sdrc.c
line 82 onwards :-
u32 get_sdr_cs_size(u32 cs)
{
u32 size;
/* get ram size field */
size = readl(sdrc_base-cs[cs].mcfg) 8;
size = 0x3FF; /* remove unwanted bits */
size = 21; /* multiply by 2 MiB to find size in MB */
return size;
}
Which I think is set in arc/arm/include/asm/arch-omap3/cpu.h but I don't
understand how the - stuff works.
This is all correct. However, what's going wrong is we're programming
the size of memory found incorrectly and we don't yet have a safe
method to probe how much memory is really there (aside:
get_ram_size(...) goes off into the weeds on omap3 and it's on my TODO
list, and rising fast, to get my flyswatter out, hooked up and see
what's really happening). So what I really need to know is which of
the cases in beagle.c this board is falling into (I suspect it's the
top half of that else, but it's 2x128MB not 1x256). Thanks again!
Okay, little bit more information is shown with printf's..
U-Boot SPL 2011.12-1-g35bbe6c-dirty (Jan 27 2012 - 10:15:33)
Texas Instruments Revision detection unimplemented
case REVISION_C4:
actual pop_id: 0xBA
actual pop_mfr: 0x2C
case REVISION_C4: Neither option was selected.
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img
using:
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index 9aa05d4..4c7bf94 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -158,7 +158,11 @@ void get_board_mem_timings(u32 *mcfg, u32 *ctrla,
u32 *ctrlb, u32 *rfr_ctrl,
*mr = MICRON_V_MR_165;
switch (get_board_revision()) {
case REVISION_C4:
+ printf(case REVISION_C4:\n);
+ printf(actual pop_id: 0x%02X \n, pop_id);
+ printf(actual pop_mfr: 0x%02X \n, pop_mfr);
if (pop_mfr == NAND_MFR_STMICRO pop_id == 0xba) {
+ printf(pop_id == 0xba (C4)\n);
/* Beagleboard Rev C4, 256MB DDR */
*mcfg = NUMONYX_V_MCFG_165(256 20);
*ctrla = NUMONYX_V_ACTIMA_165;
@@ -166,6 +170,7 @@ void get_board_mem_timings(u32 *mcfg, u32 *ctrla,
u32 *ctrlb, u32 *rfr_ctrl,
*rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_165MHz;
break;
} else if (pop_mfr == NAND_MFR_MICRON pop_id == 0xbc) {
+ printf(pop_id == 0xbc (c5)\n);
/* Beagleboard Rev C5, 256MB DDR */
*mcfg = MICRON_V_MCFG_200(256 20);
*ctrla = MICRON_V_ACTIMA_200;
@@ -173,6 +178,7 @@ void get_board_mem_timings(u32 *mcfg, u32 *ctrla,
u32 *ctrlb, u32 *rfr_ctrl,
*rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_200MHz;
break;
}
+ printf(case REVISION_C4: Neither option was selected.\n);
case REVISION_XM_A:
case REVISION_XM_B:
case REVISION_XM_C:
On my c4, it looks like neither option is selected for it..
./include/linux/mtd/nand.h:#define NAND_MFR_STMICRO 0x20
./include/linux/mtd/nand.h:#define NAND_MFR_MICRON 0x2c
looks like the RAM/NAND options might have been reversed for C4 and C5
in the IF statement.. but i dont' have a C5 to test..
I've got a C5 which has been OK. I've got to step out for a few but
I'll have a patch later today for this I hope, if you don't beat me to
it :)
Ah, now i see the problem.. There actually isn't support in u-boot
for the regular C4.. ;)
When the memory options where transfered from x-loader. The special
'white label' 512Mb DDR C4 from Special Computing became the regular
C4..
see:
http://gitorious.org/x-loader/x-loader/blobs/master/board/omap3530beagle/omap3530beagle.c#line576
and
http://gitorious.org/x-loader/x-loader/commit/1dac1a7c188e79edabe211ccaadf58cd83b278dc
So first we need to document the 512MB DDR something like...
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index 6a457cb..cf55c79 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -159,7 +159,7 @@ void get_board_mem_timings(u32 *mcfg, u32 *ctrla,
u32 *ctrlb, u32 *rfr_ctrl,
switch (get_board_revision()) {
case REVISION_C4:
if (pop_mfr == NAND_MFR_STMICRO pop_id == 0xba) {
- /* 512MB DDR */
+ /* Beagle Rev C4 from Special Computing, 512MB DDR */
*mcfg = NUMONYX_V_MCFG_165(512 20);
*ctrla = NUMONYX_V_ACTIMA_165;
*ctrlb
Re: [U-Boot] u-boot on beagleboard finds incorrect memory size.
On Fri, Jan 27, 2012 at 10:51 AM, Robert Nelson robertcnel...@gmail.com wrote:
On Fri, Jan 27, 2012 at 10:25 AM, Tom Rini tom.r...@gmail.com wrote:
On Fri, Jan 27, 2012 at 9:23 AM, Robert Nelson robertcnel...@gmail.com
wrote:
On Fri, Jan 27, 2012 at 9:58 AM, Tom Rini tom.r...@gmail.com wrote:
On Fri, Jan 27, 2012 at 8:50 AM, wilsonjonathan
piercing_m...@hotmail.com wrote:
I think the area of code that needs investigating is in
arch/arm/cpu/armv7/omap3/sdrc.c
line 82 onwards :-
u32 get_sdr_cs_size(u32 cs)
{
u32 size;
/* get ram size field */
size = readl(sdrc_base-cs[cs].mcfg) 8;
size = 0x3FF; /* remove unwanted bits */
size = 21; /* multiply by 2 MiB to find size in MB */
return size;
}
Which I think is set in arc/arm/include/asm/arch-omap3/cpu.h but I don't
understand how the - stuff works.
This is all correct. However, what's going wrong is we're programming
the size of memory found incorrectly and we don't yet have a safe
method to probe how much memory is really there (aside:
get_ram_size(...) goes off into the weeds on omap3 and it's on my TODO
list, and rising fast, to get my flyswatter out, hooked up and see
what's really happening). So what I really need to know is which of
the cases in beagle.c this board is falling into (I suspect it's the
top half of that else, but it's 2x128MB not 1x256). Thanks again!
Okay, little bit more information is shown with printf's..
U-Boot SPL 2011.12-1-g35bbe6c-dirty (Jan 27 2012 - 10:15:33)
Texas Instruments Revision detection unimplemented
case REVISION_C4:
actual pop_id: 0xBA
actual pop_mfr: 0x2C
case REVISION_C4: Neither option was selected.
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img
using:
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index 9aa05d4..4c7bf94 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -158,7 +158,11 @@ void get_board_mem_timings(u32 *mcfg, u32 *ctrla,
u32 *ctrlb, u32 *rfr_ctrl,
*mr = MICRON_V_MR_165;
switch (get_board_revision()) {
case REVISION_C4:
+ printf(case REVISION_C4:\n);
+ printf(actual pop_id: 0x%02X \n, pop_id);
+ printf(actual pop_mfr: 0x%02X \n, pop_mfr);
if (pop_mfr == NAND_MFR_STMICRO pop_id == 0xba) {
+ printf(pop_id == 0xba (C4)\n);
/* Beagleboard Rev C4, 256MB DDR */
*mcfg = NUMONYX_V_MCFG_165(256 20);
*ctrla = NUMONYX_V_ACTIMA_165;
@@ -166,6 +170,7 @@ void get_board_mem_timings(u32 *mcfg, u32 *ctrla,
u32 *ctrlb, u32 *rfr_ctrl,
*rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_165MHz;
break;
} else if (pop_mfr == NAND_MFR_MICRON pop_id == 0xbc) {
+ printf(pop_id == 0xbc (c5)\n);
/* Beagleboard Rev C5, 256MB DDR */
*mcfg = MICRON_V_MCFG_200(256 20);
*ctrla = MICRON_V_ACTIMA_200;
@@ -173,6 +178,7 @@ void get_board_mem_timings(u32 *mcfg, u32 *ctrla,
u32 *ctrlb, u32 *rfr_ctrl,
*rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_200MHz;
break;
}
+ printf(case REVISION_C4: Neither option was selected.\n);
case REVISION_XM_A:
case REVISION_XM_B:
case REVISION_XM_C:
On my c4, it looks like neither option is selected for it..
./include/linux/mtd/nand.h:#define NAND_MFR_STMICRO 0x20
./include/linux/mtd/nand.h:#define NAND_MFR_MICRON 0x2c
looks like the RAM/NAND options might have been reversed for C4 and C5
in the IF statement.. but i dont' have a C5 to test..
I've got a C5 which has been OK. I've got to step out for a few but
I'll have a patch later today for this I hope, if you don't beat me to
it :)
Ah, now i see the problem.. There actually isn't support in u-boot
for the regular C4.. ;)
When the memory options where transfered from x-loader. The special
'white label' 512Mb DDR C4 from Special Computing became the regular
C4..
see:
http://gitorious.org/x-loader/x-loader/blobs/master/board/omap3530beagle/omap3530beagle.c#line576
and
http://gitorious.org/x-loader/x-loader/commit/1dac1a7c188e79edabe211ccaadf58cd83b278dc
So first we need to document the 512MB DDR something like...
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index 6a457cb..cf55c79 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -159,7 +159,7 @@ void get_board_mem_timings(u32 *mcfg, u32 *ctrla,
u32 *ctrlb, u32 *rfr_ctrl,
switch (get_board_revision()) {
case REVISION_C4:
if (pop_mfr == NAND_MFR_STMICRO pop_id == 0xba) {
- /* 512MB DDR */
+ /* Beagle Rev C4 from Special Computing, 512MB DDR */
*mcfg = NUMONYX_V_MCFG_165
Re: [U-Boot] u-boot on beagleboard finds incorrect memory size.
On Fri, Jan 27, 2012 at 11:58 AM, Tom Rini tom.r...@gmail.com wrote:
On Fri, Jan 27, 2012 at 10:09 AM, Robert Nelson robertcnel...@gmail.com
wrote:
On Fri, Jan 27, 2012 at 10:51 AM, Robert Nelson robertcnel...@gmail.com
wrote:
On Fri, Jan 27, 2012 at 10:25 AM, Tom Rini tom.r...@gmail.com wrote:
On Fri, Jan 27, 2012 at 9:23 AM, Robert Nelson robertcnel...@gmail.com
wrote:
On Fri, Jan 27, 2012 at 9:58 AM, Tom Rini tom.r...@gmail.com wrote:
On Fri, Jan 27, 2012 at 8:50 AM, wilsonjonathan
piercing_m...@hotmail.com wrote:
I think the area of code that needs investigating is in
arch/arm/cpu/armv7/omap3/sdrc.c
line 82 onwards :-
u32 get_sdr_cs_size(u32 cs)
{
u32 size;
/* get ram size field */
size = readl(sdrc_base-cs[cs].mcfg) 8;
size = 0x3FF; /* remove unwanted bits */
size = 21; /* multiply by 2 MiB to find size in MB
*/
return size;
}
Which I think is set in arc/arm/include/asm/arch-omap3/cpu.h but I don't
understand how the - stuff works.
This is all correct. However, what's going wrong is we're programming
the size of memory found incorrectly and we don't yet have a safe
method to probe how much memory is really there (aside:
get_ram_size(...) goes off into the weeds on omap3 and it's on my TODO
list, and rising fast, to get my flyswatter out, hooked up and see
what's really happening). So what I really need to know is which of
the cases in beagle.c this board is falling into (I suspect it's the
top half of that else, but it's 2x128MB not 1x256). Thanks again!
Okay, little bit more information is shown with printf's..
U-Boot SPL 2011.12-1-g35bbe6c-dirty (Jan 27 2012 - 10:15:33)
Texas Instruments Revision detection unimplemented
case REVISION_C4:
actual pop_id: 0xBA
actual pop_mfr: 0x2C
case REVISION_C4: Neither option was selected.
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img
using:
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index 9aa05d4..4c7bf94 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -158,7 +158,11 @@ void get_board_mem_timings(u32 *mcfg, u32 *ctrla,
u32 *ctrlb, u32 *rfr_ctrl,
*mr = MICRON_V_MR_165;
switch (get_board_revision()) {
case REVISION_C4:
+ printf(case REVISION_C4:\n);
+ printf(actual pop_id: 0x%02X \n, pop_id);
+ printf(actual pop_mfr: 0x%02X \n, pop_mfr);
if (pop_mfr == NAND_MFR_STMICRO pop_id == 0xba) {
+ printf(pop_id == 0xba (C4)\n);
/* Beagleboard Rev C4, 256MB DDR */
*mcfg = NUMONYX_V_MCFG_165(256 20);
*ctrla = NUMONYX_V_ACTIMA_165;
@@ -166,6 +170,7 @@ void get_board_mem_timings(u32 *mcfg, u32 *ctrla,
u32 *ctrlb, u32 *rfr_ctrl,
*rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_165MHz;
break;
} else if (pop_mfr == NAND_MFR_MICRON pop_id == 0xbc) {
+ printf(pop_id == 0xbc (c5)\n);
/* Beagleboard Rev C5, 256MB DDR */
*mcfg = MICRON_V_MCFG_200(256 20);
*ctrla = MICRON_V_ACTIMA_200;
@@ -173,6 +178,7 @@ void get_board_mem_timings(u32 *mcfg, u32 *ctrla,
u32 *ctrlb, u32 *rfr_ctrl,
*rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_200MHz;
break;
}
+ printf(case REVISION_C4: Neither option was selected.\n);
case REVISION_XM_A:
case REVISION_XM_B:
case REVISION_XM_C:
On my c4, it looks like neither option is selected for it..
./include/linux/mtd/nand.h:#define NAND_MFR_STMICRO 0x20
./include/linux/mtd/nand.h:#define NAND_MFR_MICRON 0x2c
looks like the RAM/NAND options might have been reversed for C4 and C5
in the IF statement.. but i dont' have a C5 to test..
I've got a C5 which has been OK. I've got to step out for a few but
I'll have a patch later today for this I hope, if you don't beat me to
it :)
Ah, now i see the problem.. There actually isn't support in u-boot
for the regular C4.. ;)
When the memory options where transfered from x-loader. The special
'white label' 512Mb DDR C4 from Special Computing became the regular
C4..
see:
http://gitorious.org/x-loader/x-loader/blobs/master/board/omap3530beagle/omap3530beagle.c#line576
and
http://gitorious.org/x-loader/x-loader/commit/1dac1a7c188e79edabe211ccaadf58cd83b278dc
So first we need to document the 512MB DDR something like...
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index 6a457cb..cf55c79 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -159,7 +159,7 @@ void get_board_mem_timings(u32 *mcfg, u32 *ctrla,
u32 *ctrlb, u32 *rfr_ctrl,
switch (get_board_revision()) {
case REVISION_C4:
if (pop_mfr == NAND_MFR_STMICRO pop_id == 0xba
Re: [U-Boot] u-boot on beagleboard finds incorrect memory size.
On Fri, Jan 27, 2012 at 12:42 PM, wilsonjonathan piercing_m...@hotmail.com wrote: On Fri, 2012-01-27 at 12:00 -0600, Robert Nelson wrote: On Fri, Jan 27, 2012 at 11:58 AM, Tom Rini tom.r...@gmail.com wrote: OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 mHz OMAP3 Beagle board + LPDDR/NAND I2C: ready DRAM: 256 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0 The DRAM is now correct... but now to fix the NAND, it should be 512MiB.. ;) Good catch! Can you reply with a Signed-off-by line and I'll incorporate this into u-boot-ti/master? Thanks! Signed-off-by: Robert Nelson robertcnel...@gmail.com Thanks for pulling it into master so quickly.. ;) Regards, Wow that was interesting :-) Not being a c programmer I think I learnt something. I've made the change manually and it seems to work. My question now is I think this version is significantly different to older versions in that it no longer loads boot.scr and executes it. So my obvious question is how do I get it to do that, or using the new system what do I need to put into, I think, uEnv.txt to get it to load the latest version of ubuntu-precise-pangoline. Mind you, I think that it will then baulk at the initrd script files which manipulate boot.scr, oh joy! till you get use to uEnv.txt's I've got a compatibility script listed here.. http://elinux.org/BeagleBoardUbuntu#boot.scr_-.3E_uEnv.txt I've used it for a year, hopefully it still works as is with u-boot git.. Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx23: Put back RAM voltage level to its original value
On Fri, Apr 26, 2013 at 11:01 AM, Fabio Estevam feste...@gmail.com wrote: From: Fabio Estevam fabio.este...@freescale.com commit 5c2f444c9 (mxs: Reset the EMI block on mx23) changed the DDR voltage level, which causes mx23evk to fail to load a kernel. Put back the original values, so that mx23evk can boot a kernel again. Signed-off-by: Fabio Estevam fabio.este...@freescale.com Tested-by: Robert Nelson robertcnel...@gmail.com --- arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index bc2d69c..4950490 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c @@ -234,7 +234,7 @@ static void mx23_mem_setup_vddmem(void) struct mxs_power_regs *power_regs = (struct mxs_power_regs *)MXS_POWER_BASE; - writel((0x10 POWER_VDDMEMCTRL_TRG_OFFSET) | + writel((0x12 POWER_VDDMEMCTRL_TRG_OFFSET) | POWER_VDDMEMCTRL_ENABLE_ILIMIT | POWER_VDDMEMCTRL_ENABLE_LINREG | POWER_VDDMEMCTRL_PULLDOWN_ACTIVE, @@ -242,7 +242,7 @@ static void mx23_mem_setup_vddmem(void) early_delay(1); - writel((0x10 POWER_VDDMEMCTRL_TRG_OFFSET) | + writel((0x12 POWER_VDDMEMCTRL_TRG_OFFSET) | POWER_VDDMEMCTRL_ENABLE_LINREG, power_regs-hw_power_vddmemctrl); } -- 1.7.9.5 Sweet! This fixes the random memory issues I was seeing on my imx233-oLinuXno-Micro when using u-boot.. I Used memtester for memory verification.. u-boot v2013.04 v3.9-rc7 root@arm:/home/debian# memtester 24M memtester version 4.2.2 (32-bit) Copyright (C) 2010 Charles Cazabon. Licensed under the GNU General Public License version 2 (only). pagesize is 4096 pagesizemask is 0xf000 want 24MB (25165824 bytes) got 24MB (25165824 bytes), trying mlock ...locked. Loop 1: Stuck Address : ok Random Value: ok Compare XOR : ok Compare SUB : ok Compare MUL : ok Compare DIV : ok Compare OR : ok Compare AND : ok Sequential Increment: ok Solid Bits : ok Block Sequential: testing 254FAILURE: 0xfefefefe != 0xfefe00fe at offset 0x002c11bc. Checkerboard: setting 37^C u-boot v2013.04 + mx23: Put back RAM voltage level to its original valueu-boot v3.9-rc7 root@arm:/home/debian# memtester 24M memtester version 4.2.2 (32-bit) Copyright (C) 2010 Charles Cazabon. Licensed under the GNU General Public License version 2 (only). pagesize is 4096 pagesizemask is 0xf000 want 24MB (25165824 bytes) got 24MB (25165824 bytes), trying mlock ...locked. Loop 1: Stuck Address : ok Random Value: ok Compare XOR : ok Compare SUB : ok Compare MUL : ok Compare DIV : ok Compare OR : ok Compare AND : ok Sequential Increment: ok Solid Bits : ok Block Sequential: ok Checkerboard: ok Bit Spread : ok Bit Flip: ok Walking Ones: ok Walking Zeroes : ok 8-bit Writes: ok 16-bit Writes : ok Loop 2: Stuck Address : ok root@arm:/home/debian# cat /proc/cpuinfo processor : 0 model name : ARM926EJ-S rev 5 (v5l) BogoMIPS: 226.09 Features: swp half thumb fastmult edsp java CPU implementer : 0x41 CPU architecture: 5TEJ CPU variant : 0x0 CPU part: 0x926 CPU revision: 5 Hardware: Freescale i.MX23 (Device Tree) Revision: Serial : root@arm:/home/debian# uname -a Linux arm 3.9.0-rc7-imxv5-x0.9 #2 Thu Apr 25 15:27:14 CDT 2013 armv5tejl GNU/Linux Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] beagle: expansion boards: retry i2c_read with 16bit addressing
Some expansion boards now ship with at24 eeproms that need to communicate
via 16bit addressing.
Signed-off-by: Robert Nelson robertcnel...@gmail.com
---
board/ti/beagle/beagle.c |8
1 file changed, 8 insertions(+)
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index b829a79..9493c6b 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -227,6 +227,14 @@ static unsigned int get_expansion_id(void)
i2c_read(EXPANSION_EEPROM_I2C_ADDRESS, 0, 1, (u8 *)expansion_config,
sizeof(expansion_config));
+ /* retry reading configuration data with 16bit addressing */
+ if ((expansion_config.device_vendor == 0xFF00) ||
+ (expansion_config.device_vendor == 0x)) {
+ printf(EEPROM is blank or 8bit addressing failed: retrying
with 16bit:\n);
+ i2c_read(EXPANSION_EEPROM_I2C_ADDRESS, 0, 2, (u8
*)expansion_config,
+sizeof(expansion_config));
+ }
+
i2c_set_bus_num(TWL4030_I2C_BUS);
return expansion_config.device_vendor;
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] beagle: expansion boards: add LSR COM6L adapter
http://www.lsr.com/wireless-products/com6l The eeprom on this expansion board requires 16bit addressing. Signed-off-by: Robert Nelson robertcnel...@gmail.com --- board/ti/beagle/beagle.c |6 ++ 1 file changed, 6 insertions(+) diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c index 9493c6b..58bd556 100644 --- a/board/ti/beagle/beagle.c +++ b/board/ti/beagle/beagle.c @@ -72,6 +72,7 @@ #define BBTOYS_LCD 0x03000B00 #define BCT_BRETTL30x01000F00 #define BCT_BRETTL40x02000F00 +#define LSR_COM6L_ADPT 0x01001300 #define BEAGLE_NO_EEPROM 0x DECLARE_GLOBAL_DATA_PTR; @@ -462,6 +463,11 @@ int misc_init_r(void) case BCT_BRETTL4: printf(Recognized bct electronic GmbH brettl4 board\n); break; + case LSR_COM6L_ADPT: + printf(Recognized LSR COM6L Adapter Board\n); + MUX_BBTOYS_WIFI() + setenv(buddy, lsr-com6l-adpt); + break; case BEAGLE_NO_EEPROM: printf(No EEPROM on expansion board\n); setenv(buddy, none); -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] v2013.07-rc2
On Fri, Jun 28, 2013 at 5:12 PM, Tom Rini tr...@ti.com wrote: Hey all, I've tagged and pushed v2013.07-rc2. A bit more over the place than I should have gone, but picked up a lot of things that have been outstanding for a while. The big thing is a refactor of the boot loop. Everything should be working right now, but please test. Related to this is the ability to have crytpographically signed images. It's like secure boot in UEFI land, but hopefully without the kerfuffle. If you've got changes outstanding still, please start gently poking custodians with patchwork links. I've got a good bit of stuff I need to deal with myself still, but please prod me all the same. So, the bootm refactor ( 35fc84fa1ff51e15ecd3e464dac87eb105ffed30 ) also broke bootz/zImage... Got it to atleast get past the invalid OS message via: diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c index 02a5013..a0b55ef 100644 --- a/common/cmd_bootm.c +++ b/common/cmd_bootm.c @@ -1744,6 +1744,12 @@ static int bootz_start(cmd_tbl_t *cmdtp, int flag, int argc, int ret; void *zi_start, *zi_end; + memset(images, 0, sizeof(bootm_headers_t)); + + boot_start_lmb(images); + + images-os.os = IH_OS_LINUX; + ret = do_bootm_states(cmdtp, flag, argc, argv, BOOTM_STATE_START, images, 1); However it's still locking up at Starting Kernel ... Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] v2013.07-rc2
On Tue, Jul 2, 2013 at 2:39 AM, Simon Glass s...@chromium.org wrote:
Hi Robert,
On Tue, Jul 2, 2013 at 5:44 AM, Robert Nelson robertcnel...@gmail.com
wrote:
On Fri, Jun 28, 2013 at 5:12 PM, Tom Rini tr...@ti.com wrote:
Hey all,
I've tagged and pushed v2013.07-rc2. A bit more over the place than I
should have gone, but picked up a lot of things that have been
outstanding for a while. The big thing is a refactor of the boot loop.
Everything should be working right now, but please test. Related to
this is the ability to have crytpographically signed images. It's like
secure boot in UEFI land, but hopefully without the kerfuffle.
If you've got changes outstanding still, please start gently poking
custodians with patchwork links. I've got a good bit of stuff I need to
deal with myself still, but please prod me all the same.
So, the bootm refactor ( 35fc84fa1ff51e15ecd3e464dac87eb105ffed30 )
also broke bootz/zImage...
Got it to atleast get past the invalid OS message via:
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 02a5013..a0b55ef 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -1744,6 +1744,12 @@ static int bootz_start(cmd_tbl_t *cmdtp, int
flag, int argc,
int ret;
void *zi_start, *zi_end;
+ memset(images, 0, sizeof(bootm_headers_t));
+
+ boot_start_lmb(images);
+
+ images-os.os = IH_OS_LINUX;
+
ret = do_bootm_states(cmdtp, flag, argc, argv, BOOTM_STATE_START,
images, 1);
However it's still locking up at Starting Kernel ...
What board is this please? I have only tested on x86, but perhaps have
missed something here.
So far it looks like any arm board... I was working on specifically
the imx6 quad core wandboard bringup. But i've also verified it on
the Panda/Beagle too... Alll 3 of these boards worked fine with
v2013.07-rc1...
Wandboard:
Boot Sequence: (device tree boot)
load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file}
bootz ${loadaddr} - ${fdt_addr}
U-Boot 2013.07-rc2-1-g23c15c2-dirty (Jul 02 2013 - 06:33:59)
CPU: Freescale i.MX6Q rev1.2 at 792 MHz
Reset cause: POR
Board: Wandboard
DRAM: 2 GiB
MMC: FSL_SDHC: 0, FSL_SDHC: 1
*** Warning - bad CRC, using default environment
In:serial
Out: serial
Err: serial
Net: FEC [PRIME]
Warning: FEC using MAC address from net device
Hit any key to stop autoboot: 0
= load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
4112496 bytes read in 307 ms (12.8 MiB/s)
= load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file}
22150 bytes read in 126 ms (170.9 KiB/s)
= bootz ${loadaddr} - ${fdt_addr}
Beagle xM:
Boot Sequence: (old board file boot)
fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
bootz ${loadaddr}
OMAP3 beagleboard.org # fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
reading zImage
3421392 bytes read in 246 ms (13.3 MiB/s)
OMAP3 beagleboard.org # bootz ${loadaddr}
data abort
MAYBE you should read doc/README.arm-unaligned-accesses
pc : [9ff8bf20] lr : [9ff5d2a8]
sp : 9fef8bd8 ip : 9ff8 fp : 9fef9760
r10: 9ffa6314 r9 : 9ffa7710 r8 : 9fef8f30
r7 : 805434d0 r6 : 00020e61 r5 : ffafefff r4 : 9ff9c6e6
r3 : 00020e61 r2 : 003434d0 r1 : 8020 r0 : 9fef8cf0
Flags: nzcv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
resetting ...
U-Boot SPL 2013.07-rc2-1-g7c2cb8a-dirty (Jul 02 2013 - 06:14:53)
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] v2013.07-rc2
On Tue, Jul 2, 2013 at 6:41 AM, Robert Nelson robertcnel...@gmail.com wrote:
On Tue, Jul 2, 2013 at 2:39 AM, Simon Glass s...@chromium.org wrote:
Hi Robert,
On Tue, Jul 2, 2013 at 5:44 AM, Robert Nelson robertcnel...@gmail.com
wrote:
On Fri, Jun 28, 2013 at 5:12 PM, Tom Rini tr...@ti.com wrote:
Hey all,
I've tagged and pushed v2013.07-rc2. A bit more over the place than I
should have gone, but picked up a lot of things that have been
outstanding for a while. The big thing is a refactor of the boot loop.
Everything should be working right now, but please test. Related to
this is the ability to have crytpographically signed images. It's like
secure boot in UEFI land, but hopefully without the kerfuffle.
If you've got changes outstanding still, please start gently poking
custodians with patchwork links. I've got a good bit of stuff I need to
deal with myself still, but please prod me all the same.
So, the bootm refactor ( 35fc84fa1ff51e15ecd3e464dac87eb105ffed30 )
also broke bootz/zImage...
Got it to atleast get past the invalid OS message via:
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 02a5013..a0b55ef 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -1744,6 +1744,12 @@ static int bootz_start(cmd_tbl_t *cmdtp, int
flag, int argc,
int ret;
void *zi_start, *zi_end;
+ memset(images, 0, sizeof(bootm_headers_t));
+
+ boot_start_lmb(images);
+
+ images-os.os = IH_OS_LINUX;
+
ret = do_bootm_states(cmdtp, flag, argc, argv, BOOTM_STATE_START,
images, 1);
However it's still locking up at Starting Kernel ...
What board is this please? I have only tested on x86, but perhaps have
missed something here.
So far it looks like any arm board... I was working on specifically
the imx6 quad core wandboard bringup. But i've also verified it on
the Panda/Beagle too... Alll 3 of these boards worked fine with
v2013.07-rc1...
Wandboard:
Boot Sequence: (device tree boot)
load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file}
bootz ${loadaddr} - ${fdt_addr}
U-Boot 2013.07-rc2-1-g23c15c2-dirty (Jul 02 2013 - 06:33:59)
CPU: Freescale i.MX6Q rev1.2 at 792 MHz
Reset cause: POR
Board: Wandboard
DRAM: 2 GiB
MMC: FSL_SDHC: 0, FSL_SDHC: 1
*** Warning - bad CRC, using default environment
In:serial
Out: serial
Err: serial
Net: FEC [PRIME]
Warning: FEC using MAC address from net device
Hit any key to stop autoboot: 0
= load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
4112496 bytes read in 307 ms (12.8 MiB/s)
= load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file}
22150 bytes read in 126 ms (170.9 KiB/s)
= bootz ${loadaddr} - ${fdt_addr}
hardlock
Missed the important detail...
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] v2013.07-rc2
On Wed, Jul 3, 2013 at 8:52 AM, Simon Glass s...@chromium.org wrote:
Hi Robert.
On Tue, Jul 2, 2013 at 11:15 PM, Simon Glass s...@chromium.org wrote:
Hi Robert,
On Jul 2, 2013 8:41 PM, Robert Nelson robertcnel...@gmail.com wrote:
On Tue, Jul 2, 2013 at 2:39 AM, Simon Glass s...@chromium.org wrote:
Hi Robert,
On Tue, Jul 2, 2013 at 5:44 AM, Robert Nelson
robertcnel...@gmail.com
wrote:
On Fri, Jun 28, 2013 at 5:12 PM, Tom Rini tr...@ti.com wrote:
Hey all,
I've tagged and pushed v2013.07-rc2. A bit more over the place
than I
should have gone, but picked up a lot of things that have been
outstanding for a while. The big thing is a refactor of the boot
loop.
Everything should be working right now, but please test. Related
to
this is the ability to have crytpographically signed images. It's
like
secure boot in UEFI land, but hopefully without the kerfuffle.
If you've got changes outstanding still, please start gently poking
custodians with patchwork links. I've got a good bit of stuff I
need to
deal with myself still, but please prod me all the same.
So, the bootm refactor ( 35fc84fa1ff51e15ecd3e464dac87eb105ffed30 )
also broke bootz/zImage...
Got it to atleast get past the invalid OS message via:
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 02a5013..a0b55ef 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -1744,6 +1744,12 @@ static int bootz_start(cmd_tbl_t *cmdtp, int
flag, int argc,
int ret;
void *zi_start, *zi_end;
+ memset(images, 0, sizeof(bootm_headers_t));
+
+ boot_start_lmb(images);
+
+ images-os.os = IH_OS_LINUX;
+
ret = do_bootm_states(cmdtp, flag, argc, argv,
BOOTM_STATE_START,
images, 1);
However it's still locking up at Starting Kernel ...
What board is this please? I have only tested on x86, but perhaps have
missed something here.
So far it looks like any arm board... I was working on specifically
the imx6 quad core wandboard bringup. But i've also verified it on
the Panda/Beagle too... Alll 3 of these boards worked fine with
v2013.07-rc1...
Wandboard:
Boot Sequence: (device tree boot)
load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file}
bootz ${loadaddr} - ${fdt_addr}
U-Boot 2013.07-rc2-1-g23c15c2-dirty (Jul 02 2013 - 06:33:59)
CPU: Freescale i.MX6Q rev1.2 at 792 MHz
Reset cause: POR
Board: Wandboard
DRAM: 2 GiB
MMC: FSL_SDHC: 0, FSL_SDHC: 1
*** Warning - bad CRC, using default environment
In:serial
Out: serial
Err: serial
Net: FEC [PRIME]
Warning: FEC using MAC address from net device
Hit any key to stop autoboot: 0
= load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
4112496 bytes read in 307 ms (12.8 MiB/s)
= load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file}
22150 bytes read in 126 ms (170.9 KiB/s)
= bootz ${loadaddr} - ${fdt_addr}
Beagle xM:
Boot Sequence: (old board file boot)
fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
bootz ${loadaddr}
OMAP3 beagleboard.org # fatload mmc ${mmcdev}:${mmcpart} ${loadaddr}
zImage
reading zImage
3421392 bytes read in 246 ms (13.3 MiB/s)
OMAP3 beagleboard.org # bootz ${loadaddr}
data abort
MAYBE you should read doc/README.arm-unaligned-accesses
pc : [9ff8bf20] lr : [9ff5d2a8]
sp : 9fef8bd8 ip : 9ff8 fp : 9fef9760
r10: 9ffa6314 r9 : 9ffa7710 r8 : 9fef8f30
r7 : 805434d0 r6 : 00020e61 r5 : ffafefff r4 : 9ff9c6e6
r3 : 00020e61 r2 : 003434d0 r1 : 8020 r0 : 9fef8cf0
Flags: nzcv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
resetting ...
U-Boot SPL 2013.07-rc2-1-g7c2cb8a-dirty (Jul 02 2013 - 06:14:53)
Thanks for the details. I will take a look later today US time.
Unfortunately due to my current location I don't have access to a good ARM
bootz target. I believe I have found a problem, and will send out some
patches for you to try/debug, although with tidying up a few things.
However until I can test them (several days) they are for interest only.
Sure, no problem... Other then a long drive tonight, I'll have net
access over the 4th.. It's just 'too' easy to pack a beaglebone black
where ever i go. ;)
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] bootm: Add the missing PREP stage to bootz
On Wed, Jul 3, 2013 at 9:12 AM, Simon Glass s...@chromium.org wrote:
In the recent bootm refactor, the PREP stage was missing in the bootz
command. This causes unpredictable behaviour on platforms which need
this stage to operate correctly (e.g. ARM).
Signed-off-by: Simon Glass s...@chromium.org
---
common/cmd_bootm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 401055d..26ed7d8 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -1794,7 +1794,8 @@ int do_bootz(cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
bootm_disable_interrupts();
ret = do_bootm_states(cmdtp, flag, argc, argv,
- BOOTM_STATE_OS_FAKE_GO | BOOTM_STATE_OS_GO,
+ BOOTM_STATE_OS_PREP | BOOTM_STATE_OS_FAKE_GO |
+ BOOTM_STATE_OS_GO,
images, 1);
return ret;
--
1.8.3
Still no dice.. v2013.07-rc2 + these 3 + Tom's cmd_bootm.c: Correct
check/return for unsupported sub-command
Tested with the Panda/Wand..
Panda: bootz test:
load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
run mmcargs
bootz ${loadaddr}
Panda: bootm test: (this still works fine..)
load mmc ${mmcdev}:${mmcpart} ${loadaddr} uImage
run mmcargs
bootm ${loadaddr}
U-Boot SPL 2013.07-rc2-4-gb3e6fff-dirty (Jul 03 2013 - 09:33:36)
OMAP4430 ES2.1
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img
U-Boot 2013.07-rc2-4-gb3e6fff-dirty (Jul 03 2013 - 09:33:36)
CPU : OMAP4430 ES2.1
Board: OMAP4 Panda
I2C: ready
DRAM: 1 GiB
MMC: OMAP SD/MMC: 0
Using default environment
In:serial
Out: serial
Err: serial
Net: No ethernet found.
Hit any key to stop autoboot: 0
Panda # load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
reading zImage
3413152 bytes read in 160 ms (20.3 MiB/s)
Panda # run mmcargs
Panda # bootz ${loadaddr}
prefetch abort
pc : [10da7a5c] lr : [bff813f1]
sp : bfefdba0 ip : 7fe00fa8 fp :
r10: bfefe6a0 r9 : 0002 r8 : bfefdf38
r7 : 8000 r6 : 0700 r5 : 10da7a5a r4 : bfefdc18
r3 : bfefdc18 r2 : bfefe6a0 r1 : 0002 r0 : 0100
Flags: NzCv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
resetting ...
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] bootm: Add the missing PREP stage to bootz
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 7b3e459..5749057 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -1758,6 +1758,10 @@ static int bootz_start(cmd_tbl_t *cmdtp, int
flag, int argc,
int ret;
void *zi_start, *zi_end;
+ memset(images, 0, sizeof(bootm_headers_t));
+ boot_start_lmb(images);
+ images-os.os = IH_OS_LINUX;
+
ret = do_bootm_states(cmdtp, flag, argc, argv, BOOTM_STATE_START,
images, 1);
So I'm going to quickly re-test the wand, which is a device tree:
'bootz zImage - ftd boot...
Nope close half way there.. Still broken on Wand (device tree)
Board file boot fine..
bootz zImage
bootz zImage initrd.img
The device tree cases, lock up..
bootz zImage - device.dtb
bootz zImage initrd.img device.dtb
Environment size: 2316/8188 bytes
= load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
4109672 bytes read in 310 ms (12.6 MiB/s)
= load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file}
22150 bytes read in 259 ms (83 KiB/s)
= run mmcargs
= bootz ${loadaddr} - ${fdt_addr}
Starting kernel ...
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] bootm: Add the missing PREP stage to bootz
On Wed, Jul 3, 2013 at 9:46 AM, Robert Nelson robertcnel...@gmail.com wrote:
On Wed, Jul 3, 2013 at 9:12 AM, Simon Glass s...@chromium.org wrote:
In the recent bootm refactor, the PREP stage was missing in the bootz
command. This causes unpredictable behaviour on platforms which need
this stage to operate correctly (e.g. ARM).
Signed-off-by: Simon Glass s...@chromium.org
---
common/cmd_bootm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 401055d..26ed7d8 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -1794,7 +1794,8 @@ int do_bootz(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
bootm_disable_interrupts();
ret = do_bootm_states(cmdtp, flag, argc, argv,
- BOOTM_STATE_OS_FAKE_GO | BOOTM_STATE_OS_GO,
+ BOOTM_STATE_OS_PREP | BOOTM_STATE_OS_FAKE_GO |
+ BOOTM_STATE_OS_GO,
images, 1);
return ret;
--
1.8.3
Still no dice.. v2013.07-rc2 + these 3 + Tom's cmd_bootm.c: Correct
check/return for unsupported sub-command
Tested with the Panda/Wand..
Panda: bootz test:
load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
run mmcargs
bootz ${loadaddr}
Panda: bootm test: (this still works fine..)
load mmc ${mmcdev}:${mmcpart} ${loadaddr} uImage
run mmcargs
bootm ${loadaddr}
U-Boot SPL 2013.07-rc2-4-gb3e6fff-dirty (Jul 03 2013 - 09:33:36)
OMAP4430 ES2.1
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img
U-Boot 2013.07-rc2-4-gb3e6fff-dirty (Jul 03 2013 - 09:33:36)
CPU : OMAP4430 ES2.1
Board: OMAP4 Panda
I2C: ready
DRAM: 1 GiB
MMC: OMAP SD/MMC: 0
Using default environment
In:serial
Out: serial
Err: serial
Net: No ethernet found.
Hit any key to stop autoboot: 0
Panda # load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
reading zImage
3413152 bytes read in 160 ms (20.3 MiB/s)
Panda # run mmcargs
Panda # bootz ${loadaddr}
prefetch abort
pc : [10da7a5c] lr : [bff813f1]
sp : bfefdba0 ip : 7fe00fa8 fp :
r10: bfefe6a0 r9 : 0002 r8 : bfefdf38
r7 : 8000 r6 : 0700 r5 : 10da7a5a r4 : bfefdc18
r3 : bfefdc18 r2 : bfefe6a0 r1 : 0002 r0 : 0100
Flags: NzCv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
resetting ...
Okay, so my quick hack from yesterday now works on top of these 3
patches for the Panda case:
U-Boot SPL 2013.07-rc2-5-g8d900ea-dirty (Jul 03 2013 - 09:52:08)
OMAP4430 ES2.1
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img
U-Boot 2013.07-rc2-5-g8d900ea-dirty (Jul 03 2013 - 09:52:08)
CPU : OMAP4430 ES2.1
Board: OMAP4 Panda
I2C: ready
DRAM: 1 GiB
MMC: OMAP SD/MMC: 0
Using default environment
In:serial
Out: serial
Err: serial
Net: No ethernet found.
Hit any key to stop autoboot: 0
Panda # load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
reading zImage
3413152 bytes read in 159 ms (20.5 MiB/s)
Panda # run mmcargs
Panda # bootz ${loadaddr}
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
[0.00] Booting Linux on physical CPU 0
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.7.10-x12 (root@imx6q-sabrelite-1gb-0)
(gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Sun Jun 9 03:19:23 UTC
2013
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 7b3e459..5749057 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -1758,6 +1758,10 @@ static int bootz_start(cmd_tbl_t *cmdtp, int
flag, int argc,
int ret;
void *zi_start, *zi_end;
+ memset(images, 0, sizeof(bootm_headers_t));
+ boot_start_lmb(images);
+ images-os.os = IH_OS_LINUX;
+
ret = do_bootm_states(cmdtp, flag, argc, argv, BOOTM_STATE_START,
images, 1);
So I'm going to quickly re-test the wand, which is a device tree:
'bootz zImage - ftd boot...
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling
On Mon, Jul 8, 2013 at 9:13 AM, Tom Rini tr...@ti.com wrote:
On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
In the recent bootm refactor, the PREP stage was missing in the bootz
command. This causes unpredictable behaviour.
The use of a local variable means that the reset of cmd_bootm.c does not
in fact use the same image structure, so remove this.
Also manually set the OS type to Linux, since this is the only possibility
at present, and we need to select the right boot function.
Signed-off-by: Simon Glass s...@chromium.org
With the whole series applied, I still see a hang at:
Kernel image @ 0x8020 [ 0x00 - 0x3d44a0 ]
Starting kernel ...
Perhaps something to do with how my DDR is not at 0x0 - 256MiB but
0x8000 - 256MiB ?
Tom, which board is that?
These 5 patches just on top of v2013.07-rc2, the panda (non es) (board
file) works, but Wand (device tree) is still locking up for me...
Panda (Board file boot)
load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
run mmcargs
bootz ${loadaddr}
Panda # load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
reading zImage
3413152 bytes read in 161 ms (20.2 MiB/s)
Panda # run mmcargs
Panda # bootz ${loadaddr}
Kernel image @ 0x8200 [ 0x00 - 0x3414a0 ]
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
[0.00] Booting Linux on physical CPU 0
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
Wandboard (device tree boot)
load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file}
run mmcargs
bootz ${loadaddr} - ${fdt_addr}
Hit any key to stop autoboot: 0
= load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
3464448 bytes read in 249 ms (13.3 MiB/s)
= load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file}
23571 bytes read in 253 ms (90.8 KiB/s)
= run mmcargs
= bootz ${loadaddr} - ${fdt_addr}
Kernel image @ 0x1200 [ 0x00 - 0x34dd00 ]
Starting kernel ...
lockup
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling
On Tue, Jul 9, 2013 at 2:00 PM, Simon Glass s...@chromium.org wrote:
Hi Tom,
On Tue, Jul 9, 2013 at 10:01 AM, Tom Rini tr...@ti.com wrote:
On Mon, Jul 08, 2013 at 10:22:13AM -0400, Tom Rini wrote:
On Mon, Jul 08, 2013 at 09:17:10AM -0500, Robert Nelson wrote:
On Mon, Jul 8, 2013 at 9:13 AM, Tom Rini tr...@ti.com wrote:
On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
In the recent bootm refactor, the PREP stage was missing in the
bootz
command. This causes unpredictable behaviour.
The use of a local variable means that the reset of cmd_bootm.c
does not
in fact use the same image structure, so remove this.
Also manually set the OS type to Linux, since this is the only
possibility
at present, and we need to select the right boot function.
Signed-off-by: Simon Glass s...@chromium.org
With the whole series applied, I still see a hang at:
Kernel image @ 0x8020 [ 0x00 - 0x3d44a0 ]
Starting kernel ...
Perhaps something to do with how my DDR is not at 0x0 - 256MiB but
0x8000 - 256MiB ?
Tom, which board is that?
These 5 patches just on top of v2013.07-rc2, the panda (non es) (board
file) works, but Wand (device tree) is still locking up for me...
Panda (Board file boot)
load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
run mmcargs
bootz ${loadaddr}
Ah-ha! It's an appended dtb vs not problem now. I can boot my
beagelbone with with an appended dtb and bootz, but can't with separate.
OK, the BOOTM_STATE_FINDOTHER state code isn't working since we don't
have the rest of the header bits that the code checks for set. I've
taken a few stabs at reworking things, but it's not working yet. Simon,
do you have any ideas here? I'm starting to wonder if we don't need to
revert things afterall and sort this out post release.
Yes time is running short. I did post two reverts - I wonder if they are
effective for this problem?
Is the appended dtb with bootz the only problem remaining as far as we know?
If so then perhaps we are close.
Close.. It's the 'non appended dtb case'...
bootz ${loadaddr} - ${fdt_addr}
It's almost as if bootz doesn't have the location of the dtb binary in memory...
I will see if I can get a Beaglebone today or failing that I should be able
to try bootz with appeneded dtb on another ARM board.
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling
On Tue, Jul 9, 2013 at 4:19 PM, Tom Rini tr...@ti.com wrote:
On Tue, Jul 09, 2013 at 01:04:58PM -0700, Simon Glass wrote:
Hi Tom,
On Tue, Jul 9, 2013 at 12:05 PM, Tom Rini tr...@ti.com wrote:
On Tue, Jul 09, 2013 at 12:00:00PM -0700, Simon Glass wrote:
Hi Tom,
On Tue, Jul 9, 2013 at 10:01 AM, Tom Rini tr...@ti.com wrote:
On Mon, Jul 08, 2013 at 10:22:13AM -0400, Tom Rini wrote:
On Mon, Jul 08, 2013 at 09:17:10AM -0500, Robert Nelson wrote:
On Mon, Jul 8, 2013 at 9:13 AM, Tom Rini tr...@ti.com wrote:
On Thu, Jul 04, 2013 at 01:26:11PM -0700, Simon Glass wrote:
In the recent bootm refactor, the PREP stage was missing in the
bootz
command. This causes unpredictable behaviour.
The use of a local variable means that the reset of cmd_bootm.c
does not
in fact use the same image structure, so remove this.
Also manually set the OS type to Linux, since this is the only
possibility
at present, and we need to select the right boot function.
Signed-off-by: Simon Glass s...@chromium.org
With the whole series applied, I still see a hang at:
Kernel image @ 0x8020 [ 0x00 - 0x3d44a0 ]
Starting kernel ...
Perhaps something to do with how my DDR is not at 0x0 - 256MiB
but
0x8000 - 256MiB ?
Tom, which board is that?
These 5 patches just on top of v2013.07-rc2, the panda (non es)
(board
file) works, but Wand (device tree) is still locking up for me...
Panda (Board file boot)
load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
run mmcargs
bootz ${loadaddr}
Ah-ha! It's an appended dtb vs not problem now. I can boot my
beagelbone with with an appended dtb and bootz, but can't with
separate.
OK, the BOOTM_STATE_FINDOTHER state code isn't working since we don't
have the rest of the header bits that the code checks for set. I've
taken a few stabs at reworking things, but it's not working yet.
Simon,
do you have any ideas here? I'm starting to wonder if we don't need to
revert things afterall and sort this out post release.
Yes time is running short. I did post two reverts - I wonder if they are
effective for this problem?
Is the appended dtb with bootz the only problem remaining as far as we
know? If so then perhaps we are close.
I will see if I can get a Beaglebone today or failing that I should be
able
to try bootz with appeneded dtb on another ARM board.
I've got a fix locally now, and I'm working on cleaning it up further.
The problem is that BOOTM_STATE_FINDOTHER would never work since we
aren't the right image types, so passed ramdisk and/or dtb didn't
work. Another problem was that bootz was never consuming 'bootz', but
this was OK before. I'll post a patch shortly.
OK great, thanks for looking at this. I wonder if we can collect a set of
different use cases for bootz as a basis for test cases?
Well, what happens on sandbox when you try and boot a kernel? :) bootz
is any of:
kernel, kernel+ramdisk, kernel+ramdisk+fdt, kernel+fdt.
My biggest worry right now is, what might show up broken next? Anyone
out there easily able to boot a netbsd kernel or something?
Yes, I am not really comfortable with this. I will see if I can write some
sandbox tests for the other image types today and post my results. I guess
this bootm code has built up over a long time and it is hard to know all
the ways it is used.
Important, but I really want to see real-world booting in a case or two.
Unfortunately I don't have any ARM boards that work out of the box with
NetBSD.
There 'seems' to be a pre-built freebsd arm port...
https://wiki.freebsd.org/FreeBSD/arm/BeagleBone
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling
Important, but I really want to see real-world booting in a case or two. Unfortunately I don't have any ARM boards that work out of the box with NetBSD. There 'seems' to be a pre-built freebsd arm port... https://wiki.freebsd.org/FreeBSD/arm/BeagleBone NM.. they are using the 'bootelf' command.. https://github.com/kientzle/crochet-freebsd/blob/master/board/BeagleBone/files/uboot_patch05.patch#L108 Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] omap3_beagle: support findfdt and loadfdt for devicetree support
On Thu, Jul 11, 2013 at 4:52 PM, Nishanth Menon n...@ti.com wrote:
For folks not using concatenated device tree with uImage, having
an handy function to find and load device tree is very handy.
So introduce findfdt and loadfdt and run findfdt by default to make
it easier on user scripts.
Signed-off-by: Nishanth Menon n...@ti.com
---
include/configs/omap3_beagle.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index bdeee17..7833208 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -210,6 +210,8 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
loadaddr=0x8020\0 \
rdaddr=0x8100\0 \
+ fdt_high=0x\0 \
+ fdtaddr=0x80f8\0 \
usbtty=cdc_acm\0 \
bootfile=uImage\0 \
ramdisk=ramdisk.gz\0 \
@@ -250,6 +252,19 @@
omapdss.def_disp=${defaultdisplay} \
root=${nandroot} \
rootfstype=${nandrootfstype}\0 \
+ findfdt= \
+ if test $beaglerev = AxBx; then \
+ setenv fdtfile omap3-beagle.dtb; fi; \
+ if test $beaglerev = Cx; then \
+ setenv fdtfile omap3-beagle.dtb; fi; \
+ if test $beaglerev = xMA; then \
+ setenv fdtfile omap3-beagle-xm.dtb; fi; \
+ if test $beaglerev = xMB; then \
+ setenv fdtfile omap3-beagle-xm.dtb; fi; \
There is no need for the xMB variant, as the gpio pins used for
identification where never changed from the xMA when the newer silcon
was used for the xMB (i guess if we look at the omap's es revision, we
could figure out which are xMB's, but right now that isn't done in
u-boot)
+ if test $beaglerev = xMC; then \
+ setenv fdtfile omap3-beagle-xm.dtb; fi; \
+ if test $fdtfile = undefined; then \
+ echo WARNING: Could not determine device tree to
use; fi; \0 \
bootenv=uEnv.txt\0 \
loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenv}\0 \
importbootenv=echo Importing environment from mmc ...; \
@@ -265,6 +280,7 @@
rootfstype=${ramrootfstype}\0 \
loadramdisk=load mmc ${bootpart} ${rdaddr} ${bootdir}/${ramdisk}\0 \
loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0
\
+ loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0 \
mmcboot=echo Booting from mmc ...; \
run mmcargs; \
bootm ${loadaddr}\0 \
@@ -281,6 +297,7 @@
userbutton_nonxm=gpio input 7;\0
/* run userbutton will return 1 (false) if pressed and 0 (true) if not */
#define CONFIG_BOOTCOMMAND \
+ run findfdt; \
mmc dev ${mmcdev}; if mmc rescan; then \
if run userbutton; then \
setenv bootenv uEnv.txt; \
--
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] omap3_beagle: support findfdt and loadfdt for devicetree support
On Thu, Jul 11, 2013 at 5:03 PM, Nishanth Menon n...@ti.com wrote:
On 17:02-20130711, Robert Nelson wrote:
On Thu, Jul 11, 2013 at 4:52 PM, Nishanth Menon n...@ti.com wrote:
For folks not using concatenated device tree with uImage, having
an handy function to find and load device tree is very handy.
So introduce findfdt and loadfdt and run findfdt by default to make
it easier on user scripts.
Signed-off-by: Nishanth Menon n...@ti.com
---
include/configs/omap3_beagle.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/configs/omap3_beagle.h
b/include/configs/omap3_beagle.h
index bdeee17..7833208 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -210,6 +210,8 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
loadaddr=0x8020\0 \
rdaddr=0x8100\0 \
+ fdt_high=0x\0 \
+ fdtaddr=0x80f8\0 \
usbtty=cdc_acm\0 \
bootfile=uImage\0 \
ramdisk=ramdisk.gz\0 \
@@ -250,6 +252,19 @@
omapdss.def_disp=${defaultdisplay} \
root=${nandroot} \
rootfstype=${nandrootfstype}\0 \
+ findfdt= \
+ if test $beaglerev = AxBx; then \
+ setenv fdtfile omap3-beagle.dtb; fi; \
+ if test $beaglerev = Cx; then \
+ setenv fdtfile omap3-beagle.dtb; fi; \
+ if test $beaglerev = xMA; then \
+ setenv fdtfile omap3-beagle-xm.dtb; fi; \
+ if test $beaglerev = xMB; then \
+ setenv fdtfile omap3-beagle-xm.dtb; fi; \
There is no need for the xMB variant, as the gpio pins used for
identification where never changed from the xMA when the newer silcon
was used for the xMB (i guess if we look at the omap's es revision, we
could figure out which are xMB's, but right now that isn't done in
u-boot)
I suppose then the following is ok to do as well?
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index c686f40..6094b0f 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -369,16 +369,6 @@ int misc_init_r(void)
TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
TWL4030_PM_RECEIVER_DEV_GRP_P1);
break;
- case REVISION_XM_B:
- printf(Beagle xM Rev B\n);
- setenv(beaglerev, xMB);
- MUX_BEAGLE_XM();
- /* Set VAUX2 to 1.8V for EHCI PHY */
- twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VAUX2_DEDICATED,
- TWL4030_PM_RECEIVER_VAUX2_VSEL_18,
- TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
- TWL4030_PM_RECEIVER_DEV_GRP_P1);
- break;
case REVISION_XM_C:
printf(Beagle xM Rev C\n);
setenv(beaglerev, xMC);
Correct, as a cleanup we can nuke that xMB section..
For some bike shed paining we could rename:
Beagle xM Rev A - Beagle xM Rev A/B
Above that too. ;)
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] omap3_beagle: support findfdt and loadfdt for devicetree support
On Thu, Jul 11, 2013 at 5:17 PM, Nishanth Menon n...@ti.com wrote:
On 17:05-20130711, Robert Nelson wrote:
On Thu, Jul 11, 2013 at 5:03 PM, Nishanth Menon n...@ti.com wrote:
On 17:02-20130711, Robert Nelson wrote:
On Thu, Jul 11, 2013 at 4:52 PM, Nishanth Menon n...@ti.com wrote:
For folks not using concatenated device tree with uImage, having
an handy function to find and load device tree is very handy.
So introduce findfdt and loadfdt and run findfdt by default to make
it easier on user scripts.
Signed-off-by: Nishanth Menon n...@ti.com
---
include/configs/omap3_beagle.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/configs/omap3_beagle.h
b/include/configs/omap3_beagle.h
index bdeee17..7833208 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -210,6 +210,8 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
loadaddr=0x8020\0 \
rdaddr=0x8100\0 \
+ fdt_high=0x\0 \
+ fdtaddr=0x80f8\0 \
usbtty=cdc_acm\0 \
bootfile=uImage\0 \
ramdisk=ramdisk.gz\0 \
@@ -250,6 +252,19 @@
omapdss.def_disp=${defaultdisplay} \
root=${nandroot} \
rootfstype=${nandrootfstype}\0 \
+ findfdt= \
+ if test $beaglerev = AxBx; then \
+ setenv fdtfile omap3-beagle.dtb; fi; \
+ if test $beaglerev = Cx; then \
+ setenv fdtfile omap3-beagle.dtb; fi; \
+ if test $beaglerev = xMA; then \
+ setenv fdtfile omap3-beagle-xm.dtb; fi; \
+ if test $beaglerev = xMB; then \
+ setenv fdtfile omap3-beagle-xm.dtb; fi; \
There is no need for the xMB variant, as the gpio pins used for
identification where never changed from the xMA when the newer silcon
was used for the xMB (i guess if we look at the omap's es revision, we
could figure out which are xMB's, but right now that isn't done in
u-boot)
I suppose then the following is ok to do as well?
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index c686f40..6094b0f 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -369,16 +369,6 @@ int misc_init_r(void)
TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
TWL4030_PM_RECEIVER_DEV_GRP_P1);
break;
- case REVISION_XM_B:
- printf(Beagle xM Rev B\n);
- setenv(beaglerev, xMB);
- MUX_BEAGLE_XM();
- /* Set VAUX2 to 1.8V for EHCI PHY */
-
twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VAUX2_DEDICATED,
- TWL4030_PM_RECEIVER_VAUX2_VSEL_18,
- TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
- TWL4030_PM_RECEIVER_DEV_GRP_P1);
- break;
case REVISION_XM_C:
printf(Beagle xM Rev C\n);
setenv(beaglerev, xMC);
Correct, as a cleanup we can nuke that xMB section..
For some bike shed paining we could rename:
Beagle xM Rev A - Beagle xM Rev A/B
Above that too. ;)
OK - I suspect and am not sure how dvi_pup will get handled in the
resultant diff, What do folks think of the following?
A quick review of all my old xM schematics i have access to and the
ones on https://github.com/CircuitCo/
For the dvi_pup function
GPIO_170 was only used on the pre-production xM's P8/P9, i doubt any
of them still operate (mine died)..
It was then switched to GPIO_129 for the xMA, however there where MMC
issues, so it was changed for xMA1 (and thus xMA2)
notes, top of this:
https://github.com/CircuitCo/BeagleBoard-xM-RevC/blob/master/BeagleBoard-xM_revC_SCH.pdf
TPS_GPIO_2: was then used on xMA3 - and all later generations...
So also looking at:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-omap2/board-omap3beagle.c#n161
Looks like the original beagle needs GPIO_170..
So I'd just set GPIO_170 for:
case REVISION_AXBX:
case REVISION_CX:
case REVISION_C4:
and ignore all the pre-production xM P8/P8's/xMA..
Side note, I think 'first' customers just got the xMA2 and newer.. As
i was one of the first, and it's still running downstairs..
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] omap3_beagle: support findfdt and loadfdt for devicetree support
On Thu, Jul 11, 2013 at 11:06 PM, Nishanth Menon n...@ti.com wrote:
On 18:17-20130711, Robert Nelson wrote:
On Thu, Jul 11, 2013 at 5:17 PM, Nishanth Menon n...@ti.com wrote:
On 17:05-20130711, Robert Nelson wrote:
On Thu, Jul 11, 2013 at 5:03 PM, Nishanth Menon n...@ti.com wrote:
On 17:02-20130711, Robert Nelson wrote:
On Thu, Jul 11, 2013 at 4:52 PM, Nishanth Menon n...@ti.com wrote:
For folks not using concatenated device tree with uImage, having
an handy function to find and load device tree is very handy.
So introduce findfdt and loadfdt and run findfdt by default to make
it easier on user scripts.
Signed-off-by: Nishanth Menon n...@ti.com
---
include/configs/omap3_beagle.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/configs/omap3_beagle.h
b/include/configs/omap3_beagle.h
index bdeee17..7833208 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -210,6 +210,8 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
loadaddr=0x8020\0 \
rdaddr=0x8100\0 \
+ fdt_high=0x\0 \
+ fdtaddr=0x80f8\0 \
usbtty=cdc_acm\0 \
bootfile=uImage\0 \
ramdisk=ramdisk.gz\0 \
@@ -250,6 +252,19 @@
omapdss.def_disp=${defaultdisplay} \
root=${nandroot} \
rootfstype=${nandrootfstype}\0 \
+ findfdt= \
+ if test $beaglerev = AxBx; then \
+ setenv fdtfile omap3-beagle.dtb; fi; \
+ if test $beaglerev = Cx; then \
+ setenv fdtfile omap3-beagle.dtb; fi; \
+ if test $beaglerev = xMA; then \
+ setenv fdtfile omap3-beagle-xm.dtb; fi; \
+ if test $beaglerev = xMB; then \
+ setenv fdtfile omap3-beagle-xm.dtb; fi; \
There is no need for the xMB variant, as the gpio pins used for
identification where never changed from the xMA when the newer silcon
was used for the xMB (i guess if we look at the omap's es revision, we
could figure out which are xMB's, but right now that isn't done in
u-boot)
I suppose then the following is ok to do as well?
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index c686f40..6094b0f 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -369,16 +369,6 @@ int misc_init_r(void)
TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
TWL4030_PM_RECEIVER_DEV_GRP_P1);
break;
- case REVISION_XM_B:
- printf(Beagle xM Rev B\n);
- setenv(beaglerev, xMB);
- MUX_BEAGLE_XM();
- /* Set VAUX2 to 1.8V for EHCI PHY */
-
twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VAUX2_DEDICATED,
-
TWL4030_PM_RECEIVER_VAUX2_VSEL_18,
-
TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
- TWL4030_PM_RECEIVER_DEV_GRP_P1);
- break;
case REVISION_XM_C:
printf(Beagle xM Rev C\n);
setenv(beaglerev, xMC);
Correct, as a cleanup we can nuke that xMB section..
For some bike shed paining we could rename:
Beagle xM Rev A - Beagle xM Rev A/B
Above that too. ;)
OK - I suspect and am not sure how dvi_pup will get handled in the
resultant diff, What do folks think of the following?
A quick review of all my old xM schematics i have access to and the
ones on https://github.com/CircuitCo/
For the dvi_pup function
GPIO_170 was only used on the pre-production xM's P8/P9, i doubt any
of them still operate (mine died)..
It was then switched to GPIO_129 for the xMA, however there where MMC
issues, so it was changed for xMA1 (and thus xMA2)
notes, top of this:
https://github.com/CircuitCo/BeagleBoard-xM-RevC/blob/master/BeagleBoard-xM_revC_SCH.pdf
TPS_GPIO_2: was then used on xMA3 - and all later generations...
So also looking at:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-omap2/board-omap3beagle.c#n161
Looks like the original beagle needs GPIO_170..
So I'd just set GPIO_170 for:
case REVISION_AXBX:
case REVISION_CX:
case REVISION_C4:
and ignore all the pre-production xM P8/P8's/xMA..
Side note, I think 'first' customers just got the xMA2 and newer.. As
i was one of the first, and it's still running downstairs..
ok, here is how the code looks like with the V2 of my series:
Do we just default to none for XM_AB for dvi_pup?
static void beagle_dvi_pup(void)
{
uchar val;
switch (get_board_revision()) {
case REVISION_AXBX
Re: [U-Boot] [PATCH] wandboard: add pxe support, set default boot command like highbank
On Wed, Jul 31, 2013 at 6:01 PM, Rob Herring robherri...@gmail.com wrote:
Dennis,
On Thu, Jul 25, 2013 at 4:13 PM, dgilm...@fedoraproject.org wrote:
From: Dennis Gilmore den...@ausil.us
Signed-off-by: Dennis Gilmore den...@ausil.us
---
include/configs/wandboard.h | 42 +++---
1 file changed, 39 insertions(+), 3 deletions(-)
diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
index ee6bf21..a5052c5 100644
--- a/include/configs/wandboard.h
+++ b/include/configs/wandboard.h
@@ -58,6 +58,8 @@
#define CONFIG_LOADADDR0x1200
#define CONFIG_SYS_TEXT_BASE 0x1780
+#define CONFIG_SUPPORT_RAW_INITRD
+
/* MMC Configuration */
#define CONFIG_FSL_ESDHC
#define CONFIG_FSL_USDHC
@@ -72,6 +74,14 @@
#define CONFIG_CMD_FAT
#define CONFIG_DOS_PARTITION
+/* PXE support */
+#define CONFIG_BOOTP_PXE
+#define CONFIG_BOOTP_PXE_CLIENTARCH 0x100
+#define CONFIG_BOOTP_VCI_STRING U-boot.armv7.wandboard
+#define CONFIG_CMD_PXE
+#define CONFIG_MENU
+
+
/* Ethernet Configuration */
#define CONFIG_CMD_PING
#define CONFIG_CMD_DHCP
@@ -117,7 +127,32 @@
initrd_high=0x\0 \
fdt_file= CONFIG_DEFAULT_FDT_FILE \0 \
fdt_addr=0x1100\0 \
+ pxefile_addr_r=0x1200\0 \
+ kernel_addr_r=0x1300\0 \
+ ramdisk_addr_r=0x3200\0 \
+ fdt_addr_r=0x1100\0 \
boot_fdt=try\0 \
+ bootcmd_setup=mmc rescan\0 \
+ bootcmd_pxe=setenv bootfile \\ ;dhcp; pxe get; pxe boot\0 \
+ bootcmd_disk_scr=ext2load ${boot_ifc} ${bootdevice} ${scr_addr_r}
boot.scr source ${scr_addr_r}\0 \
+ bootcmd_disk_sysboot1=setenv bootfile /boot/extlinux/extlinux.conf;
sysboot ${boot_ifc} ${bootdevice} ext2\0 \
+ bootcmd_disk_sysboot2=setenv bootfile /extlinux/extlinux.conf;
sysboot ${boot_ifc} ${bootdevice} ext2\0 \
+ bootcmd_disk_uenv=ext2load ${boot_ifc} ${bootdevice} ${uenv_addr_r}
uEnv.txt; env import -t ${uenv_addr_r} ${filesize}; run bootcmd_uenv\0 \
+ bootcmd_disk_kernel=ext2load ${boot_ifc} ${bootdevice}
${kernel_addr_r} vmlinuz ext2load ${boot_ifc} ${bootdevice}
${ramdisk_addr_r} initrd.img bootz ${kernel_addr_r}
${ramdisk_addr_r}:${filesize} ${fdt_addr}\0 \
+ bootcmd_disk=run bootcmd_disk_sysboot1; run bootcmd_disk_sysboot2;
run bootcmd_disk_uenv; run bootcmd_disk_scr; run bootcmd_disk_kernel\0 \
+ bootcmd_sata=setenv boot_ifc scsi; scsi scan run bootcmd_disk\0
\
+ bootcmd_mmc=setenv boot_ifc mmc; mmc rescan run bootcmd_disk\0 \
+ bootcmd_default=run bootcmd_mmc; run bootcmd_sata; run
bootcmd_pxe\0 \
I really would not like to see this propagated to another board. I've
completely redone the env for highbank based on what Stephen Warren
did for Tegra. It would be good to come up with a common version
rather than duplicating for each board. This is now what the env looks
like for highbank in current firmware:
kernel_boot=echo Trying kernel...; ${fs}load ${devtype} ${devnum}
${kernel_addr_r} ${prefix}vmlinuz ${fs}load ${devtype} ${devnum}
${ramdisk_addr_r} ${prefix}initrd.img bootz ${kernel_addr_r}
${ramdisk_addr_r}:${filesize} ${fdt_addr}
script_boot=echo Trying script images...; for script in
${boot_scripts}; do ${fs}load ${devtype} ${devnum} ${script_addr}
${prefix}${script} echo Executing ${prefix}${script}... source
${script_addr}; done;
env_boot=echo Trying environment file...; ${fs}load ${devtype}
${devnum} ${script_addr} ${prefix}uEnv.txt Executing
${prefix}uEnv.txt... env import -t ${script_addr} ${filesize}};
Guys, this is just silly.. Your using both uEnv.txt/boot.scr scripts
by default, which you could use to hide all this extra stuff in a
text file on the boot drive, that way mainline u-boot doesn't have to
be patched for every little change. ;)
I know it's bikeshedding, but most boards can be converted to just:
#define CONFIG_BOOTCOMMAND \
mmc dev ${mmcdev}; \
if mmc rescan; then \
echo SD/MMC found on device ${mmcdev}; \
if run loadbootenv; then \
run importbootenv; \
fi; \
if test -n $uenvcmd; then \
echo Running uenvcmd ...; \
run uenvcmd; \
fi; \
if run loadsomefailsafedefault; then \
run mmcboot; \
fi; \
fi;
#endif
where:
loadbootenv=load mmc ${mmcdev}:${mmcpart} ${loadaddr} uEnv.txt\0 \
importbootenv=echo Importing environment from mmc (uEnv.txt)...; \
env import -t ${loadaddr} ${filesize}\0 \
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: omap3: Implement dpll5 (HSUSB clk) workaround for OMAP36xx/AM/DM37xx according to errata sprz318e.
On Fri, Aug 16, 2013 at 9:34 AM, Peter A. Bigot p...@pabigot.com wrote: On 08/16/2013 08:38 AM, Tom Rini wrote: On Wed, Aug 14, 2013 at 09:53:16PM -0500, Peter A. Bigot wrote: On 07/09/2013 02:43 AM, Naumann Andreas wrote: In chapter 'Advisory 2.1 USB Host Clock Drift Causes USB Spec Non-compliance in Certain Configurations' of the TI Errata it is recommended to use certain div/mult values for the DPLL5 clock setup. So far u-boot used the old 34xx values, so I added the errata recommended values specificly for 36xx init only. Also, the FSEL registers exist no longer, so removed them from init. Tested this on a AM3703 board with 19.2MHz oscillator, which previously couldnt lock the dpll5 (kernel complained). As a consequence the EHCI USB port wasnt usable in U-Boot and kernel. With this patch, kernel panics disappear and USB working fine in u-boot and kernel. Signed-off-by: Andreas Naumann anaum...@ultratronik.de While this patch works with Linux that has been patched for this erratum, it will cause problems with some unpatched versions of Linux. Right. So Linux also needs to be patched for the erratum. Yes. My point was that if you update u-boot alone, then try to use it to boot an unpatched Linux that assumes CM_CLKSEL5_PLL has its power-on value, USB will not work. I think it's dangerous to assume that the mixture of an unpatched Linux with a patched u-boot will never occur, and the cause of the failure that results is pretty subtle. So whatever gets merged would be safer if it restored the default setting of CM_CLKSEL5_PLL prior to handing off control to Linux. Agree, we should not apply this, till we also have an 'approved' patch for mainline linux posted. Right now we have a set of kernel hacks, but no agreed on method as the kernel maintainer did not have a board that suffered from the errata.. Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: omap3: Implement dpll5 (HSUSB clk) workaround for OMAP36xx/AM/DM37xx according to errata sprz318e.
On Fri, Aug 16, 2013 at 10:07 AM, Robert Nelson robertcnel...@gmail.com wrote: On Fri, Aug 16, 2013 at 9:34 AM, Peter A. Bigot p...@pabigot.com wrote: On 08/16/2013 08:38 AM, Tom Rini wrote: On Wed, Aug 14, 2013 at 09:53:16PM -0500, Peter A. Bigot wrote: On 07/09/2013 02:43 AM, Naumann Andreas wrote: In chapter 'Advisory 2.1 USB Host Clock Drift Causes USB Spec Non-compliance in Certain Configurations' of the TI Errata it is recommended to use certain div/mult values for the DPLL5 clock setup. So far u-boot used the old 34xx values, so I added the errata recommended values specificly for 36xx init only. Also, the FSEL registers exist no longer, so removed them from init. Tested this on a AM3703 board with 19.2MHz oscillator, which previously couldnt lock the dpll5 (kernel complained). As a consequence the EHCI USB port wasnt usable in U-Boot and kernel. With this patch, kernel panics disappear and USB working fine in u-boot and kernel. Signed-off-by: Andreas Naumann anaum...@ultratronik.de While this patch works with Linux that has been patched for this erratum, it will cause problems with some unpatched versions of Linux. Right. So Linux also needs to be patched for the erratum. Yes. My point was that if you update u-boot alone, then try to use it to boot an unpatched Linux that assumes CM_CLKSEL5_PLL has its power-on value, USB will not work. I think it's dangerous to assume that the mixture of an unpatched Linux with a patched u-boot will never occur, and the cause of the failure that results is pretty subtle. So whatever gets merged would be safer if it restored the default setting of CM_CLKSEL5_PLL prior to handing off control to Linux. Agree, we should not apply this, till we also have an 'approved' patch for mainline linux posted. Right now we have a set of kernel hacks, but no agreed on method as the kernel maintainer did not have a board that suffered from the errata.. btw: here's a version that seems to work on v3.11-rc5: https://raw.github.com/RobertCNelson/armv7-multiplatform/v3.11.x/patches/omap_sprz319_erratum_v2.1/0001-hack-omap-clockk-dpll5-apply-sprz319e-2.1-erratum-kernel-3.11-rc2.patch Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: omap3: Implement dpll5 (HSUSB clk) workaround for OMAP36xx/AM/DM37xx according to errata sprz318e.
On Tue, Aug 20, 2013 at 5:15 AM, Andreas Naumann d...@andin.de wrote: Hi Roger, What are the symptoms you see when this issue triggers? The symptoms are erroneous USB transaction, seen with a USB port analyzer. These only sometimes (not always) stall the USB communication, e.g. a USB mass storage device cant be read any longer. What is the test case to trigger the error? Is it just running any USB I/O for long enough time? Our scenario to reproduce was rebooting a warmed up board (either let it run for 5min or heat up in climate chamber). However, the beagle probably uses a 26 MHz crystal oscillator (our board uses 19.2MHz), so the PLL5 dividers may be set in a way that the problem never occurs. The xM uses a 26Mhz, but the errata still applies, as a number of customer boards do show the issue.. http://www.ti.com/lit/er/sprz319e/sprz319e.pdf page 113 I have a beagle-xm (DM3730 ES1.2) with me and would like to reproduce the error. Roger, this only seems to effect a small number of xM's, as it seems to vary on pll drift. So if your xM is fine, i do have a spare xM C, that pretty reliably shows the issue after transferring a large amount of data over the usb port... I had traded a good xM with a customer such that i could keep re-basing our out of tree dpll5 tweak.. Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] beaglxm/bootz: kernel boot fail due to align err: cache handling issues?
On Fri, Aug 23, 2013 at 9:21 AM, Nishanth Menon n...@ti.com wrote:
Hi,
Noticed an interesting behavior where adding a dcache flush kernel boot
fail due to unaligned-accesses seems to go away.
Full details: http://pastebin.com/kVBRWsbE
Without dcache flush being added to my uenvcmd:
Kernel image @ 0x8020 [ 0x00 - 0x3e2690 ]
data abort
MAYBE you should read doc/README.arm-unaligned-accesses
pc : [9ff6f6b4] lr : [9ff6ef6c]
sp : 9fefaaf0 ip : 9fefe8ec fp :
r10: 9ffa6544 r9 : 9ffa5e5c r8 : 9fefaf30
r7 : 0f80 r6 : 9ffa6544 r5 : 9ffa65b0 r4 : 9ffa65b4
r3 : 0049 r2 : 0010 r1 : r0 : 0f80
Flags: nZCv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
With dcache flush being added to my uenvcmd: complete boot
I think something of the form was highlighted here:
http://marc.info/?l=u-bootm=137276534624656w=2
Not sure if there was any conclusion to the effect.
There may still be an underline bug, but the bootz ${loadaddr} issue
i showed in that post was fixed very late in the v2013.07, i forget
the commit, it may have been a day or two right before.
So looking at your pastebin.com log: U-Boot
2013.07-rc2-00044-g1d28a6a it might be worthwhile to re-test with
v2013.07 final, specially since your using bootz...
(I've already been shipping a bootz enabled u-boot v2013.07 for the
beagle-xm to end users)..
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v11 2/2] Enable btrfs support in mx53loco config
On Tue, Apr 2, 2013 at 9:17 AM, Adnan Ali adnan@codethink.co.uk wrote:
Enable btrfs support in mx53loco config
Signed-off-by: Adnan Ali adnan@codethink.co.uk
---
include/configs/mx53loco.h |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/configs/mx53loco.h b/include/configs/mx53loco.h
index a4b610f..62e9a76 100644
--- a/include/configs/mx53loco.h
+++ b/include/configs/mx53loco.h
@@ -56,6 +56,8 @@
#define CONFIG_GENERIC_MMC
#define CONFIG_CMD_FAT
#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_BTR
+#define CONFIG_CMD_FS_GENERIC
#define CONFIG_DOS_PARTITION
/* Eth Configs */
@@ -128,7 +130,7 @@
mmcroot=/dev/mmcblk0p3 rw rootwait\0 \
mmcargs=setenv bootargs console=ttymxc0,${baudrate}
root=${mmcroot}\0 \
loadbootscript= \
- fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0 \
+ btrload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0 \
Instead of changing this to btrload for everyone, wouldn't it make
more sense to use the generic load command? As your already setting
CONFIG_CMD_FS_GENERIC
Once you do that, you might as well also enable:
#define CONFIG_CMD_EXT4
bootscript=echo Running bootscript from mmc ...; \
source\0 \
loaduimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0
\
--
1.7.9.5
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v11 2/2] Enable btrfs support in mx53loco config
On Tue, Apr 2, 2013 at 10:38 AM, Adnan Ali adnan@codethink.co.uk wrote:
On 02/04/13 16:19, Robert Nelson wrote:
On Tue, Apr 2, 2013 at 9:17 AM, Adnan Ali adnan@codethink.co.uk
wrote:
Enable btrfs support in mx53loco config
Signed-off-by: Adnan Ali adnan@codethink.co.uk
---
include/configs/mx53loco.h |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/configs/mx53loco.h b/include/configs/mx53loco.h
index a4b610f..62e9a76 100644
--- a/include/configs/mx53loco.h
+++ b/include/configs/mx53loco.h
@@ -56,6 +56,8 @@
#define CONFIG_GENERIC_MMC
#define CONFIG_CMD_FAT
#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_BTR
+#define CONFIG_CMD_FS_GENERIC
#define CONFIG_DOS_PARTITION
/* Eth Configs */
@@ -128,7 +130,7 @@
mmcroot=/dev/mmcblk0p3 rw rootwait\0 \
mmcargs=setenv bootargs console=ttymxc0,${baudrate}
root=${mmcroot}\0 \
loadbootscript= \
- fatload mmc ${mmcdev}:${mmcpart} ${loadaddr}
${script};\0 \
+ btrload mmc ${mmcdev}:${mmcpart} ${loadaddr}
${script};\0 \
Instead of changing this to btrload for everyone, wouldn't it make
more sense to use the generic load command? As your already setting
CONFIG_CMD_FS_GENERIC
Well idea of adding that was to enable btrfs and to show its associated
commands.
Yes you can use generic 'load' command. Defaults was using fatload so i
change
it to btrload.
That's perfectly fine for showing the btrfs command's as an RFC patch,
but if this was heading for mainline as-is, it would be nice to use
the load command instead of moving from one partition format that's
been default for a couple years to a new format with less users. (not
that I don't like the btrfs format. ;) as i've been running it on a
few omap boards for a couple years now..)
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mx53loco hangs on 2012.07
On Tue, Jul 31, 2012 at 1:25 PM, Fabio Estevam feste...@gmail.com wrote: Hi, Just tried 2012.07 on a mx53loco and this is what I got: U-Boot 2012.07 (Jul 31 2012 - 15:21:51) Board: MX53 LOCO I2C: ready DRAM: 1 GiB WARNING: Caches not enabled CPU: Freescale i.MX53 family rev2.0 at 1000 MHz Reset cause: POR MMC: FSL_SDHC: 0, FSL_SDHC: 1 (Hangs here) Have anyone else seen this? I will start debugging it, and any suggestions are welcome. It's actually not hanging up, if you have a boot script, it seems to runs that just fine, but it will not print it to the serial terminal.. This would seem to redirect the prompt the lcd? http://git.denx.de/?p=u-boot.git;a=commit;h=f714b0a911e24cc733553f02b30d508212f339fe before that commit i was using 4398d55 with no issues.. mx53loco-r U-Boot 2012.07-7-g7395c76 (Jul 31 2012 - 11:29:17) Board: MX53 LOCO I2C: ready DRAM: 1 GiB WARNING: Caches not enabled CPU: Freescale i.MX53 family rev2.1 at 1000 MHz Reset cause: WDOG MMC: FSL_SDHC: 0, FSL_SDHC: 1 *** Warning - bad CRC, using default environment Uncompressing Linux... done, booting the kernel Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx53loco: Fix PMIC name
On Tue, Dec 11, 2012 at 10:36 AM, Fabio Estevam
fabio.este...@freescale.com wrote:
commit c73368150 (pmic: Extend PMIC framework to support multiple instances
of PMIC devices) has incorrectly passed the PMIC name under the FSL PMIC case.
Fix that by passing FSL_PMIC as the parameter of pmic_get.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
board/freescale/mx53loco/mx53loco.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/freescale/mx53loco/mx53loco.c
b/board/freescale/mx53loco/mx53loco.c
index 81c511c..2c8cb7a 100644
--- a/board/freescale/mx53loco/mx53loco.c
+++ b/board/freescale/mx53loco/mx53loco.c
@@ -374,7 +374,7 @@ static int power_init(void)
if (retval)
return retval;
- p = pmic_get(DIALOG_PMIC);
+ p = pmic_get(FSL_PMIC);
if (!p)
return -ENODEV;
--
1.7.9.5
Hi Fabio,
It looks like we need one more fixup after commit c73368150 on the
first run/older (non R, Dialog, bug wired extra Capacitor) version of
this board.. Do you happen to have any in your lab?
U-Boot 2013.01-rc2-dirty (Dec 20 2012 - 15:55:01)
Board: MX53 LOCO
I2C: ready
DRAM: 1 GiB
pmic_alloc: No available memory for allocation!
pmic_init: POWER allocation error!
CPU: Freescale i.MX53 family rev2.0 at 800 MHz
Reset cause: POR
MMC: FSL_SDHC: 0, FSL_SDHC: 1
*** Warning - bad CRC, using default environment
(and it just keeps on resetting)
It looks to be failing after calloc...
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/power/power_core.c#l100
100 p = calloc(sizeof(*p), 1);
101 if (!p) {
102 printf(%s: No available memory for
allocation!\n, __func__);
103 return NULL;
104 }
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx53loco: Fix PMIC name
Hi Fabio,
On Wed, Dec 26, 2012 at 9:21 AM, Fabio Estevam feste...@gmail.com wrote:
Robert,
On Wed, Dec 26, 2012 at 1:07 PM, Fabio Estevam feste...@gmail.com wrote:
On Wed, Dec 26, 2012 at 1:02 PM, Fabio Estevam feste...@gmail.com wrote:
With the new PMIC framework: is it safe to call the PMIC API from
board_init function?
Calling it from board_late_init fixes the issue for me.
Will send the patch soon.
Can you try the patch below?
Thanks for taking a look at this..
board/freescale/mx53loco/mx53loco.c | 10 --
include/configs/mx53loco.h |1 +
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/board/freescale/mx53loco/mx53loco.c
b/board/freescale/mx53loco/mx53loco.c
index 2c8cb7a..63a4f8b 100644
--- a/board/freescale/mx53loco/mx53loco.c
+++ b/board/freescale/mx53loco/mx53loco.c
@@ -462,12 +462,18 @@ int board_init(void)
mxc_set_sata_internal_clock();
setup_iomux_i2c();
+
+ lcd_enable();
+
+ return 0;
+}
+
+int board_late_init(void)
+{
if (!power_init())
clock_1GHz();
print_cpuinfo();
- lcd_enable();
-
return 0;
}
diff --git a/include/configs/mx53loco.h b/include/configs/mx53loco.h
index e30502b..c4181bd 100644
--- a/include/configs/mx53loco.h
+++ b/include/configs/mx53loco.h
@@ -39,6 +39,7 @@
#define CONFIG_SYS_MALLOC_LEN (10 * 1024 * 1024)
#define CONFIG_BOARD_EARLY_INIT_F
+#define CONFIG_BOARD_LATE_INIT
Ah, i was missing this when heading down the board_late_init road on friday..
#define CONFIG_MXC_GPIO
#define CONFIG_REVISION_TAG
--
1.7.9.5
It boots now, but I get resets now:
U-Boot 2013.01-rc2-00172-gf8cfcf1-dirty (Dec 26 2012 - 13:13:28)
Board: MX53 LOCO
I2C: ready
DRAM: 1 GiB
MMC: FSL_SDHC: 0, FSL_SDHC: 1
In:serial
Out: serial
Err: serial
CPU: Freescale i.MX53 family rev2.1 at 1000 MHz
Reset cause: WDOG
Net: FEC
Warning: FEC using MAC address from net device
Interesting, I'm still only getting this far on the old Dialog board..
U-Boot 2013.01-rc2-00173-gd781d95-dirty (Dec 26 2012 - 09:42:43)
Board: MX53 LOCO
I2C: ready
DRAM: 1 GiB
I'm going to start printf'ing:
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/power/power_dialog.c
as we aren't getting the memory error, so it should be atleast past
that...
Hit any key to stop autoboot: 0
data abort
MAYBE you should read doc/README.arm-unaligned-accesses
pc : [aff72220] lr : [aff721fc]
sp : af565e20 ip : af566918 fp :
r10: 0003 r9 : affabb5b r8 : af565f58
r7 : r6 : 36747fff r5 : af5668e8 r4 : 36747fff
r3 : af5668ec r2 : af5668eb r1 : r0 : af5668e8
Flags: NzcV IRQs off FIQs off Mode SVC_32
Resetting CPU ...
resetting ...
I've reverted this just to double check (no change for me...):
http://git.denx.de/?p=u-boot.git;a=commit;h=28e5ac2d974547bde0c72aa0c1d66fd22c6ef3ad
U-Boot 2013.01-rc2-00172-gf8cfcf1-dirty (Dec 26 2012 - 13:13:28)
Board: MX53 LOCO
I2C: ready
DRAM: 1 GiB
but it looks like a separate issue?
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx53loco: Fix PMIC name
On Wed, Dec 26, 2012 at 9:54 AM, Fabio Estevam feste...@gmail.com wrote: On Wed, Dec 26, 2012 at 1:51 PM, Robert Nelson robertcnel...@gmail.com wrote: Interesting, I'm still only getting this far on the old Dialog board.. U-Boot 2013.01-rc2-00173-gd781d95-dirty (Dec 26 2012 - 09:42:43) Board: MX53 LOCO I2C: ready DRAM: 1 GiB I tested with 2 mx53loco boards here: one with FSL PMIC and one with Dialog. I recall we had 2 versions of boards with Dialog PMIC, but at least with the one I have here it boots fine now after applying the patch I just sent. Okay, good to hear it works with the Dialog PMIC you have, as that should cover a majority of the Dialog based boards customers actually have. As the one I have here was one of the very first ones and i know something changed later in production... Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx53loco: Fix PMIC name
On Wed, Dec 26, 2012 at 10:50 AM, Fabio Estevam feste...@gmail.com wrote: On Wed, Dec 26, 2012 at 2:04 PM, Robert Nelson robertcnel...@gmail.com wrote: Okay, good to hear it works with the Dialog PMIC you have, as that should cover a majority of the Dialog based boards customers actually have. As the one I have here was one of the very first ones and i know something changed later in production... Yes, but not happy to see a regression with your board and also the resets that started to happen now. I'll keep debugging it here, did reverting this commit, help with the resets? http://git.denx.de/?p=u-boot.git;a=commit;h=28e5ac2d974547bde0c72aa0c1d66fd22c6ef3ad Which toolchain did you use? I am using gcc 4.6.3. If you have a chance to try the same toolchain to make sure we got the same results, that would be nice. That build was with Linaro's 4.7.1 2012.04 release, from: https://launchpad.net/linaro-toolchain-binaries/ ./arm-linux-gnueabi-gcc --version arm-linux-gnueabi-gcc (crosstool-NG linaro-1.13.1-2012.04-20120426 - Linaro GCC 2012.04) 4.7.1 20120402 (prerelease) Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx53loco: Fix PMIC name
On Wed, Dec 26, 2012 at 11:21 AM, Fabio Estevam feste...@gmail.com wrote: On Wed, Dec 26, 2012 at 3:08 PM, Robert Nelson robertcnel...@gmail.com wrote: I'll keep debugging it here, did reverting this commit, help with the resets? http://git.denx.de/?p=u-boot.git;a=commit;h=28e5ac2d974547bde0c72aa0c1d66fd22c6ef3ad Tried reverting it and still see the data-aborts. I am also testing on my mx53loco board with the mc34708 pmic and I see that it hangs on boot about 10% of the attempts: U-Boot 2013.01-rc2-00172-gf8cfcf1-dirty (Dec 26 2012 - 15:15:27) Board: MX53 LOCO I2C: ready DRAM: 1 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 This did not happen prior to commit c73368150 (pmic: Extend PMIC framework to support multiple instances of PMIC devices). Okay, now we are on the same page, upgraded to: arm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1-4.7-2012.12-20121214 - Linaro GCC 2012.12) 4.7.3 20121205 (prerelease).. With your Dialog patch, it is properly setting 1Ghz, and just keeps rebooting.. :) U-Boot 2013.01-rc2-00173-ga0d04f3 (Dec 26 2012 - 11:47:34) Board: MX53 LOCO I2C: ready DRAM: 1 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial CPU: Freescale i.MX53 family rev2.0 at 1000 MHz Reset cause: WDOG Net: FEC Warning: FEC using MAC address from net device Hit any key to stop autoboot: 0 data abort MAYBE you should read doc/README.arm-unaligned-accesses pc : [aff72250] lr : [aff72228] sp : af565d68 ip : fff4 fp : r10: 0003 r9 : affab8d9 r8 : af565f58 r7 : r6 : e5bc345d r5 : af6df330 r4 : e5bc345d r3 : af6df334 r2 : af6df333 r1 : r0 : af6df330 Flags: nzCv IRQs off FIQs off Mode SVC_32 Resetting CPU ... resetting ... U-Boot 2013.01-rc2-00173-ga0d04f3 (Dec 26 2012 - 11:47:34) Board: MX53 LOCO I2C: ready DRAM: 1 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial CPU: Freescale i.MX53 family rev2.0 at 1000 MHz Reset cause: WDOG Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx53loco: Fix PMIC name
On Wed, Dec 26, 2012 at 11:51 AM, Robert Nelson robertcnel...@gmail.com wrote: On Wed, Dec 26, 2012 at 11:21 AM, Fabio Estevam feste...@gmail.com wrote: On Wed, Dec 26, 2012 at 3:08 PM, Robert Nelson robertcnel...@gmail.com wrote: I'll keep debugging it here, did reverting this commit, help with the resets? http://git.denx.de/?p=u-boot.git;a=commit;h=28e5ac2d974547bde0c72aa0c1d66fd22c6ef3ad Tried reverting it and still see the data-aborts. I am also testing on my mx53loco board with the mc34708 pmic and I see that it hangs on boot about 10% of the attempts: U-Boot 2013.01-rc2-00172-gf8cfcf1-dirty (Dec 26 2012 - 15:15:27) Board: MX53 LOCO I2C: ready DRAM: 1 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 This did not happen prior to commit c73368150 (pmic: Extend PMIC framework to support multiple instances of PMIC devices). Okay, now we are on the same page, upgraded to: arm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1-4.7-2012.12-20121214 - Linaro GCC 2012.12) 4.7.3 20121205 (prerelease).. With your Dialog patch, it is properly setting 1Ghz, and just keeps rebooting.. :) U-Boot 2013.01-rc2-00173-ga0d04f3 (Dec 26 2012 - 11:47:34) Board: MX53 LOCO I2C: ready DRAM: 1 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial CPU: Freescale i.MX53 family rev2.0 at 1000 MHz Reset cause: WDOG Net: FEC Warning: FEC using MAC address from net device Hit any key to stop autoboot: 0 data abort MAYBE you should read doc/README.arm-unaligned-accesses pc : [aff72250] lr : [aff72228] sp : af565d68 ip : fff4 fp : r10: 0003 r9 : affab8d9 r8 : af565f58 r7 : r6 : e5bc345d r5 : af6df330 r4 : e5bc345d r3 : af6df334 r2 : af6df333 r1 : r0 : af6df330 Flags: nzCv IRQs off FIQs off Mode SVC_32 Resetting CPU ... resetting ... Okay success on another bisect run to find what was causing the Data Abort with linaro's gcc toolchain.. gcc version 4.7.3 20121205 (prerelease) (crosstool-NG linaro-1.13.1-4.7-2012.12-20121214 - Linaro GCC 2012.12) Reverting, Troy's last 4 imximage changes: ab857f2613be39274d0870768720067ff9d859c0 (imximage: make set_imx_hdr_v1/v2 easier to read) ad0826dcd81ba6cf4cc93a4ca8337e1bc676c238 (imximage: change parameters to set_imx_hdr) 243319825fa6e79885d57b6b78e72f3fe10ef69c (imximage: delay setting of image size) 348ca8efb79652d2b259fbd0ed6d317a77a8cbb9 (imximage: fix size of image to load.) (this was the first bad bisect, the previous 3 are needed for a clean revert) Along with Fabio's mx53loco: Call PMIC related functions from board_late_init() The Dialog based mx53loco is no operating correctly with linaro's toolchain... U-Boot 2013.01-rc2-00176-gbc67175-dirty (Jan 02 2013 - 12:14:51) Board: MX53 LOCO I2C: ready DRAM: 1 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial CPU: Freescale i.MX53 family rev2.0 at 1000 MHz Reset cause: POR Net: FEC Warning: FEC using MAC address from net device Hit any key to stop autoboot: 0 mmc0 is current device ** Unrecognized filesystem type ** ** Unrecognized filesystem type ** Booting from net ... BOOTP broadcast 1 Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx53loco: Fix PMIC name
On Wed, Jan 2, 2013 at 1:42 PM, Troy Kisky
troy.ki...@boundarydevices.com wrote:
On 1/2/2013 11:33 AM, Fabio Estevam wrote:
Thanks for bisecting, Robert. Troy/Stefano, Any suggestions about this? It
would be really nice if we could keep mx53loco functional when using gcc
4.6.2. Regards, Fabio Estevam
Could you see if this patch makes any difference? It still needs cleaned up
some before mainline
[PATCH V4 01/11] imximage: mx53 needs transfer length a multiple of 512
diff --git a/tools/imximage.c b/tools/imximage.c
index 63f88b6..7e54e97 100644
--- a/tools/imximage.c
+++ b/tools/imximage.c
@@ -494,6 +494,8 @@ static void imximage_print_header(const void *ptr)
}
}
+#define ALIGN(a, b) (((a) + (b) - 1) ~((b) - 1))
+
static void imximage_set_header(void *ptr, struct stat *sbuf, int ifd,
struct mkimage_params *params)
{
@@ -515,7 +517,13 @@ static void imximage_set_header(void *ptr, struct stat
*sbuf, int ifd,
/* Set the imx header */
(*set_imx_hdr)(imxhdr, dcd_len, params-ep, imxhdr-flash_offset);
- *header_size_ptr = sbuf-st_size + imxhdr-flash_offset;
+ /*
+* ROM bug alert
+* mx53 only loads 512 byte multiples.
+* The remaining fraction of a block bytes would
+* not be loaded.
+*/
+ *header_size_ptr = ALIGN(sbuf-st_size + imxhdr-flash_offset, 512);
}
int imximage_check_params(struct mkimage_params *params)
-- 1.7.9.5
Sweet! Thanks Troy,
That fixes it on my Dialog based mx53loco with linaro's 4.7.3 gcc toolchain...
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot v2011.12-rc1 hang on pandaboard
On Mon, Dec 12, 2011 at 11:27 AM, Chris Lalancette clalance...@gmail.com wrote: Hello, I'm trying to boot the current version of u-boot (both the MLO and u-boot.img) on the pandaboard 4430. However, it always hangs up right after Using default environment, and before Hit any key to stop autoboot. I bisected the problem down to commit 9792987721c7980453fe6447c3fa6593b44f8458; if I revert that USB commit, then the boot proceeds as normal. I can't say I quite understand why this is a problem for the Panda, but aside from reverting the commit, does anyone have a suggestion for fixing this? Reverting that same commit also fixes the beagleboard xm.. For reference, I'm using, linaro's arm gcc: gcc version 4.6.2 20110908 (prerelease) (Linaro GCC 4.6-2011.09-1) Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] zImage and raw ramdisk support -- test
On Fri, Mar 30, 2012 at 10:38 AM, Marek Vasut marek.va...@gmail.com wrote: Guys, I need final test on as much platforms as possible. Can you please run these two following patches and tell me if they work with zImage and raw ramdisk for you? http://patchwork.ozlabs.org/patch/146848/ http://patchwork.ozlabs.org/patch/147440/ I can't promise they will make it to this release (I've been pestering WD pretty thoroughly (sorry about that), though I'm starting to be unhappy to merge this stuff at the verge of release myself). Hi Marek, These work great on my omap3 Beagle xM C / omap4 Panda, using a zImage and initramfs.. Just added the two appropriate board configs, to enable it.. #define CONFIG_CMD_BOOTZ #define CONFIG_SUPPORT_RAW_INITRD and used todays u-boot git head: http://git.denx.de/?p=u-boot.git;a=commit;h=7cb30b13f12077c7eec8ce2419cd96cd65ace8e2 Tested-by: Robert Nelson robertcnel...@gmail.com Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [beagleboard] Re: [PATCH v3] omap3_beagle: enable the use of a plain text file named uEnv.txt instead of boot.scr
On Wed, Mar 2, 2011 at 5:41 PM, Alexander Holler hol...@ahsoftware.de wrote: Hello Jason, Am 02.03.2011 21:26, schrieb Jason Kridner: For backwards compatibility the use of boot.scr is still supported. Sorry, but I think that line in the description should get removed too. So, just a thought.. Are you guys planning to push this same boot method to all the other omap devices that just finally got boot.scr boot support by default in u-boot? It also seems's like it'll end up be the FAQ of the month for the beagleboard group.. ;) Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] omap3_beagle: enable the use of a plain text file named uEnv.txt instead of boot.scr
On Thu, Mar 3, 2011 at 7:43 PM, Alexander Holler hol...@ahsoftware.de wrote: Am 03.03.2011 00:48, schrieb Robert Nelson: On Wed, Mar 2, 2011 at 5:41 PM, Alexander Hollerhol...@ahsoftware.de wrote: Hello Jason, Am 02.03.2011 21:26, schrieb Jason Kridner: For backwards compatibility the use of boot.scr is still supported. Sorry, but I think that line in the description should get removed too. So, just a thought.. Are you guys planning to push this same boot method to all the other omap devices that just finally got boot.scr boot support by default in u-boot? It also seems's like it'll end up be the FAQ of the month for the beagleboard group.. ;) I would say that should be decided by every board-maintainer, just like the change from ttyS2 to ttyO2. E.g. I don't think the devkit8000-sdk will change as soon as the stuff the for the beagleboard. Oh, we will work around it over the transition, so it's not a big deal.. It was just kinda nice, (if we assume all boards have xlo/u-boot in nand) that most boards would boot on one boot.scr/kernel/rootfs combination. Since the mainline kernel can boot on all omap2/3/4 boards (in mainline) at this point.. But since both the xM/Panda don't have nand, my point's kinda moot as they'll need a different xlo/u-boot... Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Fwd: [ Uboot code understanding guide ]
On Tue, Jan 28, 2014 at 11:16 AM, Devarsh gadhia devarsh.gad...@gmail.com wrote: Hey wolfgang, I am trying to port uboot on beagle boneblack. Eventhogh uboot has support for beagle board(but not for BBB), I'd like to port uboot 2013.10 on BBB as 1 task of ubuntu porting on BBB. Ah why a 3rd port? there's always two configs you can use on the BBB.. am335x_evm which supports: AM335x GP EVM AM335x EVM SK Beaglebone White Beaglebone Black or the am335x_boneblack which is just a tweak of am335x_evm to support only the BBB Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] [PATCH] omap3_beagle: fdt: xMA/B set hsusb2_power_reg active-high
With the xM revision C, the DC control of the usb hub was inverted.
By adding the enable-active-high property to hsusb2_power_reg, mainline
omap3-beagle-xm.dtb
will now activiate properly activate the usb hub on older xMA/B varients.
Signed-off-by: Robert Nelson robertcnel...@gmail.com
CC: Tom Rini tr...@ti.com
---
include/configs/omap3_beagle.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index c58bc91..d7d63ce 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -249,6 +249,9 @@
setenv fdtfile omap3-beagle-xm.dtb; fi; \
if test $fdtfile = undefined; then \
echo WARNING: Could not determine device tree to use;
fi; \0 \
+ fixfdt= \
+ if test $beaglerev = xMAB; then \
+ fdt addr ${fdtaddr}; fdt resize; fdt set
/hsusb2_power_reg enable-active-high; fi; \0 \
bootenv=uEnv.txt\0 \
loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenv}\0 \
importbootenv=echo Importing environment from mmc ...; \
@@ -308,6 +311,7 @@
setenv bootfile zImage; \
if run loadimage; then \
run loadfdt; \
+ run fixfdt; \
run mmcbootz; \
fi; \
--
1.8.5.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] [PATCH] omap3_beagle: fdt: xMA/B set hsusb2_power_reg active-high
On Tue, Jan 28, 2014 at 5:31 PM, Robert Nelson robertcnel...@gmail.com wrote:
With the xM revision C, the DC control of the usb hub was inverted.
By adding the enable-active-high property to hsusb2_power_reg, mainline
omap3-beagle-xm.dtb
will now activiate properly activate the usb hub on older xMA/B varients.
Signed-off-by: Robert Nelson robertcnel...@gmail.com
CC: Tom Rini tr...@ti.com
---
include/configs/omap3_beagle.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index c58bc91..d7d63ce 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -249,6 +249,9 @@
setenv fdtfile omap3-beagle-xm.dtb; fi; \
if test $fdtfile = undefined; then \
echo WARNING: Could not determine device tree to
use; fi; \0 \
+ fixfdt= \
+ if test $beaglerev = xMAB; then \
+ fdt addr ${fdtaddr}; fdt resize; fdt set
/hsusb2_power_reg enable-active-high; fi; \0 \
bootenv=uEnv.txt\0 \
loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenv}\0 \
importbootenv=echo Importing environment from mmc ...; \
@@ -308,6 +311,7 @@
setenv bootfile zImage; \
if run loadimage; then \
run loadfdt; \
+ run fixfdt; \
run mmcbootz; \
fi; \
--
1.8.5.3
I've listed this as an RFC, as i'm not sure if there is a generic way
we should be doing device tree fixup's in u-boot.
I have thought about splitting omap3-beagle-xm.dtb into two variants
ab and c with just a simple one line delta:
https://github.com/RobertCNelson/armv7-multiplatform/blob/v3.13.x/patches/omap3_beagle_xm_rework/0002-ARM-dts-omap3-beagle-xm-ab-usb-host-is-active-high-t.patch
But it's just so trivial to just fix it in u-boot instead.
Thoughts?
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] [PATCH] omap3_beagle: fdt: xMA/B set hsusb2_power_reg active-high
Well, we have per-platform fixups in the tree today. However this now means that only u-boot is going to provide a correct and fully functional tree for those revs, which isn't good imho for the beagleboard community use cases of older u-boots / distro support / non-u-boot bootloader support, so it'd probably be best to have per rev DTs and update findfdt to use the right one. Thanks Tom, The thing is, usb has been broken on the xMA/B's ever since we first setup findfdt to use the omap3-beagle-xm.dtb. Although the usb ehci port was finally fixed in v3.13-rcX, so nobody really noticed these pre-xMC's where broken in the first place. That's why I thought it made more sense to fix it in u-boot, as we then get mainline v3.13.x working out of the box for free. (if the distro upgrades u-boot) Otherwise all distro's need to carry a kernel patch for v3.13/v3.14 adding a new omap3-beagle-xm-ab.dtb variant. I can go either way, as i've been pushing out images with the *-ab.dtb / *-c.dtb variants running v3.12/v3.13 to the beagleboard community. But while updating my base image to v2014.01, i thought pushing it to u-boot might be better in the long run. Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] omap3_beagle: xM A/B validate new dtb exits in file system
On Fri, May 2, 2014 at 3:15 PM, robertcnelson robertcnel...@gmail.com wrote:
From: Robert Nelson robertcnel...@gmail.com
Fall back to previous dtb used when omap3-beagle-xm-ab.dtb doesn't exist in
file system
Signed-off-by: Robert Nelson robertcnel...@gmail.com
CC: Tom Rini tr...@ti.com
CC: Nishanth Menon n...@ti.com
---
include/configs/omap3_beagle.h | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index a1d38ff..06b9006 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -248,6 +248,12 @@
setenv fdtfile omap3-beagle-xm.dtb; fi; \
if test $fdtfile = undefined; then \
echo WARNING: Could not determine device tree to
use; fi; \0 \
+ validatefdt= \
+ if test $beaglerev = xMAB; then \
+ if test ! -e mmc ${bootpart} ${bootdir}/${fdtfile};
then \
+ setenv fdtfile omap3-beagle-xm.dtb; \
+ fi; \
+ fi; \0 \
bootenv=uEnv.txt\0 \
loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenv}\0 \
importbootenv=echo Importing environment from mmc ...; \
@@ -263,7 +269,7 @@
rootfstype=${ramrootfstype}\0 \
loadramdisk=load mmc ${bootpart} ${rdaddr} ${bootdir}/${ramdisk}\0 \
loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0
\
- loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0 \
+ loadfdt=run validatefdt; load mmc ${bootpart} ${fdtaddr}
${bootdir}/${fdtfile}\0 \
mmcboot=echo Booting from mmc ...; \
run mmcargs; \
bootm ${loadaddr}\0 \
--
1.9.2
Little git send-email failure here, I was trying to send this second
as patch as [RFC].
This is my first thoughts of keeping backward compatibility with less
then v3.15-rc3 kernels.
Thoughts?
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] toolchain problems when building iMX6 mx6qsabreauto (and another bootloader tool)
On Fri, Nov 29, 2013 at 4:28 PM, Wolfgang Denk w...@denx.de wrote: Dear Christian Gmeiner, In message cah9nwweb6s+3s4o25d7cifob9y3_7jmhosjo6o78fijquwz...@mail.gmail.com you wrote: I am running into the same problem. Me wonders which patch/change triggers this problem. I am using the same toolchain since I started to work with u-boot and it fails with the latest rc. Maybe Linaro started using a hard-float configuration only recently? For what it's worth, i just ran a git bisect on this issue today, as this compiler worked fine with v2013.10 toolchain: arm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1-4.8-2013.10 - Linaro GCC 2013.10) 4.8.2 20131014 (prerelease) 762a88ccf8540948fbf8c31b40a29d1e0684a25b is the first bad commit commit 762a88ccf8540948fbf8c31b40a29d1e0684a25b Author: Pierre Aubert p.aub...@staubli.com Date: Thu Sep 19 17:48:59 2013 +0200 mx6: compute PLL PFD frequencies rather than using defines Signed-off-by: Pierre Aubert p.aub...@staubli.com CC: Stefano Babic sba...@denx.de :04 04 c3dba1387015304c14486872c9776d008d9a3b03 1f16de9cee07af71e12f1a746dcd962c9eb84bb0 M arch git bisect log git bisect start # good: [183acb700378a8cfc5d50a01a65de93fb2c24586] Prepare v2013.10 git bisect good 183acb700378a8cfc5d50a01a65de93fb2c24586 # bad: [d19ad726bcd5d9106f7ba9c750462fcc369f1020] Prepare v2014.01-rc1 git bisect bad d19ad726bcd5d9106f7ba9c750462fcc369f1020 # good: [65ba7add0d609bbd035b8d42fafdaf428ac24751] time: add weak annotation to timer_read_counter declaration git bisect good 65ba7add0d609bbd035b8d42fafdaf428ac24751 # bad: [c3ebb8c38a5da5e40da2786c5d850d1f6555ff95] Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx git bisect bad c3ebb8c38a5da5e40da2786c5d850d1f6555ff95 # bad: [3285d4ca197928a048d3dda86751b5d26e6e0e86] Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' git bisect bad 3285d4ca197928a048d3dda86751b5d26e6e0e86 # good: [552998e5f7655ba8fd3acff400012bd651edff06] TI:armv7: Change CONFIG_SYS_SPL_ARGS_ADDR to a higher address git bisect good 552998e5f7655ba8fd3acff400012bd651edff06 # bad: [195d130da1c2705f96571b7265312bdfa8a83fee] Revert configs: imx: Make CONFIG_SYS_PROMPT uniform across FSL boards git bisect bad 195d130da1c2705f96571b7265312bdfa8a83fee # bad: [4867b634b7c0e5ede258b4998fa4b2710e7daacf] ARM: mx5: Enable L2 cache git bisect bad 4867b634b7c0e5ede258b4998fa4b2710e7daacf # bad: [0c5e26678b18e136c1514bf769a16060ae1b5ff8] udoo: Add initial support for mx6q udoo board git bisect bad 0c5e26678b18e136c1514bf769a16060ae1b5ff8 # bad: [6654f33c9b520bd4073c7f82a13044e79bc14898] ARM: mxs: tools: Use mkimage for BootStream generation git bisect bad 6654f33c9b520bd4073c7f82a13044e79bc14898 # bad: [762a88ccf8540948fbf8c31b40a29d1e0684a25b] mx6: compute PLL PFD frequencies rather than using defines git bisect bad 762a88ccf8540948fbf8c31b40a29d1e0684a25b # first bad commit: [762a88ccf8540948fbf8c31b40a29d1e0684a25b] mx6: compute PLL PFD frequencies rather than using defines using USE_PRIVATE_LIBGCC=yes causes another error.. arch/arm/cpu/armv7/mx6/built-in.o: In function `mxc_get_pll_pfd': /opt/github/u-boot/arch/arm/cpu/armv7/mx6/clock.c:126: undefined reference to `__aeabi_uldivmod' /opt/gcc/gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_linux/bin/arm-linux-gnueabihf-ld.bfd: BFD (crosstool-NG linaro-1.13.1-4.8-2013.10 - Linaro GCC 2013.10) 2.23.2.20130610 Linaro 2013.10-4 assertion fail /cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/src/binutils-linaro-2.23.2-2013.10-4/bfd/elf32-arm.c:7687 /opt/gcc/gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_linux/bin/arm-linux-gnueabihf-ld.bfd: error: required section '.rel.plt' not found in the linker script /opt/gcc/gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_linux/bin/arm-linux-gnueabihf-ld.bfd: final link failed: Invalid operation make: *** [u-boot] Error 1 Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] toolchain problems when building iMX6 mx6qsabreauto (and another bootloader tool)
On Wed, Dec 4, 2013 at 9:35 AM, Måns Rullgård m...@mansr.com wrote: Robert Nelson robertcnel...@gmail.com writes: On Fri, Nov 29, 2013 at 4:28 PM, Wolfgang Denk w...@denx.de wrote: Dear Christian Gmeiner, In message cah9nwweb6s+3s4o25d7cifob9y3_7jmhosjo6o78fijquwz...@mail.gmail.com you wrote: I am running into the same problem. Me wonders which patch/change triggers this problem. I am using the same toolchain since I started to work with u-boot and it fails with the latest rc. Maybe Linaro started using a hard-float configuration only recently? For what it's worth, i just ran a git bisect on this issue today, as this compiler worked fine with v2013.10 toolchain: arm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1-4.8-2013.10 - Linaro GCC 2013.10) 4.8.2 20131014 (prerelease) 762a88ccf8540948fbf8c31b40a29d1e0684a25b is the first bad commit commit 762a88ccf8540948fbf8c31b40a29d1e0684a25b Author: Pierre Aubert p.aub...@staubli.com Date: Thu Sep 19 17:48:59 2013 +0200 mx6: compute PLL PFD frequencies rather than using defines That commit introduces a 64-bit division without using the lldiv() function, which pulls in previously unused libgcc stuff. Try this patch: diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c index 873d9d0..752b3c8 100644 --- a/arch/arm/cpu/armv7/mx6/clock.c +++ b/arch/arm/cpu/armv7/mx6/clock.c @@ -5,6 +5,7 @@ */ #include common.h +#include div64.h #include asm/io.h #include asm/errno.h #include asm/arch/imx-regs.h @@ -123,8 +124,8 @@ static u32 mxc_get_pll_pfd(enum pll_clocks pll, int pfd_num) return 0; } - return (freq * 18) / ((div ANATOP_PFD_FRAC_MASK(pfd_num)) - ANATOP_PFD_FRAC_SHIFT(pfd_num)); + return lldiv(freq * 18, (div ANATOP_PFD_FRAC_MASK(pfd_num)) + ANATOP_PFD_FRAC_SHIFT(pfd_num)); } static u32 get_mcu_main_clk(void) Thanks Måns! That fixed it... Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Sources for MLO on BeagleBone Black?
On Wed, Dec 4, 2013 at 2:34 PM, Satz Klauer satzkla...@googlemail.com wrote: Hi Tom, point is, I want to change some functionality of bootloader - thus I want to know where it is built from. It is nice when MLO file appears automagically but in my special case I like to know where it comes from exaclty. http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/am33xx/config.mk#l7 Everything built inside CONFIG_SPL_BUILD for the particular TI/OMAP based target.. Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs
On Thu, Dec 5, 2013 at 8:18 PM, Dennis Gilmore den...@ausil.us wrote:
Signed-off-by: Dennis Gilmore den...@ausil.us
---
include/configs/wandboard.h | 40 +++-
1 file changed, 35 insertions(+), 5 deletions(-)
diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
index e9c7e64..02d8968 100644
--- a/include/configs/wandboard.h
+++ b/include/configs/wandboard.h
@@ -40,6 +40,9 @@
#define CONFIG_CONS_INDEX 1
#define CONFIG_BAUDRATE115200
+/* enable generic distro config */
+#define DISTRO_DEFAULTS 1
+
/* Command definition */
#include config_cmd_default.h
@@ -48,7 +51,6 @@
#define CONFIG_CMD_BMODE
#define CONFIG_CMD_SETEXPR
-#define CONFIG_BOOTDELAY 5
#define CONFIG_SYS_MEMTEST_START 0x1000
#define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_MEMTEST_START + 500 *
SZ_1M)
@@ -65,6 +67,9 @@
#define CONFIG_CMD_MMC
#define CONFIG_GENERIC_MMC
#define CONFIG_BOUNCE_BUFFER
+
+#define CONFIG_BOOTDELAY 5
+
#define CONFIG_CMD_EXT2
#define CONFIG_CMD_FAT
#define CONFIG_DOS_PARTITION
@@ -74,6 +79,11 @@
#define CONFIG_CMD_DHCP
#define CONFIG_CMD_MII
#define CONFIG_CMD_NET
+
+#define CONFIG_OF_LIBFDT
+#define CONFIG_CMD_BOOTZ
+
+/* Ethernet Configuration */
#define CONFIG_FEC_MXC
#define CONFIG_MII
#define IMX_FEC_BASE ENET_BASE_ADDR
@@ -113,8 +123,30 @@
fdt_high=0x\0 \
initrd_high=0x\0 \
fdt_file= CONFIG_DEFAULT_FDT_FILE \0 \
- fdt_addr=0x1100\0 \
+ fdt_addr=0x1110\0 \
+ fdt_addr_r=0x1120\0 \
+ pxefile_addr_r=0x1130\0 \
+ scr_addr_r=0x1140\0 \
+ kernel_addr_r=0x1150\0 \
+ ramdisk_addr_r=0x1350\0 \
boot_fdt=try\0 \
+ bootcmd_setup=mmc rescan\0 \
+ bootcmd_pxe=setenv bootfile \\ ;dhcp; tftp ${fdt_addr}
/dtb/${fdt_file}; pxe get; pxe boot\0 \
+ bootcmd_disk_scr=ext2load ${boot_ifc} ${bootdevice} ${scr_addr_r}
boot.scr
Why all the non-generic ext2load's? use just load, then it'll work
with both fat, ext2/3/4 btrfs...
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs
On Thu, Dec 5, 2013 at 11:01 PM, Dennis Gilmore den...@ausil.us wrote:
El Thu, 5 Dec 2013 21:47:43 -0600
Robert Nelson robertcnel...@gmail.com escribió:
On Thu, Dec 5, 2013 at 8:18 PM, Dennis Gilmore den...@ausil.us
wrote:
Signed-off-by: Dennis Gilmore den...@ausil.us
---
include/configs/wandboard.h | 40
+++- 1 file changed, 35
insertions(+), 5 deletions(-)
diff --git a/include/configs/wandboard.h
b/include/configs/wandboard.h index e9c7e64..02d8968 100644
--- a/include/configs/wandboard.h
+++ b/include/configs/wandboard.h
@@ -40,6 +40,9 @@
#define CONFIG_CONS_INDEX 1
#define CONFIG_BAUDRATE115200
+/* enable generic distro config */
+#define DISTRO_DEFAULTS 1
+
/* Command definition */
#include config_cmd_default.h
@@ -48,7 +51,6 @@
#define CONFIG_CMD_BMODE
#define CONFIG_CMD_SETEXPR
-#define CONFIG_BOOTDELAY 5
#define CONFIG_SYS_MEMTEST_START 0x1000
#define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_MEMTEST_START +
500 * SZ_1M) @@ -65,6 +67,9 @@
#define CONFIG_CMD_MMC
#define CONFIG_GENERIC_MMC
#define CONFIG_BOUNCE_BUFFER
+
+#define CONFIG_BOOTDELAY 5
+
#define CONFIG_CMD_EXT2
#define CONFIG_CMD_FAT
#define CONFIG_DOS_PARTITION
@@ -74,6 +79,11 @@
#define CONFIG_CMD_DHCP
#define CONFIG_CMD_MII
#define CONFIG_CMD_NET
+
+#define CONFIG_OF_LIBFDT
+#define CONFIG_CMD_BOOTZ
+
+/* Ethernet Configuration */
#define CONFIG_FEC_MXC
#define CONFIG_MII
#define IMX_FEC_BASE ENET_BASE_ADDR
@@ -113,8 +123,30 @@
fdt_high=0x\0 \
initrd_high=0x\0 \
fdt_file= CONFIG_DEFAULT_FDT_FILE \0 \
- fdt_addr=0x1100\0 \
+ fdt_addr=0x1110\0 \
+ fdt_addr_r=0x1120\0 \
+ pxefile_addr_r=0x1130\0 \
+ scr_addr_r=0x1140\0 \
+ kernel_addr_r=0x1150\0 \
+ ramdisk_addr_r=0x1350\0 \
boot_fdt=try\0 \
+ bootcmd_setup=mmc rescan\0 \
+ bootcmd_pxe=setenv bootfile \\ ;dhcp; tftp
${fdt_addr} /dtb/${fdt_file}; pxe get; pxe boot\0 \
+ bootcmd_disk_scr=ext2load ${boot_ifc} ${bootdevice}
${scr_addr_r} boot.scr
Why all the non-generic ext2load's? use just load, then it'll work
with both fat, ext2/3/4 btrfs...
Regards,
the pxe code requires you specify the filesystem for the sysboot
command, and as /boot needs to be ext ive kept it consistent. Ive also
not narrowed down the option to enable load to work, in my testing it
did not work.
Ah, i see the issue, #define CONFIG_CMD_FS_GENERIC isn't defined yet
for the wandboard in mainline u-boot, as you don't set it either in
your patch, so of course a generic load won't work..
So if you add:
#define CONFIG_CMD_EXT4
#define CONFIG_CMD_FS_GENERIC
after:
#define CONFIG_CMD_EXT2
in your patch you can drop all the ext2load non-sense for generic loads.
I've been shipping ubuntu/debian images with '#define
CONFIG_CMD_FS_GENERIC' and 'load' for the wand since v2013.07 with no
issues..
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs
Why all the non-generic ext2load's? use just load, then it'll work with both fat, ext2/3/4 btrfs... Regards, the pxe code requires you specify the filesystem for the sysboot command, and as /boot needs to be ext ive kept it consistent. Ive also not narrowed down the option to enable load to work, in my testing it did not work. having said that I just found CONFIG_CMD_FS_GENERIC which is not set, though cmd_pxe.c will need some patching to not require specifying a filesystem I can see fixing cmd_pxe.c could be done later. But as just a generic uEnv.txt user, I do like the idea of having a consistent variable naming setup for a bunch of boards. So i can easily convert my stuff to this setup, but the ext2load vs a generic load was the one big issue it was missing. Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Question: booting Linux from ext4 mmc partition
On Mon, Jan 6, 2014 at 8:56 AM, nidalpres nidalp...@gmail.com wrote: Hi all! I was following instructions from http://eewiki.net/display/linuxonarm/iMX233-OLinuXino in order to get mainline kernel to boot off of my olinuxino micro board. I have created two partitions on my SD card: Device Boot Start End Blocks Id System /dev/sde12048 67583 32768 53 OnTrack DM6 Aux3 /dev/sde2 67584 7829503 3880960 83 Linux and installed everything as per instructions. However on boot this is what I get on console: HTLLCLC U-Boot 2013.10-dirty (Jan 05 2014 - 19:38:28) CPU: Freescale i.MX23 rev1.4 at 454 MHz BOOT: SSP SD/MMC #0 DRAM: 64 MiB MMC: MXS MMC: 0 *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial Net: Net Initialization Skipped No ethernet found. Hit any key to stop autoboot: 0 mmc0 is current device SD/MMC found on device 0 221 bytes read in 149 ms (1000 Bytes/s) Importing environment from mmc (uEnv.txt)... Checking if uenvcmd is set ... Running default loadzimage ... MMC0: Data error with command 18 (status 0xf0302020)! ** ext4fs_devread read error - block = I couldn't find anywhere what ext4fs_devread read error - block means. Found message origin in ext4fs_devread() function in u-boot source after some time but I really can't get my head around on what it means just by reading code. I suspect it doesn't like block sizes or something, not sure. So I changed second partition to ext2 (instead of ext4) an changed env parameters to instruct uboot that it is ext2 partition, nothing changed. Then I changed source header file include/configs/mx23_olinuxino.h and removed #define CONFIG_CMD_EXT4 from it hoping it will remove ext4 support. I also changed hardcoded env parameters in same file from mmcrootfstype=ext4 to mmcrootfstype=ext2. Recompiled u-boot, dd it to sd card, rinse and repeat, got exactly the same response on console you see above. I give up for today after 3 hours of battling with it. I plan to make 3 partitions: amtrak, vfat (for kernel) and ext4 (for rootfs). But if ext4fs_devread persists to complain (and I apparently haven't removed it from code) I don't think it would work either. What is going on? Can anyone give me some pointers what to do next? Just for sanity sake, have you tried try a different (brand) microSD card? Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Question: booting Linux from ext4 mmc partition
On Tue, Jan 7, 2014 at 1:26 PM, nidalpres nidalp...@gmail.com wrote: Hi Robert! I have 4-5 microsd cards (Kingston, SanDisk, Samsung), 4 and 8GB in size, tried two, same thing. I also tried vfat partition and disabled support for ext2 AND ext4 completely in u-boot, and basically same thing happened. Then I tried to list/load files manually from vfat/ext4 partitions using u-boot command prompt. I can list vfat and ext4 partitions and load files from them into memory. However, once I load uImage file everything regarding mmc access and loading files breaks. I seems to me that loading one big file somehow corrupts something (hahah, very precise explanation). uImage is little over 4MB. So if it's a failing at 4MB, at what size does it work as you maybe over writing memory.. Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] omap3_beagle: use omap3-beagle.dtb for the C4 revision
findftd is currently setting fdtfile to undefined for the beagle c4, select omap3-beagle.dtb instead Signed-off-by: Robert Nelson robertcnel...@gmail.com --- include/configs/omap3_beagle.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h index 1b566c0..c58bc91 100644 --- a/include/configs/omap3_beagle.h +++ b/include/configs/omap3_beagle.h @@ -241,6 +241,8 @@ setenv fdtfile omap3-beagle.dtb; fi; \ if test $beaglerev = Cx; then \ setenv fdtfile omap3-beagle.dtb; fi; \ + if test $beaglerev = C4; then \ + setenv fdtfile omap3-beagle.dtb; fi; \ if test $beaglerev = xMAB; then \ setenv fdtfile omap3-beagle-xm.dtb; fi; \ if test $beaglerev = xMC; then \ -- 1.8.5.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
On Thu, Aug 14, 2014 at 10:49 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 08/14/2014 02:25 AM, Alexander Holler wrote: Am 31.07.2014 21:57, schrieb Stephen Warren: Huh, I do see that now. I must have been looking at the content of common/cmd_nvedit.c from the wrong branch, which didn't include that patch. I could have sworn I checked git history too, but evidently not. It is indeed clearly there right before the patches which use it. Sorry for the noise. As I've just remembered where I did see your name before, the config for the rpi (as found in 2004.04) misses the uenvcmd. That's necessary to execute commands when using uEnv.txt. It's easily done with something like the following: env import -t -r $loadaddr $filesize; \ if test -n \$uenvcmd\; then \ echo \Running uenvcmd ...\; \ run uenvcmd; \ fi; \ My intention was that uEnv.txt be used to set up environment variables, not to allow its use for custom scripts. The check for if uenvcmd is set then run uenvcmd syntax, should really be pushed into the distro default stuff. As that syntax is used by default for a lot of different targets in u-boot. Most users who deal with u-boot (even if they don't want to) seem to understand it. Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Revert am335x_evm.h: If mmcdev and bootpart switch to mmcdev 1, so should mmcroot.
On Tue, Oct 8, 2013 at 3:39 PM, Robert P. J. Day rpj...@crashcourse.ca wrote: On Tue, 8 Oct 2013, Tom Rini wrote: ... snip ... Applied to u-boot/master. dumb question but what does it mean to say Applied to u-boot/master when it clearly has not been applied to master? i can see posts like that, but doing a git pull produces nothing. i am on the u-boot mainline, and the master branch, so what am i misunderstanding? thanks. The public git/http server is only synced every 6hours... Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bad Linux ARM zImage magic
On Tue, Oct 22, 2013 at 11:11 PM, claus anders cytroni...@yahoo.de wrote: Due to this patch: 0001-omap3_beagle-uEnv.txt-bootz-n-fixes.patch, u-boot for my beagleboard seems to need always a zImage. Up to now, I used uImage just fine. Correct, that's exactly one of the features that my out of tree patch does.. If you'd like to use uImage, don't apply my patch. ;) (adding u-boot cc this time..) Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [[PATCH v2]pandaboard: 1/1] Modification of Elpida DDR2 RAM for Pandaboard-ES Rev B3
On Thu, Nov 14, 2013 at 4:06 AM, Hardik hardik.pa...@volansystech.com wrote:
From: Hardik Patel hardik.pa...@volansystech.com
Signed-off-by: Hardik Patel hardik.pa...@volansystech.com
---
arch/arm/cpu/armv7/omap4/sdram_elpida.c |2 +-
board/ti/panda/panda.c | 24
2 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/omap4/sdram_elpida.c
b/arch/arm/cpu/armv7/omap4/sdram_elpida.c
index e4c8316..9fbdeea 100644
--- a/arch/arm/cpu/armv7/omap4/sdram_elpida.c
+++ b/arch/arm/cpu/armv7/omap4/sdram_elpida.c
@@ -123,7 +123,7 @@ static void emif_get_reg_dump_sdp(u32 emif_nr, const
struct emif_regs **regs)
*regs = emif_regs_elpida_200_mhz_2cs;
else if (omap4_rev == OMAP4430_ES2_3)
*regs = emif_regs_elpida_400_mhz_1cs;
- else if (omap4_rev OMAP4470_ES1_0)
+ else if (omap4_rev OMAP4470_ES1_0 !is_panda_es_rev_b3())
*regs = emif_regs_elpida_400_mhz_2cs;
else
*regs = emif_regs_elpida_400_mhz_1cs;
diff --git a/board/ti/panda/panda.c b/board/ti/panda/panda.c
index c104024..5a7f80a 100644
--- a/board/ti/panda/panda.c
+++ b/board/ti/panda/panda.c
@@ -122,6 +122,30 @@ int get_board_revision(void)
return board_id;
}
+/*
+* Routine: is_panda_es_rev_b3
+* Description: Detect if we are running on B3 version of ES panda board,
+* This can be done by reading the level of GPIO 171
+* and checking the processor revisions.
+* GPIO171: 1 = Panda ES Rev B3
+*/
+u8 is_panda_es_rev_b3(void)
+{
+int processor_rev = omap_revision();
+int ret = 0;
+
+if ((processor_rev = OMAP4460_ES1_0
+ processor_rev = OMAP4460_ES1_1)) {
+
+/* Setup the mux for the common board ID pins (gpio 171) */
+writew((IEN | M3), (*ctrl)-control_padconf_core_base +
UNIPRO_TX0);
+
+/* if processor_rev is panda ES and GPIO171 is 1, it is rev
b3 */
+ret = gpio_get_value(PANDA_BOARD_ID_2_GPIO);
+}
+return ret;
+}
+
/**
* @brief misc_init_r - Configure Panda board specific configurations
* such as power configurations, ethernet initialization as phase2 of
Nice, this works great on my Panda ES B3.
Tested-by: Robert Nelson robertcnel...@gmai.com
U-Boot SPL 2013.10-00339-g712d969 (Nov 14 2013 - 09:21:19)
OMAP4460 ES1.1
SPL: Please implement spl_start_uboot() for your board
SPL: Direct Linux boot not active!
reading u-boot.img
reading u-boot.img
U-Boot 2013.10-00339-g712d969 (Nov 14 2013 - 09:21:19)
CPU : OMAP4460 ES1.1
Board: OMAP4 Panda
I2C: ready
DRAM: 1 GiB
MMC: OMAP SD/MMC: 0
Using default environment
BTW, should be bump the system enviroment board_name, that way it
loads a different kernel *.dtb? (omap4-panda-es-b3.dtb)
As right now it'll load the omap4-panda-es.dtb which currently uses
both cs lines on the emif driver..
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap4-panda-common.dtsi#n373
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [BeagleBone Black] AM335x CPU frequency
On Wed, Apr 9, 2014 at 6:59 AM, Xuebing Wang xbi...@gmail.com wrote: Hi community, Can someone confirm that in the latest u-boot code, by default BeagleBone Black CPU AM335x is using opp100 (dpll_mpu_opp100), and CPU runs at 1GHz? Thanks. http://git.denx.de/?p=u-boot.git;a=blob;f=board/ti/am335x/board.c;hb=HEAD#l280 Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Resets on mx6qsabrelite
On Wed, Sep 19, 2012 at 7:59 AM, Fabio Estevam feste...@gmail.com wrote: Hi, I am getting reset when using latest U-boot mainline with mx6qsabrelite and loading a kernel. U-Boot 2012.07-00580-g49b3962 (Sep 19 2012 - 09:56:23) CPU: Freescale i.MX6Q rev1.0 at 792 MHz Reset cause: POR Board: MX6Q-Sabre Lite DRAM: 1 GiB WARNING: Caches not enabled MMC: FSL_SDHC: 0, FSL_SDHC: 1 In:serial Out: serial Err: serial Net: FEC Hit any key to stop autoboot: 0 Using FEC device TFTP from server 192.168.1.103; our IP address is 192.168.1.108 Filename 'uImage'. Load address: 0x1200 Loading: # # # # done Bytes transferred = 3220080 (312270 hex) Using FEC device TFTP from server 192.168.1.103; our IP address is 192.168.1.108 Filename 'imx6q-sabrelite.dtb'. Load address: 0x11ff Loading: # done Bytes transferred = 13715 (3593 hex) ## Booting kernel from Legacy Image at 1200 ... Image Name: Linux-3.5.3 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3220016 Bytes = 3.1 MiB Load Address: 10008000 Entry Point: 10008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 11ff Booting using the fdt blob at 0x11ff Loading Kernel Image ... OK OK Using Device Tree in place at 11ff, end 11ff6592 data abort pc : [4ff81fd8] lr : [4ff75950] sp : 4fd6fb90 ip : 11ff028c fp : r10: 4ffae980 r9 : r8 : 4fd6ff60 r7 : 11ff r6 : r5 : r4 : 4ffae980 r3 : r2 : 4ffa2529 r1 : 4fd6fb88 r0 : 11ff Flags: nZCv IRQs off FIQs off Mode SVC_32 Resetting CPU ... resetting ... It might be masking the problem, but I've been reverting: http://git.denx.de/?p=u-boot.git;a=commit;h=c50afc1dab78a1a72bc37b60d97864e56b52cc5c (I've also been reverting that for mx51evk/mx53loco when using device tree's too...) Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] mx6qsabrelite: Change default environment to cope with OE changes
On Wed, Sep 19, 2012 at 10:13 AM, Otavio Salvador ota...@ossystems.com.br wrote: OpenEmbedded has change partitioning layout of generated image so it does not raise warnings during the boot regarding unkown partition being used for U-Boot. Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- include/configs/mx6qsabrelite.h |8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/include/configs/mx6qsabrelite.h b/include/configs/mx6qsabrelite.h index 72d0154..0d5fd40 100644 --- a/include/configs/mx6qsabrelite.h +++ b/include/configs/mx6qsabrelite.h @@ -141,12 +141,10 @@ #define CONFIG_EXTRA_ENV_SETTINGS \ script=boot.scr\0 \ uimage=uImage\0 \ - console=ttymxc1\0 \ - fdt_high=0x\0 \ - initrd_high=0x\0 \ Your going to need fdt_high/initrd_high for when using linux device tree's... Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] mx6qsabrelite: Change default environment to cope with OE changes
On Wed, Sep 19, 2012 at 1:00 PM, Otavio Salvador ota...@ossystems.com.br wrote: On Wed, Sep 19, 2012 at 2:57 PM, Robert Nelson robertcnel...@gmail.com wrote: On Wed, Sep 19, 2012 at 10:13 AM, Otavio Salvador ota...@ossystems.com.br wrote: OpenEmbedded has change partitioning layout of generated image so it does not raise warnings during the boot regarding unkown partition being used for U-Boot. Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- include/configs/mx6qsabrelite.h |8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/include/configs/mx6qsabrelite.h b/include/configs/mx6qsabrelite.h index 72d0154..0d5fd40 100644 --- a/include/configs/mx6qsabrelite.h +++ b/include/configs/mx6qsabrelite.h @@ -141,12 +141,10 @@ #define CONFIG_EXTRA_ENV_SETTINGS \ script=boot.scr\0 \ uimage=uImage\0 \ - console=ttymxc1\0 \ - fdt_high=0x\0 \ - initrd_high=0x\0 \ Your going to need fdt_high/initrd_high for when using linux device tree's... I am not against keeping it but it is not used right now. It may not be used in openembedded, but device tree is the only option for a pure mainline kernel for this board, so it's needed. ;) Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] mx53loco: Allow booting a zImage kernel
On Wed, Oct 24, 2012 at 2:44 PM, Fabio Estevam feste...@gmail.com wrote: From: Fabio Estevam fabio.este...@freescale.com Allow booting a zImage kernel. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- include/configs/mx53loco.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/mx53loco.h b/include/configs/mx53loco.h index 0658dd3..25672c0 100644 --- a/include/configs/mx53loco.h +++ b/include/configs/mx53loco.h @@ -103,6 +103,7 @@ /* Command definition */ #include config_cmd_default.h +#define CONFIG_CMD_BOOTZ Fabio, Any thoughts on also enabling define CONFIG_SUPPORT_RAW_INITRD at the same time, otherwise you'd still have to run mkimage on the other half initrd.img-$(uname -r) when using booting an initramfs with your main kernel image.. Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] any value in defining specifically a beagleboard xM config file?
On Sun, Nov 11, 2012 at 9:18 AM, Robert P. J. Day rpj...@crashcourse.ca wrote: i'll guess this topic has come up before but is there any value in defining a config file explicitly for the beagle xM, which differs from the beagle classic primarily in that it has no onboard flash? on my current xM, i have a perfectly fine booting u-boot which i'm thinking i got from the circuitco site, and it works terrifically except that it comes with numerous commands related to flash, of which there is of course none. the stock omap3_beagle.h file, unsurprisingly, configures all of the MTD and NAND settings relevant for the classic, which are entirely superfluous for the xM. and given the number of commands that represents, there's lots of stuff that obviously has no value on the xM. The first run of xM-A3's out of the factory actually had nand, due to a shortage at the time of nandless-pop memory at the time.. Although you can't boot from it, (without modifications to the board), it's still usable in u-boot/kernel.. Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2015.01-rc3 released
On Mon, Dec 8, 2014 at 3:44 PM, Tom Rini tr...@ti.com wrote: Hey all, I've pushed v2015.01-rc3 out to the repository and tarballs should exist soon. So, we're nearing the end now, relatively speaking, so things should start getting quieter. I'd like everyone to please build their respective areas and make sure everything is building right. As always, if anything else is broken please speak up. On mx53loco_defconfig I'm getting: drivers/built-in.o: In function `reset_sata': /var/lib/jenkins/jobs/github_Bootloader-Builder/workspace/scratch/u-boot/drivers/block/dwc_ahsata.c:611: undefined reference to `disable_sata_clock' /var/lib/jenkins/jobs/github_Bootloader-Builder/workspace/dl/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-ld.bfd: BFD (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) 2.24.0.20140829 Linaro 2014.09 assertion fail /cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/src/binutils-linaro-2.24.0-2014.09/bfd/elf32-arm.c:7710 /var/lib/jenkins/jobs/github_Bootloader-Builder/workspace/dl/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-ld.bfd: error: required section '.rel.plt' not found in the linker script /var/lib/jenkins/jobs/github_Bootloader-Builder/workspace/dl/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-ld.bfd: final link failed: Invalid operation Makefile:1052: recipe for target 'u-boot' failed make: *** [u-boot] Error 1 Which has a fix: http://git.denx.de/?p=u-boot/u-boot-imx.git;a=summary Looks like we sata: fix reset_sata for dwc_ahsata Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2015.01-rc3 released
On Mon, Dec 8, 2014 at 7:52 PM, Robert Nelson robertcnel...@gmail.com wrote: On Mon, Dec 8, 2014 at 3:44 PM, Tom Rini tr...@ti.com wrote: Hey all, I've pushed v2015.01-rc3 out to the repository and tarballs should exist soon. So, we're nearing the end now, relatively speaking, so things should start getting quieter. I'd like everyone to please build their respective areas and make sure everything is building right. As always, if anything else is broken please speak up. On mx53loco_defconfig I'm getting: drivers/built-in.o: In function `reset_sata': /var/lib/jenkins/jobs/github_Bootloader-Builder/workspace/scratch/u-boot/drivers/block/dwc_ahsata.c:611: undefined reference to `disable_sata_clock' /var/lib/jenkins/jobs/github_Bootloader-Builder/workspace/dl/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-ld.bfd: BFD (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) 2.24.0.20140829 Linaro 2014.09 assertion fail /cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/src/binutils-linaro-2.24.0-2014.09/bfd/elf32-arm.c:7710 /var/lib/jenkins/jobs/github_Bootloader-Builder/workspace/dl/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-ld.bfd: error: required section '.rel.plt' not found in the linker script /var/lib/jenkins/jobs/github_Bootloader-Builder/workspace/dl/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-ld.bfd: final link failed: Invalid operation Makefile:1052: recipe for target 'u-boot' failed make: *** [u-boot] Error 1 Which has a fix: http://git.denx.de/?p=u-boot/u-boot-imx.git;a=summary (oh gmail and the evil cltr-enter shortcut...) This commit: http://git.denx.de/?p=u-boot/u-boot-imx.git;a=commit;h=dd1c8f1b5fb63a682fce62a53464108d8587b0a2 Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ti, am3517: errata 430973 workaround
On Mon, Dec 8, 2014 at 4:19 PM, Jeroen Hofstee jer...@myspectrum.nl wrote: Hi, A while ago [1], a RFC was posted to disable workaround for besides others, errata 430973. It is a bit unclear to me which revision actually need this workaround, but as suggested in [2] also enabling this workaround in Linux seem to make some weird problems go away in linux (signal 4, bad instruction, 11 segfaults etc). As said, I am a bit in doubt why this works. The board in question is a tam3517 derived one: cat /proc/cpuinfo Processor: ARMv7 Processor rev 7 (v7l) BogoMIPS: 397.57 Features: swp half thumb fastmult vfp edsp neon vfpv3 tls CPU implementer: 0x41 CPU architecture: 7 CPU variant: 0x1 CPU part: 0xc08 CPU revision: 7 Which makes this a r1p7 I assume, and hence the workaround of linux, CONFIG_ARM_ERRATA_430973, This option enables the workaround for the 430973 Cortex-A8 (r1p0..r1p2) erratum, should not be needed it seems. Digging thru my old beagle notes 430973 is also needed for r1p3 (dm3730/bb-xm), so that config option was never updated since the errata was first discovered in r1p2 devices.. Fixed in r2p1 sounds about right, as i know for sure it works fine in 'r3p2' (am335x/bbb) Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/13] ARM: atmel: sama5d4_xplained: enable spl support
a/configs/sama5d4_xplained_spiflash_defconfig b/configs/sama5d4_xplained_spiflash_defconfig index 3a4607c..755dd8b 100644 --- a/configs/sama5d4_xplained_spiflash_defconfig +++ b/configs/sama5d4_xplained_spiflash_defconfig @@ -1,3 +1,4 @@ +CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS=SAMA5D4,SYS_USE_SERIALFLASH +S:CONFIG_ARM=y +S:CONFIG_TARGET_SAMA5D4_XPLAINED=y diff --git a/include/configs/sama5d4_xplained.h b/include/configs/sama5d4_xplained.h index 996973d..6d70bc9 100644 --- a/include/configs/sama5d4_xplained.h +++ b/include/configs/sama5d4_xplained.h @@ -20,7 +20,9 @@ #define CONFIG_ARCH_CPU_INIT +#ifndef CONFIG_SPL_BUILD #define CONFIG_SKIP_LOWLEVEL_INIT +#endif #define CONFIG_BOARD_EARLY_INIT_F #define CONFIG_DISPLAY_CPUINFO @@ -66,8 +68,12 @@ #define CONFIG_SYS_SDRAM_BASE ATMEL_BASE_DDRCS #define CONFIG_SYS_SDRAM_SIZE 0x2000 +#ifdef CONFIG_SPL_BUILD +#define CONFIG_SYS_INIT_SP_ADDR0x21 +#else #define CONFIG_SYS_INIT_SP_ADDR \ (CONFIG_SYS_SDRAM_BASE + 4 * 1024 - GENERATED_GBL_DATA_SIZE) +#endif #define CONFIG_SYS_LOAD_ADDR 0x2200 /* load address */ @@ -221,4 +227,54 @@ /* Size of malloc() pool */ #define CONFIG_SYS_MALLOC_LEN (4 * 1024 * 1024) + +/* SPL */ +#define CONFIG_SPL_FRAMEWORK +#define CONFIG_SPL_TEXT_BASE 0x20 +#define CONFIG_SPL_MAX_SIZE0x1 +#define CONFIG_SPL_BSS_START_ADDR 0x2000 +#define CONFIG_SPL_BSS_MAX_SIZE0x8 +#define CONFIG_SYS_SPL_MALLOC_START0x2008 +#define CONFIG_SYS_SPL_MALLOC_SIZE 0x8 + +#define CONFIG_SPL_LIBCOMMON_SUPPORT +#define CONFIG_SPL_LIBGENERIC_SUPPORT +#define CONFIG_SPL_GPIO_SUPPORT +#define CONFIG_SPL_SERIAL_SUPPORT + +#define CONFIG_SPL_BOARD_INIT +#define CONFIG_SYS_MONITOR_LEN (512 10) + +#ifdef CONFIG_SYS_USE_MMC +#define CONFIG_SPL_LDSCRIPT arch/arm/cpu/at91-common/u-boot-spl.lds +#define CONFIG_SPL_MMC_SUPPORT +#define CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS 0x400 +#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR 0x200 +#define CONFIG_SYS_MMC_SD_FS_BOOT_PARTITION1 Hi Bo, You have an extra _ there: (MMC_SD) - (MMCSD), it should be: #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1 build error: common/spl/spl_mmc.c: In function ‘spl_mmc_load_image’: common/spl/spl_mmc.c:135:6: error: ‘CONFIG_SYS_MMCSD_FS_BOOT_PARTITION’ undeclared (first use in this function) CONFIG_SYS_MMCSD_FS_BOOT_PARTITION, ^ common/spl/spl_mmc.c:135:6: note: each undeclared identifier is reported only once for each function it appears in scripts/Makefile.build:275: recipe for target 'spl/common/spl/spl_mmc.o' failed make[2]: *** [spl/common/spl/spl_mmc.o] Error 1 scripts/Makefile.spl:212: recipe for target 'spl/common/spl' failed make[1]: *** [spl/common/spl] Error 2 make[1]: *** Waiting for unfinished jobs Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/13] ARM: atmel: sama5d4ek: enable SPL support
Same here: +#ifdef CONFIG_SYS_USE_MMC +#define CONFIG_SPL_LDSCRIPT arch/arm/cpu/at91-common/u-boot-spl.lds +#define CONFIG_SPL_MMC_SUPPORT +#define CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS 0x400 +#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR 0x200 +#define CONFIG_SYS_MMC_SD_FS_BOOT_PARTITION1 ^^ #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION1 Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/13] ARM: atmel: sama5d4_xplained: enable spl support
On Wed, Dec 10, 2014 at 7:29 PM, Bo Shen voice.s...@atmel.com wrote: Hi Robert Nelson, On 12/11/2014 09:21 AM, Bo Shen wrote: Hi Robert Nelson, On 12/11/2014 05:35 AM, Robert Nelson wrote: + +#ifdef CONFIG_SYS_USE_MMC +#define CONFIG_SPL_LDSCRIPT arch/arm/cpu/at91-common/u-boot-spl.lds +#define CONFIG_SPL_MMC_SUPPORT +#define CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS 0x400 +#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR 0x200 +#define CONFIG_SYS_MMC_SD_FS_BOOT_PARTITION1 Hi Bo, You have an extra _ there: (MMC_SD) - (MMCSD), it should be: #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1 build error: common/spl/spl_mmc.c: In function ‘spl_mmc_load_image’: common/spl/spl_mmc.c:135:6: error: ‘CONFIG_SYS_MMCSD_FS_BOOT_PARTITION’ undeclared (first use in this function) CONFIG_SYS_MMCSD_FS_BOOT_PARTITION, ^ common/spl/spl_mmc.c:135:6: note: each undeclared identifier is reported only once for each function it appears in scripts/Makefile.build:275: recipe for target 'spl/common/spl/spl_mmc.o' failed make[2]: *** [spl/common/spl/spl_mmc.o] Error 1 scripts/Makefile.spl:212: recipe for target 'spl/common/spl' failed make[1]: *** [spl/common/spl] Error 2 make[1]: *** Waiting for unfinished jobs Do you test this patch series based on u-boot master branch? I use git grep CONFIG_SYS_MMCSD_FS_BOOT_PARTITION, and don't find any information about it. Using git grep CONFIG_SYS_MMC_SD_FS_BOOT_PARTITION show many files use it. And the following commit introduced this name: ---8--- commit 205b4f33cfe58268df7d433f2da515fe660afd9c Author: Guillaume GARDET guillaume.gar...@free.fr Date: Wed Oct 15 17:53:11 2014 +0200 Rename some defines containing FAT in their name to be filesystem generic Rename some defines containing FAT in their name to be filesystem generic: MMCSD_MODE_FAT = MMCSD_MODE_FS CONFIG_SPL_FAT_LOAD_ARGS_NAME = CONFIG_SPL_FS_LOAD_ARGS_NAME CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME = CONFIG_SPL_FS_LOAD_PAYLOAD_NAME CONFIG_SYS_MMC_SD_FAT_BOOT_PARTITION = CONFIG_SYS_MMC_SD_FS_BOOT_PARTITION Signed-off-by: Guillaume GARDET guillaume.gar...@free.fr Cc: Tom Rini tr...@ti.com ---8--- Sorry for the noise, just now, I fetch the u-boot master branch and find this name is changed again in the following commit: ---8--- commit e2ccdf89a0196b40b445700670777ebee231756d Author: Paul Kocialkowski cont...@paulk.fr Date: Sat Nov 8 23:14:55 2014 +0100 MMC SD fs boot partition config coding style and proper description CONFIG_SYS_MMC_SD_FS_BOOT_PARTITION ought to be called CONFIG_SYS_MMCSD_FS_BOOT_PARTITION to keep it consistent with other config options such as: CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR. In addition, it is not related to raw mode booting but to fs mode instead. Signed-off-by: Paul Kocialkowski cont...@paulk.fr Reviewed-by: Tom Rini tr...@ti.com ---8--- Thanks, I will rebase it to u-boot latest master branch and will fix it in v2 version. Ouch, i was just on master and didn't check git history... Wow two renames of that variable in master!!!. ;) Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: if MMCSD_MODE_RAW fails, try MMCSD_MODE_FS, if available
On Tue, Nov 18, 2014 at 3:44 AM, Guillaume GARDET
guillaume.gar...@free.fr wrote:
In SPL MMC, boot modes are exclusive. So, if MMCSD_MODE_RAW fails, the board
hangs. This patch allows to
try MMCSD_MODE_FS then, if available.
It has been tested on a pandaboard (rev. A3).
HI Guillaume,
What mode did you test this is? (RAW or FS)
In Raw Mode with the omap5_uevm beaglebone black, i've had to revert
this. (I'm using RAW mode by default)
U-Boot SPL 2015.01-rc3-dirty (Dec 08 2014 - 20:04:01)
OMAP5432 ES2.0
SPL: Please implement spl_start_uboot() for your board
SPL: Direct Linux boot not active!
spl: wrong MMC boot mode
### ERROR ### Please RESET the board ###
Disk setup, I'm using
sudo dd if=/dev/zero of=${DISK} bs=1M count=10
sudo dd if=./u-boot/MLO of=${DISK} count=1 seek=1 conv=notrunc bs=128k
sudo dd if=./u-boot/u-boot.img of=${DISK} count=2 seek=1 conv=notrunc bs=384k
sudo sfdisk --in-order --Linux --unit M ${DISK} -__EOF__
1,,0x83,*
__EOF__
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: mmc: Fix raw boot mode (related to commit 4c5bbc2328a24f5e1ee990c9a9527e48e5fb3b5f)
On Tue, Dec 16, 2014 at 5:00 AM, Guillaume GARDET guillaume.gar...@free.fr wrote: As reported by Robert Nelson, commit 4c5bbc2328a24f5e1ee990c9a9527e48e5fb3b5f may break MMC RAW boot mode. This patch fixes the check path to fix MMC Raw boot mode. Tested raw boot mode and FS boot mode on a pandaboard (rev. A3). Reported-by: Robert Nelson robertcnel...@gmail.com Signed-off-by: Guillaume GARDET guillaume.gar...@free.fr Cc: Tom Rini tr...@ti.com Cc: Robert Nelson robertcnel...@gmail.com Thanks Guillaume! Tested in raw fs mode on a beaglebone black (microSD eMMC) Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: mmc: Fix raw boot mode (related to commit 4c5bbc2328a24f5e1ee990c9a9527e48e5fb3b5f)
On Tue, Dec 16, 2014 at 11:43 AM, Guillaume Gardet guillaume.gar...@free.fr wrote: Le 16/12/2014 18:16, Robert Nelson a écrit : On Tue, Dec 16, 2014 at 5:00 AM, Guillaume GARDET guillaume.gar...@free.fr wrote: As reported by Robert Nelson, commit 4c5bbc2328a24f5e1ee990c9a9527e48e5fb3b5f may break MMC RAW boot mode. This patch fixes the check path to fix MMC Raw boot mode. Tested raw boot mode and FS boot mode on a pandaboard (rev. A3). Reported-by: Robert Nelson robertcnel...@gmail.com Signed-off-by: Guillaume GARDET guillaume.gar...@free.fr Tested-by: Robert Nelson robertcnel...@gmail.com Cc: Tom Rini tr...@ti.com Cc: Robert Nelson robertcnel...@gmail.com Thanks Guillaume! Tested in raw fs mode on a beaglebone black (microSD eMMC) Thanks for testing it. :) You could add your tested by tag. I always forget. ;) Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] mx6cuboxi: Add HDMI output support
On Wed, Apr 29, 2015 at 3:02 PM, Vagrant Cascadian vagr...@aikidev.net wrote: On 2015-04-27, Fabio Estevam wrote: Add HDMI output using PLL5 as the source for the IPU DI clocks, and accurate VESA timings. These settings are based on the patch from Soeren Moch sm...@web.de submitted for the tbs2910 mx6 based board. It allows the display to work properly at 1024x768@60. This should make the hdmi output signal compatible with most if not all modern displays. I wasn't able to test this as the HDMI TV I'm using doesn't support this resolution (it is admittedly ~9 years old, the closest resolution it does support is 1280x720@60). How complicated would it be to support multiple resolutions? There's edid support in the sunxi display driver.. live well, vagrant ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] mx6cuboxi: Add HDMI output support
On Wed, Apr 29, 2015 at 3:02 PM, Vagrant Cascadian vagr...@aikidev.net wrote: On 2015-04-27, Fabio Estevam wrote: Add HDMI output using PLL5 as the source for the IPU DI clocks, and accurate VESA timings. These settings are based on the patch from Soeren Moch sm...@web.de submitted for the tbs2910 mx6 based board. It allows the display to work properly at 1024x768@60. This should make the hdmi output signal compatible with most if not all modern displays. I wasn't able to test this as the HDMI TV I'm using doesn't support this resolution (it is admittedly ~9 years old, the closest resolution it does support is 1280x720@60). How complicated would it be to support multiple resolutions? (Sorry about the double post.. gmail..) There's edid support in the sunxi_display driver: http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/video/sunxi_display.c;hb=HEAD#l188 Could pull it out as a share it. Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] udoo: Switch to SPL support
Just a quick comment, otherwise tested on my udoo quad/dual..
diff --git a/include/configs/udoo.h b/include/configs/udoo.h
index 910bf01..f93b67a 100644
--- a/include/configs/udoo.h
+++ b/include/configs/udoo.h
@@ -11,6 +11,10 @@
#include mx6_common.h
+#define CONFIG_SPL_MMC_SUPPORT
+#define CONFIG_SPL_FAT_SUPPORT
So ^ this forces use to include u-boot.img in a FAT partition..
For extX, you'd have to add:
#define CONFIG_SPL_EXT_SUPPORT
But, this also breaks if you had dd'ed SPL/u-boot.img..
U-Boot SPL 2015.10-rc1-1-gc195aa3 (Aug 03 2015 - 17:48:55)
spl_register_fat_device: fat register err - -1
spl_load_image_fat: error reading image u-boot.img, err - -1
spl: mmc: no boot mode left to try
### ERROR ### Please RESET the board ###
sudo dd if=./u-boot/SPL of=${DISK} seek=1 bs=1k
sudo dd if=./u-boot/u-boot.img of=${DISK} seek=69 bs=1k
Shouldn't we just not enable either and do like the wandboard and just
dd SPL/u-boot.img?
Regards,
--
Robert Nelson
https://rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2015.07 released
On Tue, Jul 14, 2015 at 3:24 PM, Nikolay Dimitrov picmas...@mail.bg wrote: Hi Tom, On 07/14/2015 11:14 PM, Peter Robinson wrote: Hi Tom, On Tue, Jul 14, 2015 at 6:56 PM, Tom Rini tr...@konsulko.com wrote: Hey all, I've pushed v2015.07 out to the repository and tarballs should exist soon. I don't see the release tag in git either by doing a pull from my checkout or via the web interface. Does it take time to sync? Peter Same here, the release tag is missing. The public repo is on a 6 hour cron job, give it a few more hours.. Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] board/ti/am335x: beaglebone stop muxing i2c1_pin_mux
On the BeagleBone these i2c1 pins are routed to the expanasion header, where
they can be defined as either pr1_usart0_Xxd/pwm0/spi0/i2c1, dont assume i2c1
Fixes: https://e2e.ti.com/support/arm/sitara_arm/f/791/p/313894/1387696
Signed-off-by: Robert Nelson <robertcnel...@gmail.com>
Reported-by: Matthijs van Duin <matthijsvand...@gmail.com>
CC: Tom Rini <tr...@konsulko.com>
---
board/ti/am335x/mux.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/board/ti/am335x/mux.c b/board/ti/am335x/mux.c
index 680f656..fd3da58 100644
--- a/board/ti/am335x/mux.c
+++ b/board/ti/am335x/mux.c
@@ -317,7 +317,6 @@ void enable_board_pin_mux(struct am335x_baseboard_id
*header)
/* Do board-specific muxes. */
if (board_is_bone(header)) {
/* Beaglebone pinmux */
- configure_module_pin_mux(i2c1_pin_mux);
configure_module_pin_mux(mii1_pin_mux);
configure_module_pin_mux(mmc0_pin_mux);
#if defined(CONFIG_NAND)
@@ -356,7 +355,6 @@ void enable_board_pin_mux(struct am335x_baseboard_id
*header)
configure_module_pin_mux(mmc0_pin_mux_sk_evm);
} else if (board_is_bone_lt(header)) {
/* Beaglebone LT pinmux */
- configure_module_pin_mux(i2c1_pin_mux);
configure_module_pin_mux(mii1_pin_mux);
configure_module_pin_mux(mmc0_pin_mux);
#if defined(CONFIG_NAND) && defined(CONFIG_EMMC_BOOT)
--
2.6.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] board/ti/am335x: add support for BeagleBone Green
SeeedStudio BeagleBone Green (BBG) is clone of the BeagleBone Black (BBB) minus
the HDMI port and addition of two Grove connectors (i2c2 and usart2).
This board can be identified by the 1A value after A335BNLT (BBB) in the at24
eeprom:
1A: [aa 55 33 ee 41 33 33 35 42 4e 4c 54 1a 00 00 00 |.U3.A335BNLT|]
http://beagleboard.org/green
http://www.seeedstudio.com/wiki/Beaglebone_green
In Mainline Kernel as of:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=79a4e64c679d8a0b1037da174e4aea578c80c4e6
Patch tested on BeagleBone Black (rev C) and BeagleBone Green (production model)
Signed-off-by: Robert Nelson <robertcnel...@gmail.com>
CC: Tom Rini <tr...@konsulko.com>
CC: Jason Kridner <jkrid...@gmail.com>
---
board/ti/am335x/board.c | 12 +---
include/configs/am335x_evm.h | 7 ++-
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index f0cb1e2..f56d17e 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -507,9 +507,15 @@ int board_late_init(void)
safe_string[sizeof(header.name)] = 0;
setenv("board_name", safe_string);
- strncpy(safe_string, (char *)header.version, sizeof(header.version));
- safe_string[sizeof(header.version)] = 0;
- setenv("board_rev", safe_string);
+ /* BeagleBone Green eeprom, board_rev: 0x1a 0x00 0x00 0x00 */
+ if ( (header.version[0] == 0x1a) && (header.version[1] == 0x00) &&
+(header.version[2] == 0x00) && (header.version[3] == 0x00) ) {
+ setenv("board_rev", "BBG1");
+ } else {
+ strncpy(safe_string, (char *)header.version,
sizeof(header.version));
+ safe_string[sizeof(header.version)] = 0;
+ setenv("board_rev", safe_string);
+ }
#endif
return 0;
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index d58816d..ed3fd34 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -186,7 +186,12 @@
"if test $board_name = A335BONE; then " \
"setenv fdtfile am335x-bone.dtb; fi; " \
"if test $board_name = A335BNLT; then " \
- "setenv fdtfile am335x-boneblack.dtb; fi; " \
+ "if test $board_rev = BBG1; then " \
+ "setenv fdtfile am335x-bonegreen.dtb; " \
+ "else " \
+ "setenv fdtfile am335x-boneblack.dtb; " \
+ "fi; " \
+ "fi; " \
"if test $board_name = A33515BB; then " \
"setenv fdtfile am335x-evm.dtb; fi; " \
"if test $board_name = A335X_SK; then " \
--
2.6.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] mkimage: mxs (mx23_olinuxino) build regression
Hi Simon,
I've just finished bisecting a build error for the mx23_olinuxino platform.
git bisect points to:
http://git.denx.de/?p=u-boot.git;a=commit;h=92a655c326b22de58dcd5371ca1a62fdc57f8e04
to build:
make ARCH=arm CROSS_COMPILE=${CC} distclean
make ARCH=arm CROSS_COMPILE=${CC} mx23_olinuxino_defconfig
make ARCH=arm CROSS_COMPILE=${CC} u-boot.sb
Build error:
CFG spl/u-boot-spl.cfg
MKIMAGE u-boot.sb
./tools/mkimage: Can't open (null): Bad address
arch/arm/cpu/arm926ejs/mxs/Makefile:82: recipe for target 'u-boot.sb' failed
make[1]: *** [u-boot.sb] Error 1
Makefile:989: recipe for target 'u-boot.sb' failed
make: *** [u-boot.sb] Error 2
Reverting that commit and building show the target booting just fine:
HTLCLC
U-Boot 2015.10-rc2-00305-g8304793 (Sep 02 2015 - 14:40:06 -0500)
CPU: Freescale i.MX23 rev1.4 at 454 MHz
BOOT: SSP SD/MMC #0
DRAM: 64 MiB
MMC: MXS MMC: 0
*** Warning - bad CRC, using default environment
In:serial
Out: serial
Err: serial
Net: Net Initialization Skipped
No ethernet found.
Regards,
--
Robert Nelson
https://rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mkimage: mxs (mx23_olinuxino) build regression
On Wed, Sep 2, 2015 at 3:52 PM, Otavio Salvador <otavio.salva...@ossystems.com.br> wrote: > On Wed, Sep 2, 2015 at 4:48 PM, Robert Nelson <robertcnel...@gmail.com> wrote: >> I've just finished bisecting a build error for the mx23_olinuxino platform. >> >> git bisect points to: >> >> http://git.denx.de/?p=u-boot.git;a=commit;h=92a655c326b22de58dcd5371ca1a62fdc57f8e04 > > I think it has been fixed and merged today in master. Thanks you are right! The fix is in u-boot-imx.git master http://git.denx.de/?p=u-boot/u-boot-imx.git;a=shortlog;h=refs/heads/master so when u-boot.git master pushes that pull it'll be fine.. Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot 2016.01-rc2 detects BeagleBone Black incorrectly
Hi Matwey On Sat, Dec 12, 2015 at 3:14 AM, Matwey V. Kornilov <matwey.korni...@gmail.com> wrote: > Hello, > > I am running 2016.01-rc on BBB (Embest replica) > > printenv shows the following: > > findfdt=if test $board_name = A335BONE; then setenv fdtfile > am335x-bone.dtb; fi; if test $board_name = A335BNLT; then if test > $board_rev = BBG1; then setenv fdtfile am335x-bonegreen.dtb; else setenv > fdtfile am335x-boneblack.dtb; fi; fi; if test $board_name = A33515BB; > then setenv fdtfile am335x-evm.dtb; fi; if test $board_name = A335X_SK; > then setenv fdtfile am335x-evmsk.dtb; fi; if test $fdtfile = undefined; > then echo WARNING: Could not determine device tree to use; fi; > > after findfdt has been run, > > fdtfile=am335x-bonegreen.dtb > > But it is not correct. My $board_rev is the following, I have no idea > why does it contain line break. > > board_name=A335BNLT > board_rev=t\ Yuck, another variation! Can you do me a favor and dump the eeprom: https://github.com/beagleboard/image-builder/blob/master/readme.md Download and run: wget https://raw.githubusercontent.com/RobertCNelson/boot-scripts/master/device/bone/tester/show-eeprom.sh sudo /bin/bash show-eeprom.sh It uses hexdump and compatible with bb.org' 3.8/4.1/etc.. The green should only trigger on: 0x1a 0x00 0x00 0x00 http://git.denx.de/?p=u-boot.git;a=blobdiff;f=board/ti/am335x/board.c;h=f56d17ec58e17a6532b5df649249b4038b475897;hp=f0cb1e204ad550622df7848a993f1eb2f173bc43;hb=dfd1bb4ec89e8b1e87f0605af2345ad6dcf777da;hpb=e4aa8edb6e5cae256a5c5a3c5cd30e05e8f5a2b4 Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot 2016.01-rc2 detects BeagleBone Black incorrectly
On Thu, Dec 17, 2015 at 11:54 AM, Matwey V. Kornilov <matwey.korni...@gmail.com> wrote: > 2015-12-17 3:53 GMT+03:00 Robert Nelson <robertcnel...@gmail.com>: >> Hi Matwey >> >> On Sat, Dec 12, 2015 at 3:14 AM, Matwey V. Kornilov >> <matwey.korni...@gmail.com> wrote: >>> Hello, >>> >>> I am running 2016.01-rc on BBB (Embest replica) >>> >>> printenv shows the following: >>> >>> findfdt=if test $board_name = A335BONE; then setenv fdtfile >>> am335x-bone.dtb; fi; if test $board_name = A335BNLT; then if test >>> $board_rev = BBG1; then setenv fdtfile am335x-bonegreen.dtb; else setenv >>> fdtfile am335x-boneblack.dtb; fi; fi; if test $board_name = A33515BB; >>> then setenv fdtfile am335x-evm.dtb; fi; if test $board_name = A335X_SK; >>> then setenv fdtfile am335x-evmsk.dtb; fi; if test $fdtfile = undefined; >>> then echo WARNING: Could not determine device tree to use; fi; >>> >>> after findfdt has been run, >>> >>> fdtfile=am335x-bonegreen.dtb >>> >>> But it is not correct. My $board_rev is the following, I have no idea >>> why does it contain line break. >>> >>> board_name=A335BNLT >>> board_rev=t\ >> >> Yuck, another variation! Can you do me a favor and dump the eeprom: >> >> https://github.com/beagleboard/image-builder/blob/master/readme.md >> >> Download and run: >> >> wget >> https://raw.githubusercontent.com/RobertCNelson/boot-scripts/master/device/bone/tester/show-eeprom.sh >> >> sudo /bin/bash show-eeprom.sh > > # sudo /bin/bash show-eeprom.sh > eeprom: [�U3�A335BNLTt > ue] > eeprom raw: [ aa 55 33 ee 41 33 33 35 42 4e 4c 54 74 0a 75 > 65 |.U3.A335BNLTt.ue|] ah, it's tripping on the "." = "0a" character.. Do you happen to remember where you purchased it and what it was called.. (for git commit) This patch should work: https://gist.github.com/RobertCNelson/21f44591c78daed7c637 Please test, and i've added it to our table: https://github.com/RobertCNelson/omap-image-builder/commit/620ebf627d3df8c693845bef07af232aa289ff41 Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] omap4_panda: Convert to config_distro_bootcmd.h
On Thu, Dec 10, 2015 at 3:46 PM, Tom Rini <tr...@konsulko.com> wrote: > Based on the am335x_evm conversion, switch to config_distro_bootcmd for > mmc and pxe. Tested with Fedora 23. > > Signed-off-by: Tom Rini <tr...@konsulko.com> > --- > include/configs/ti_omap4_common.h | 51 > - > 1 file changed, 27 insertions(+), 24 deletions(-) > > diff --git a/include/configs/ti_omap4_common.h > b/include/configs/ti_omap4_common.h > index 08130eb..8b6c065 100644 > --- a/include/configs/ti_omap4_common.h > +++ b/include/configs/ti_omap4_common.h > @@ -82,6 +82,32 @@ > /* > * Environment setup > */ > +#define BOOTENV_DEV_LEGACY_MMC(devtypeu, devtypel, instance) \ > + "bootcmd_" #devtypel #instance "=" \ > + "setenv mmcdev " #instance"; "\ > + "setenv bootpart " #instance":2 ; "\ > + "run mmcboot\0" > + > +#define BOOTENV_DEV_NAME_LEGACY_MMC(devtypeu, devtypel, instance) \ > + #devtypel #instance " " > + > +#define BOOTENV_DEV_NAME_NAND(devtypeu, devtypel, instance) \ > + #devtypel #instance " " > + > +#define BOOT_TARGET_DEVICES(func) \ > + func(MMC, mmc, 0) \ > + func(LEGACY_MMC, legacy_mmc, 0) \ > + func(MMC, mmc, 1) \ > + func(LEGACY_MMC, legacy_mmc, 1) \ I don't remember the panda having a 2nd mmc card slot, are there other omap4's with this feature? Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] omap4_panda: Convert to config_distro_bootcmd.h
On Thu, Dec 10, 2015 at 4:58 PM, Robert Nelson <robertcnel...@gmail.com> wrote: > On Thu, Dec 10, 2015 at 3:46 PM, Tom Rini <tr...@konsulko.com> wrote: >> Based on the am335x_evm conversion, switch to config_distro_bootcmd for >> mmc and pxe. Tested with Fedora 23. >> >> Signed-off-by: Tom Rini <tr...@konsulko.com> >> --- >> include/configs/ti_omap4_common.h | 51 >> - >> 1 file changed, 27 insertions(+), 24 deletions(-) >> >> diff --git a/include/configs/ti_omap4_common.h >> b/include/configs/ti_omap4_common.h >> index 08130eb..8b6c065 100644 >> --- a/include/configs/ti_omap4_common.h >> +++ b/include/configs/ti_omap4_common.h >> @@ -82,6 +82,32 @@ >> /* >> * Environment setup >> */ >> +#define BOOTENV_DEV_LEGACY_MMC(devtypeu, devtypel, instance) \ >> + "bootcmd_" #devtypel #instance "=" \ >> + "setenv mmcdev " #instance"; "\ >> + "setenv bootpart " #instance":2 ; "\ >> + "run mmcboot\0" >> + >> +#define BOOTENV_DEV_NAME_LEGACY_MMC(devtypeu, devtypel, instance) \ >> + #devtypel #instance " " >> + >> +#define BOOTENV_DEV_NAME_NAND(devtypeu, devtypel, instance) \ >> + #devtypel #instance " " >> + >> +#define BOOT_TARGET_DEVICES(func) \ >> + func(MMC, mmc, 0) \ >> + func(LEGACY_MMC, legacy_mmc, 0) \ >> + func(MMC, mmc, 1) \ >> + func(LEGACY_MMC, legacy_mmc, 1) \ > > I don't remember the panda having a 2nd mmc card slot, are there other > omap4's with this feature? ahh the omap4-sdp did, since this is ti_omap4_common.h that's fine.. Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot 2016.01-rc2 detects BeagleBone Black incorrectly
>> ah, it's tripping on the "." = "0a" character.. >> >> Do you happen to remember where you purchased it and what it was >> called.. (for git commit) >> >> This patch should work: >> >> https://gist.github.com/RobertCNelson/21f44591c78daed7c637 >> > > The patch works good. > But could you please explain me? I thought the problem was in 'test' operator. > Unlikely > test '\0x74\0x0a\0x75\0x65' = BBG1 > should be true. I saw this when i first booted the Green with the production eeprom, "test" doesn't seem to like non printable characters.. Sorry i didn't look into "test" much further.. Instead i just worked around it with the Green.. Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot for AM5728
On Fri, Nov 20, 2015 at 11:56 PM, chandrashekar p <chanduec...@gmail.com> wrote: > Hello, > > I'm using AM5728 EVM board, to use u-boot boot loader i tried by > downloading the u-boot from other google link. > Their i didn't find the config file for AM5728. > > https://eewiki.net/display/linuxonarm/BeagleBoard-X15#BeagleBoard-X15-Bootloader:U-Boot > > I tried with the below link, it didn't get succeed, got the error. PLease > go through the error file & suggest me how i can come out of this issue. Those directions work fine if you actually follow them: https://gist.github.com/RobertCNelson/4aa9eb1d028237a895a1 > > Please send the link to download where i can get the latest u-boot boot > loader which support for AM5728 EVM board. Please double check what terminal commands you utilized. Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] At start of autoboot check, flush any pending RX bytes
On Thu, Jan 14, 2016 at 11:51 AM, Tom Rini <tr...@konsulko.com> wrote: > On Thu, Jan 14, 2016 at 11:48:07AM -0600, Robert Nelson wrote: > > On Thu, Jan 14, 2016 at 11:31 AM, Tom Rini <tr...@konsulko.com> wrote: > > > > > On Mon, Jan 11, 2016 at 09:59:18AM -0700, Simon Glass wrote: > > > > Hi Craig, > > > > > > > > On 20 December 2015 at 19:07, Craig McQueen > > > > <craig.mcqu...@innerrange.com> wrote: > > > > > This is to avoid the boot sequence halting due to initial "junk" > > > > > received on serial input. > > > > > > > > > > Signed-off-by: Craig McQueen <craig.mcqu...@innerrange.com> > > > > > --- > > > > > I have found that on the BeagleBone Black, U-Boot occasionally > halts at > > > > > the U-Boot prompt at boot-up, whether power-up, warm external > > > > > reset or software reset. I have seen other people report the same > > > issue. > > > > > > > > > > This seems to be due to U-Boot receiving "junk" data on the serial > > > > > console. The BeagleBone Black has a pull-down resistor which was > > > > > apparently added to try to mitigate this issue, but it doesn't > entirely > > > > > fix it. > > > > > > > > I wonder if this can be fixed for that board only? > > > > > > No, and it's not -exactly- a that board only problem. It's a HW design > > > issue that can show up elsewhere too. I _think_ however in this case > > > the answer would be to migrate to perhaps CONFIG_AUTOBOOT_KEYED_CTRLC > as > > > that's one of the reason various other boards use that set of options. > > > > > > I would suggest bringing this up on the beaglebone list to see what the > > > various people that ship and support these boards think, thanks! > > > > > > > I actually enabled this feature this week by default for beagleboard.org > : > > > > diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig > > index 27cb881..8699953 100644 > > --- a/configs/am335x_evm_defconfig > > +++ b/configs/am335x_evm_defconfig > > @@ -3,7 +3,10 @@ CONFIG_TARGET_AM335X_EVM=y > > CONFIG_SPL_STACK_R_ADDR=0x8200 > > CONFIG_SPL=y > > CONFIG_SPL_STACK_R=y > > -CONFIG_SYS_EXTRA_OPTIONS="NAND" > > +CONFIG_AUTOBOOT_KEYED=y > > +CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d seconds\n" > > +CONFIG_AUTOBOOT_DELAY_STR="d" > > +CONFIG_AUTOBOOT_STOP_STR=" " > > # CONFIG_CMD_IMLS is not set > > # CONFIG_CMD_FLASH is not set > > CONFIG_CMD_GPIO=y > > > > It'll take time to replace older images but on target users can just: > > > > cd /opt/scripts/tools/developers/ > > git pull > > sudo ./update_bootloader.sh > > > > U-Boot SPL 2016.01-1-g4eb802e (Jan 13 2016 - 11:14:31) > > Trying to boot from MMC > > bad magic > > > > > > U-Boot 2016.01-1-g4eb802e (Jan 13 2016 - 11:14:31 -0600), Build: > > jenkins-github_Bootloader-Builder-313 > > > >Watchdog enabled > > I2C: ready > > DRAM: 512 MiB > > Reset Source: Global external warm reset has occurred. > > Reset Source: Power-on reset has occurred. > > MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 > > Using default environment > > > > Net:not set. Validating first E-fuse MAC > > cpsw, usb_ether > > Press SPACE to abort autoboot in 2 seconds > > => > > Space eh? OK. Now would be the time to push this upstream as the merge > window just opened :) > That seemed like the most common when i looked at it.. grep -R "AUTOBOOT_PROMPT" configs/*defconfig Do you want me to hit all 3 bbb related configs? beagleboard.org uses: am335x_evm_defconfig I know some users use: am335x_boneblack_defconfig am335x_boneblack_vboot_defconfig Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] At start of autoboot check, flush any pending RX bytes
On Thu, Jan 14, 2016 at 11:31 AM, Tom Rini <tr...@konsulko.com> wrote: > On Mon, Jan 11, 2016 at 09:59:18AM -0700, Simon Glass wrote: > > Hi Craig, > > > > On 20 December 2015 at 19:07, Craig McQueen > > <craig.mcqu...@innerrange.com> wrote: > > > This is to avoid the boot sequence halting due to initial "junk" > > > received on serial input. > > > > > > Signed-off-by: Craig McQueen <craig.mcqu...@innerrange.com> > > > --- > > > I have found that on the BeagleBone Black, U-Boot occasionally halts at > > > the U-Boot prompt at boot-up, whether power-up, warm external > > > reset or software reset. I have seen other people report the same > issue. > > > > > > This seems to be due to U-Boot receiving "junk" data on the serial > > > console. The BeagleBone Black has a pull-down resistor which was > > > apparently added to try to mitigate this issue, but it doesn't entirely > > > fix it. > > > > I wonder if this can be fixed for that board only? > > No, and it's not -exactly- a that board only problem. It's a HW design > issue that can show up elsewhere too. I _think_ however in this case > the answer would be to migrate to perhaps CONFIG_AUTOBOOT_KEYED_CTRLC as > that's one of the reason various other boards use that set of options. > > I would suggest bringing this up on the beaglebone list to see what the > various people that ship and support these boards think, thanks! > I actually enabled this feature this week by default for beagleboard.org: diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig index 27cb881..8699953 100644 --- a/configs/am335x_evm_defconfig +++ b/configs/am335x_evm_defconfig @@ -3,7 +3,10 @@ CONFIG_TARGET_AM335X_EVM=y CONFIG_SPL_STACK_R_ADDR=0x8200 CONFIG_SPL=y CONFIG_SPL_STACK_R=y -CONFIG_SYS_EXTRA_OPTIONS="NAND" +CONFIG_AUTOBOOT_KEYED=y +CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d seconds\n" +CONFIG_AUTOBOOT_DELAY_STR="d" +CONFIG_AUTOBOOT_STOP_STR=" " # CONFIG_CMD_IMLS is not set # CONFIG_CMD_FLASH is not set CONFIG_CMD_GPIO=y It'll take time to replace older images but on target users can just: cd /opt/scripts/tools/developers/ git pull sudo ./update_bootloader.sh U-Boot SPL 2016.01-1-g4eb802e (Jan 13 2016 - 11:14:31) Trying to boot from MMC bad magic U-Boot 2016.01-1-g4eb802e (Jan 13 2016 - 11:14:31 -0600), Build: jenkins-github_Bootloader-Builder-313 Watchdog enabled I2C: ready DRAM: 512 MiB Reset Source: Global external warm reset has occurred. Reset Source: Power-on reset has occurred. MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Using default environment Net:not set. Validating first E-fuse MAC cpsw, usb_ether Press SPACE to abort autoboot in 2 seconds => Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] am335x: BeagleBones enable CONFIG_AUTOBOOT_KEYED
On startup, the BeagleBone family of boards can occationally halt at the U-Boot prompt. Due to U-Boot receiving random data on the usart. Migrate BeagleBone based boards to use CONFIG_AUTOBOOT_KEYED, user will now have to enter the key to get to U-Boot prompt Signed-off-by: Robert Nelson <robertcnel...@gmail.com> CC: Craig McQueen <craig.mcqu...@innerrange.com> CC: Tom Rini <tr...@konsulko.com> --- configs/am335x_boneblack_defconfig | 4 configs/am335x_boneblack_vboot_defconfig | 4 configs/am335x_evm_defconfig | 4 3 files changed, 12 insertions(+) diff --git a/configs/am335x_boneblack_defconfig b/configs/am335x_boneblack_defconfig index 3030a95..8803da5 100644 --- a/configs/am335x_boneblack_defconfig +++ b/configs/am335x_boneblack_defconfig @@ -4,6 +4,10 @@ CONFIG_SPL_STACK_R_ADDR=0x8200 CONFIG_SPL=y CONFIG_SPL_STACK_R=y CONFIG_SYS_EXTRA_OPTIONS="EMMC_BOOT" +CONFIG_AUTOBOOT_KEYED=y +CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d seconds\n" +CONFIG_AUTOBOOT_DELAY_STR="d" +CONFIG_AUTOBOOT_STOP_STR=" " # CONFIG_CMD_IMLS is not set # CONFIG_CMD_FLASH is not set CONFIG_CMD_GPIO=y diff --git a/configs/am335x_boneblack_vboot_defconfig b/configs/am335x_boneblack_vboot_defconfig index ad40b07..5dcb942 100644 --- a/configs/am335x_boneblack_vboot_defconfig +++ b/configs/am335x_boneblack_vboot_defconfig @@ -8,6 +8,10 @@ CONFIG_FIT=y CONFIG_FIT_VERBOSE=y CONFIG_FIT_SIGNATURE=y CONFIG_SYS_EXTRA_OPTIONS="EMMC_BOOT,ENABLE_VBOOT" +CONFIG_AUTOBOOT_KEYED=y +CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d seconds\n" +CONFIG_AUTOBOOT_DELAY_STR="d" +CONFIG_AUTOBOOT_STOP_STR=" " # CONFIG_CMD_IMLS is not set # CONFIG_CMD_FLASH is not set CONFIG_CMD_GPIO=y diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig index 27cb881..7753ab5 100644 --- a/configs/am335x_evm_defconfig +++ b/configs/am335x_evm_defconfig @@ -4,6 +4,10 @@ CONFIG_SPL_STACK_R_ADDR=0x8200 CONFIG_SPL=y CONFIG_SPL_STACK_R=y CONFIG_SYS_EXTRA_OPTIONS="NAND" +CONFIG_AUTOBOOT_KEYED=y +CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d seconds\n" +CONFIG_AUTOBOOT_DELAY_STR="d" +CONFIG_AUTOBOOT_STOP_STR=" " # CONFIG_CMD_IMLS is not set # CONFIG_CMD_FLASH is not set CONFIG_CMD_GPIO=y -- 2.6.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] At start of autoboot check, flush any pending RX bytes
On Tue, Jan 19, 2016 at 10:35 PM, Simon Glass <s...@chromium.org> wrote: > Hi, > > On 18 January 2016 at 23:46, Craig McQueen <craig.mcqu...@innerrange.com> > wrote: >>> Tom Rini wrote: >>> >>> On Mon, Jan 11, 2016 at 09:59:18AM -0700, Simon Glass wrote: >>> > Hi Craig, >>> > >>> > On 20 December 2015 at 19:07, Craig McQueen >>> > <craig.mcqu...@innerrange.com> wrote: >>> > > This is to avoid the boot sequence halting due to initial "junk" >>> > > received on serial input. >>> > > >>> > > Signed-off-by: Craig McQueen <craig.mcqu...@innerrange.com> >>> > > --- >>> > > I have found that on the BeagleBone Black, U-Boot occasionally halts >>> > > at the U-Boot prompt at boot-up, whether power-up, warm external >>> > > reset or software reset. I have seen other people report the same issue. >>> > > >>> > > This seems to be due to U-Boot receiving "junk" data on the serial >>> > > console. The BeagleBone Black has a pull-down resistor which was >>> > > apparently added to try to mitigate this issue, but it doesn't >>> > > entirely fix it. >>> > >>> > I wonder if this can be fixed for that board only? >>> >>> No, and it's not -exactly- a that board only problem. It's a HW design >>> issue >>> that can show up elsewhere too. I _think_ however in this case the answer >>> would be to migrate to perhaps CONFIG_AUTOBOOT_KEYED_CTRLC as that's >>> one of the reason various other boards use that set of options. >>> >>> I would suggest bringing this up on the beaglebone list to see what the >>> various people that ship and support these boards think, thanks! >> >> Other options such as CONFIG_AUTOBOOT_KEYED_CTRLC sound like a work-around >> of the problem, rather than a fix of the root-cause. But maybe that's just >> my opinion. Simon Glass' suggestion (clear out the UART input buffer when >> the driver is probed) sounded reasonable, but I haven't tried it. > > Since it seems like a hardware bug, we can only have a workaround. A > real fix would involve fixing the root cause, i.e. fixing the > hardware. > >> >> I think BeagleBone Black definitely needs _some_ sort of fix -- currently >> BBB can randomly fail to boot, which isn't good. If my patch isn't wanted, >> then please implement a suitable alternative. > > How about what Tom suggested? Ctrl-C is not likely to happen by accident. This should be good enough for everyone, it'll look for an exact match over serial "" otherwise it'll ignore everything else: http://lists.denx.de/pipermail/u-boot/2016-January/241286.html Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BeagleBone Black: u-boot 2016.03-rc2 worng fdt detection
On Mon, Mar 7, 2016 at 8:55 AM, Robert Nelson <robertcnel...@gmail.com> wrote: > On Mon, Mar 7, 2016 at 4:50 AM, Matwey V. Kornilov > <matwey.korni...@gmail.com> wrote: >> Hello, >> >> I am running u-boot 2016.03-rc2 on BeagleBone Black and it is >> incorrectly detected as BeagleBone Green. >> >> fdtfile=am335x-bonegreen.dtb >> >> => print board_name >> board_name=A335BNLT >> => print board_rev >> board_rev=t >> ue >> >> >> Similar issue was here on 2016.01. > > CC'ing Steven, > > as he's rewritten the eeprom patchset: > > https://patchwork.ozlabs.org/patch/587572/ > > Steven, here's the magical eeprom values this board needs: > > https://gist.github.com/RobertCNelson/21f44591c78daed7c637 > > I've had no luck tracking down another copy of this unique board in > the field for purchase. and here's the older thread: http://lists.denx.de/pipermail/u-boot/2015-December/237604.html The 'test' operator: http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/am335x_evm.h;h=6ebe0b3866f9b137472cc080c9eb8f1e38233186;hb=HEAD#l185 is chocking on the 0x0a character.. Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BeagleBone Black: u-boot 2016.03-rc2 worng fdt detection
On Mon, Mar 7, 2016 at 4:50 AM, Matwey V. Kornilov <matwey.korni...@gmail.com> wrote: > Hello, > > I am running u-boot 2016.03-rc2 on BeagleBone Black and it is > incorrectly detected as BeagleBone Green. > > fdtfile=am335x-bonegreen.dtb > > => print board_name > board_name=A335BNLT > => print board_rev > board_rev=t > ue > > > Similar issue was here on 2016.01. CC'ing Steven, as he's rewritten the eeprom patchset: https://patchwork.ozlabs.org/patch/587572/ Steven, here's the magical eeprom values this board needs: https://gist.github.com/RobertCNelson/21f44591c78daed7c637 I've had no luck tracking down another copy of this unique board in the field for purchase. Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support
On Wed, Apr 27, 2016 at 6:28 PM, Marek Vasut <ma...@denx.de> wrote: > On 04/28/2016 01:16 AM, Tom Rini wrote: > > On Thu, Apr 28, 2016 at 01:06:07AM +0200, Marek Vasut wrote: > > > >> Enable support for booting U-Boot image from filesystem instead of some > >> random offset on the SD card. This makes the board usable by putting the > >> u-boot.img to first partition of the SD card and writing the SPL this > way: > >> $ dd if=u-boot-with-spl.imx of=/dev/sdX seek=2 bs=512 > > > > Wait, you're still writing u-boot + SPL to the device and not just SPL, > > but it's still preferring the filesystem one over the appended one? > > > > Ha, good point. I should've written the 'SPL' file instead, which is > just the SPL without U-Boot. I don't want to install U-Boot to random > offset on the SD card as it has the potential to corrupt data if the > u-boot binary changes in size. > > If I install u-boot image to random offset 138 blocks from the start of > SD card, it will boot that, otherwise it will load from FS. > > I will update the commit message with the correct info, sorry. > Oh, we went thru this last year... http://lists.denx.de/pipermail/u-boot/2015-August/222061.html If your serious about changing "one" i.mx6 board, you need to change them "all". Otherwise leave a 1MB hole on your mmc partition and dd spl/u-boot.img as that works for ti/imx/sunxi... Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support
On Wed, Apr 27, 2016 at 7:54 PM, Tom Rini <tr...@konsulko.com> wrote: > On Thu, Apr 28, 2016 at 02:02:05AM +0200, Marek Vasut wrote: > > On 04/28/2016 01:49 AM, Robert Nelson wrote: > [snip] > > > 1: > > > > > > Yeap, end users like to delete "MLO/u-boot.img" that was in the "fat" > > > boot partition in our production beaglebone images specifically > > > "2014-05-14" which was shipped by default on rev C. Thus > > > soft-bricking/etc boards.. > > > > OK, so because hypothetical user is an idiot, we should use sub-par > > solution ? User can also be an idiot and generate U-Boot which is over 1 > > MiB, in which case I will turn your argument around against you. Sorry, > > I am not buying this. > > No, real users. Lots of them. From nearly every "community" oriented > board ever. Which is why the distros also go for this method, point #2. > > > > http://beagleboard.org/latest-images > > > > > > Moving it under the 1MB location, has solved that problem. > > > > Until u-boot grows over 1 MiB. This only postponed the problem. > > Since there is filesystem support in the SPL, we should use that > > as a superior solution which doesn't suffer from this problem. > > I thought people were supposed to be aligning their first partitions > much higher these days, 4MiB? as the general case for being safe > regardless of the actual flash in the SD card. Setting aside sandbox > which I hope grows extremely large for testing purposes, I really hope > U-Boot + SPL can always stay under 1MiB. Our job is to boot the next > stage. If we get so large in our design of implementing things that we > forget this, we have a problem. > I've followed the 4kb convention and fdisk defaults to 1MB offset: (even thou we aren't dealing spinning disks) https://www.ibm.com/developerworks/library/l-linux-on-4kb-sector-disks/ I haven't looked at the latest eMMC spec, but the eMMC 'boot' sections on current silicon is only 1MB (x2) mmcblk1boot0 179:16 01M 1 disk mmcblk1boot1 179:24 01M 1 disk mmcblk1 179:80 1.8G 0 disk Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: mx6: Enable MMC FS boot support
On Wed, Apr 27, 2016 at 6:41 PM, Marek Vasut <ma...@denx.de> wrote: > On 04/28/2016 01:32 AM, Robert Nelson wrote: > > > > > > On Wed, Apr 27, 2016 at 6:28 PM, Marek Vasut <ma...@denx.de > > <mailto:ma...@denx.de>> wrote: > > > > On 04/28/2016 01:16 AM, Tom Rini wrote: > > > On Thu, Apr 28, 2016 at 01:06:07AM +0200, Marek Vasut wrote: > > > > > >> Enable support for booting U-Boot image from filesystem instead > of some > > >> random offset on the SD card. This makes the board usable by > putting the > > >> u-boot.img to first partition of the SD card and writing the SPL > this way: > > >> $ dd if=u-boot-with-spl.imx of=/dev/sdX seek=2 bs=512 > > > > > > Wait, you're still writing u-boot + SPL to the device and not just > SPL, > > > but it's still preferring the filesystem one over the appended one? > > > > > > > Ha, good point. I should've written the 'SPL' file instead, which is > > just the SPL without U-Boot. I don't want to install U-Boot to random > > offset on the SD card as it has the potential to corrupt data if the > > u-boot binary changes in size. > > > > If I install u-boot image to random offset 138 blocks from the start > of > > SD card, it will boot that, otherwise it will load from FS. > > > > I will update the commit message with the correct info, sorry. > > > > > > Oh, we went thru this last year... > > > > http://lists.denx.de/pipermail/u-boot/2015-August/222061.html > > > > If your serious about changing "one" i.mx6 board, you need to change > > them "all". > > No, I do not have to change and will not change any other boards I > cannot test. > Okay, so if you can't test, are you going to keep an updated database: boardx = boots this way? boardy = boots that way? Otherwise, keep like the other i.mx6's.. Or throw it under a "kconfig" so you can easily enable either mode. > > > Otherwise leave a 1MB hole on your mmc partition and dd spl/u-boot.img > > as that works for ti/imx/sunxi... > > No, this design is utterly broken. If U-Boot grows beyond 1 MiB, it will > corrupt my data, silently. I will not have this. I would much rather see > these broken designs go away and have everyone move to > SPL in random location as mandated by BootROM (unfortunately) and > u-boot.img on a filesystem. That way, u-boot.img can grow and shrink > either way, without endangering any surrounding data. > > Can you give me any argument why writing u-boot.img to random location > on the SD card is better than storing it on a filesystem ? > 1: Yeap, end users like to delete "MLO/u-boot.img" that was in the "fat" boot partition in our production beaglebone images specifically "2014-05-14" which was shipped by default on rev C. Thus soft-bricking/etc boards.. http://beagleboard.org/latest-images Moving it under the 1MB location, has solved that problem. 2: fedora/debian/ubuntu/yocto all expect this board to have these settings.. Regards, -- Robert Nelson https://rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] configs/wandboard.h: fix dtb file name for findfdt.
Hi Adam,
On Mon, Jul 18, 2016 at 10:45 AM, Adam Duskett <adamdusk...@outlook.com>
wrote:
> With the release of kernel 4.1.15 for the imx6 line of processors,
> wandboard now uses imx6q-wandboard-revc1.dtb and
> imx6dl-wandboard-revc1.dtb.
> This patch fixes the naming convention to work with kernel 4.1.15
>
> Signed-off-by: Adam Duskett <adamdusk...@outlook.com>
> ---
> include/configs/wandboard.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
> index 99f5c0c..d41b600 100644
> --- a/include/configs/wandboard.h
> +++ b/include/configs/wandboard.h
> @@ -135,9 +135,9 @@
> "setenv bootargs ${bootargs} ${fbmem}\0" \
> "findfdt="\
> "if test $board_name = C1 && test $board_rev = MX6Q ; then
> " \
> - "setenv fdtfile imx6q-wandboard.dtb; fi; " \
> + "setenv fdtfile imx6q-wandboard-revc1.dtb; fi; " \
> "if test $board_name = C1 && test $board_rev = MX6DL ;
> then " \
> - "setenv fdtfile imx6dl-wandboard.dtb; fi; " \
> + "setenv fdtfile imx6dl-wandboard-revc1.dtb; fi; " \
> "if test $board_name = B1 && test $board_rev = MX6Q ; then
> " \
> "setenv fdtfile imx6q-wandboard-revb1.dtb; fi; " \
> "if test $board_name = B1 && test $board_rev = MX6DL ;
> then " \
>
NAK, This breaks mainline:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/Makefile?id=refs/tags/v4.7-rc7#n338
imx6dl-wandboard.dtb \
imx6dl-wandboard-revb1.dtb \
imx6q-wandboard.dtb \
imx6q-wandboard-revb1.dtb \
Regards,
--
Robert Nelson
https://rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
