Re: [fs/squashfs PATCH v3 2/2] avoid 64-bit divisions on 32-bit

[Mauro Condarelli]

On 10/8/20 9:34 AM, Miquel Raynal wrote:
> Hi Mauro,
>
> Mauro Condarelli  wrote on Thu,  8 Oct 2020 00:30:21
> +0200:
>
>> Use macros in linux/kernel.h to avoid 64-bit divisions.
> s/in/from/?
My command of English language is far from perfect.
I meant those macros are used in Linux kernel.
Feel free to rewrite as needed.

>> These divisions are needed to convert from file length (potentially
>> over 32-bit range) to block number, so result and remainder are
>> guaranteed to fit in 32-bit integers.
>>
>> Some 32bit architectures (notably mipsel) lack an implementation of
>> __udivdi3() compiler helper function in reduced libgcc.
>>
>> Standard strategy is to use macros and do_div() inline.
> You don't use do_div(), here, is it a leftover or do you mean that this
> is a generic solution?
I meant I use the macros in SquashFS code, but macros use
do_div() inline function to do their job.
Should I rephrase to be more explicit?


>> Signed-off-by: Mauro Condarelli 
>> ---
>>
>> Changes in v3:
>> - converted to use DIV_ROUND_(UP|DOWN)_ULL() macros (Miquel Raynal).
>> - split commits to handle unrelated Kconfig warning (Thomas Petazzoni).
>>
>> Changes in v2:
>> - replace division with right shift (Daniel Schwierzeck).
>> - remove vocore2-specific change (Daniel Schwierzeck).
>> - add warning to Kconfig about CONFIG_SYS_MALLOC_LEN (Tom Rini).
>>
>>  fs/squashfs/sqfs.c   | 32 
>>  fs/squashfs/sqfs_inode.c |  7 ---
>>  2 files changed, 20 insertions(+), 19 deletions(-)
>>
>> diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
>> index 15208b4dab..ef9f5e3449 100644
>> --- a/fs/squashfs/sqfs.c
>> +++ b/fs/squashfs/sqfs.c
>> @@ -10,14 +10,14 @@
>>  #include 
>>  #include 
>>  #include 
>> -#include 
>> +#include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>>  #include 
>>  #include 
>>  #include 
>> -#include 
>>  
>>  #include "sqfs_decompressor.h"
>>  #include "sqfs_filesystem.h"
>> @@ -85,10 +85,10 @@ static int sqfs_calc_n_blks(__le64 start, __le64 end, 
>> u64 *offset)
>>  u64 start_, table_size;
>>  
>>  table_size = le64_to_cpu(end) - le64_to_cpu(start);
>> -start_ = le64_to_cpu(start) / ctxt.cur_dev->blksz;
>> +start_ = DIV_ROUND_DOWN_ULL(le64_to_cpu(start), ctxt.cur_dev->blksz);
>>  *offset = le64_to_cpu(start) - (start_ * ctxt.cur_dev->blksz);
>>  
>> -return DIV_ROUND_UP(table_size + *offset, ctxt.cur_dev->blksz);
>> +return (table_size + *offset + ctxt.cur_dev->blksz - 1) >> 
>> ctxt.cur_dev->log2blksz;
This is definitely a leftover.
It should be:

  return DIV_ROUND_UP_ULL(table_size + *offset, ctxt.cur_dev->blksz);

> I don't recall Joao using this kind of structure but I might be wrong.
> Can you just verify that this is not a leftover from a previous change?
I will correct, retest and resend.

> Also, as you state in the commit message, all these divisions serve the
> same purpose: translating a file length to a block number. I think a
> helper would be very nice here, something like
>
>   sqfs_length_to_block_id(ctxt, length);
I will consider it.

>
> Thanks,
> Miquèl
>

[fs/squashfs PATCH v3 1/2] Add warning for dynamic memory usage.

[Mauro Condarelli]

SquashFS may need a large amount of dynamic memory fot its buffers,
especially if and when compression is enabled I got failures with
CONFIG_SYS_MALLOC_LEN < 0x4000.

I found no way to enforce this in Kconfig itself, so I resorted
to ada a warning in help string.

Signed-off-by: Mauro Condarelli 
---

(no changes since v1)

 fs/squashfs/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/squashfs/Kconfig b/fs/squashfs/Kconfig
index 54ab1618f1..7c3f83d007 100644
--- a/fs/squashfs/Kconfig
+++ b/fs/squashfs/Kconfig
@@ -9,3 +9,5 @@ config FS_SQUASHFS
  filesystem use, for archival use (i.e. in cases where a .tar.gz file
  may be used), and in constrained block device/memory systems (e.g.
  embedded systems) where low overhead is needed.
+ WARNING: if compression is enabled SquashFS needs a large amount
+ of dynamic memory; make sure CONFIG_SYS_MALLOC_LEN >= 0x4000.
-- 
2.25.1

[fs/squashfs PATCH v3 0/2] fs/squashfs: avoid 64-bit divisions on 32-bit

[Mauro Condarelli]

Corrected to comply with all reviev comments in v2.

Sorry for the delay, but I was fighting a very bad u-boot misbehavior
which seems completely unrelated to this patchset, I was unsure, but
I made real sure my problems exist with ot without this.

My problem is u-boot seems to become unstable if I have 10 or more
partitons on SD. At first I blamed my patches (10th partiton was what
I used for testing), but problem persists even without patches and
removing 10th (using p6 for SquashFS) errors vanished.
I did not find root cause yet, but it doesn't seem related to this.

Changes in v3:
- converted to use DIV_ROUND_(UP|DOWN)_ULL() macros (Miquel Raynal).
- split commits to handle unrelated Kconfig warning (Thomas Petazzoni).

Changes in v2:
- replace division with right shift (Daniel Schwierzeck).
- remove vocore2-specific change (Daniel Schwierzeck).
- add warning to Kconfig about CONFIG_SYS_MALLOC_LEN (Tom Rini).

Mauro Condarelli (2):
  Add warning for dynamic memory usage.
  avoid 64-bit divisions on 32-bit

 fs/squashfs/Kconfig  |  2 ++
 fs/squashfs/sqfs.c   | 32 
 fs/squashfs/sqfs_inode.c |  7 ---
 3 files changed, 22 insertions(+), 19 deletions(-)

-- 
2.25.1

[fs/squashfs PATCH v3 2/2] avoid 64-bit divisions on 32-bit

[Mauro Condarelli]

Use macros in linux/kernel.h to avoid 64-bit divisions.

These divisions are needed to convert from file length (potentially
over 32-bit range) to block number, so result and remainder are
guaranteed to fit in 32-bit integers.

Some 32bit architectures (notably mipsel) lack an implementation of
__udivdi3() compiler helper function in reduced libgcc.

Standard strategy is to use macros and do_div() inline.

Signed-off-by: Mauro Condarelli 
---

Changes in v3:
- converted to use DIV_ROUND_(UP|DOWN)_ULL() macros (Miquel Raynal).
- split commits to handle unrelated Kconfig warning (Thomas Petazzoni).

Changes in v2:
- replace division with right shift (Daniel Schwierzeck).
- remove vocore2-specific change (Daniel Schwierzeck).
- add warning to Kconfig about CONFIG_SYS_MALLOC_LEN (Tom Rini).

 fs/squashfs/sqfs.c   | 32 
 fs/squashfs/sqfs_inode.c |  7 ---
 2 files changed, 20 insertions(+), 19 deletions(-)

diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
index 15208b4dab..ef9f5e3449 100644
--- a/fs/squashfs/sqfs.c
+++ b/fs/squashfs/sqfs.c
@@ -10,14 +10,14 @@
 #include 
 #include 
 #include 
-#include 
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 
 #include "sqfs_decompressor.h"
 #include "sqfs_filesystem.h"
@@ -85,10 +85,10 @@ static int sqfs_calc_n_blks(__le64 start, __le64 end, u64 
*offset)
u64 start_, table_size;
 
table_size = le64_to_cpu(end) - le64_to_cpu(start);
-   start_ = le64_to_cpu(start) / ctxt.cur_dev->blksz;
+   start_ = DIV_ROUND_DOWN_ULL(le64_to_cpu(start), ctxt.cur_dev->blksz);
*offset = le64_to_cpu(start) - (start_ * ctxt.cur_dev->blksz);
 
-   return DIV_ROUND_UP(table_size + *offset, ctxt.cur_dev->blksz);
+   return (table_size + *offset + ctxt.cur_dev->blksz - 1) >> 
ctxt.cur_dev->log2blksz;
 }
 
 /*
@@ -109,8 +109,8 @@ static int sqfs_frag_lookup(u32 inode_fragment_index,
if (inode_fragment_index >= get_unaligned_le32(>fragments))
return -EINVAL;
 
-   start = get_unaligned_le64(>fragment_table_start) /
-   ctxt.cur_dev->blksz;
+   start = 
DIV_ROUND_DOWN_ULL(get_unaligned_le64(>fragment_table_start),
+  ctxt.cur_dev->blksz);
n_blks = sqfs_calc_n_blks(sblk->fragment_table_start,
  sblk->export_table_start,
  _offset);
@@ -135,7 +135,7 @@ static int sqfs_frag_lookup(u32 inode_fragment_index,
start_block = get_unaligned_le64(table + table_offset + block *
 sizeof(u64));
 
-   start = start_block / ctxt.cur_dev->blksz;
+   start = DIV_ROUND_DOWN_ULL(start_block, ctxt.cur_dev->blksz);
n_blks = sqfs_calc_n_blks(cpu_to_le64(start_block),
  sblk->fragment_table_start, _offset);
 
@@ -641,8 +641,8 @@ static int sqfs_read_inode_table(unsigned char 
**inode_table)
 
table_size = get_unaligned_le64(>directory_table_start) -
get_unaligned_le64(>inode_table_start);
-   start = get_unaligned_le64(>inode_table_start) /
-   ctxt.cur_dev->blksz;
+   start = DIV_ROUND_DOWN_ULL(get_unaligned_le64(>inode_table_start),
+  ctxt.cur_dev->blksz);
n_blks = sqfs_calc_n_blks(sblk->inode_table_start,
  sblk->directory_table_start, _offset);
 
@@ -725,8 +725,8 @@ static int sqfs_read_directory_table(unsigned char 
**dir_table, u32 **pos_list)
/* DIRECTORY TABLE */
table_size = get_unaligned_le64(>fragment_table_start) -
get_unaligned_le64(>directory_table_start);
-   start = get_unaligned_le64(>directory_table_start) /
-   ctxt.cur_dev->blksz;
+   start = 
DIV_ROUND_DOWN_ULL(get_unaligned_le64(>directory_table_start),
+  ctxt.cur_dev->blksz);
n_blks = sqfs_calc_n_blks(sblk->directory_table_start,
  sblk->fragment_table_start, _offset);
 
@@ -1334,11 +1334,11 @@ int sqfs_read(const char *filename, void *buf, loff_t 
offset, loff_t len,
}
 
for (j = 0; j < datablk_count; j++) {
-   start = data_offset / ctxt.cur_dev->blksz;
+   start = DIV_ROUND_DOWN_ULL(data_offset, ctxt.cur_dev->blksz);
table_size = SQFS_BLOCK_SIZE(finfo.blk_sizes[j]);
table_offset = data_offset - (start * ctxt.cur_dev->blksz);
-   n_blks = DIV_ROUND_UP(table_size + table_offset,
- ctxt.cur_dev->blksz);
+   n_blks = DIV_ROUND_UP_ULL(table_size + table_offset,
+ ctxt.cur_dev->blksz);
 
data_buffer = malloc_ca

Problems with large amount of partitions on SD

[Mauro Condarelli]

I am having huge problems with my system *possibly* due to fact I have 10 
partitions on a single SD card.

I'm getting an unreliable behavior (issuing the same commands do *not* result 
in consistent behavior) which *seem* to point to some overwrite/cache problem.

First of all: is a configuration with 10 partitions on SD supported?
I tried perusing files in disk/part*, but I failed to see where extended 
partitions are handled.

Here follows one (typical) example:

This is one example of a boot after a long time off, no key touched:

> U-Boot SPL 2020.10-rc5 (Oct 01 2020 - 17:14:04 +0200)
> Trying to boot from NOR
>
>
> U-Boot 2020.10-rc5 (Oct 01 2020 - 17:14:04 +0200)
>
> CPU:   MediaTek MT7628A ver:1 eco:2
> Boot:  DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL
> Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
> DRAM:  128 MiB
> WDT:   Started with servicing (60s timeout)
> MMC:   mmc@1013: 0
> Loading Environment from SPIFlash... SF: Detected w25q128 with page size 256 
> Bytes, erase size 4 KiB, total 16 MiB
> OK
> In:uart2@e00
> Out:   uart2@e00
> Err:   uart2@e00
> Model: VoCore2
> Net:   
> Warning: eth@1011 (eth0) using random MAC address - 0a:92:ae:d0:9b:c2
> eth0: eth@1011
> Hit any key to stop autoboot:  0 
> Loading System B
>
> Partition Map for MMC device 0  --   Partition Type: DOS
>
> Part  Start SectorNum Sectors UUIDType
>   1   2048262144  30f8737b-01 0c
>   2   264192  4194304 30f8737b-02 83
>   3   4458496 32768   30f8737b-03 83
>   4   4491264 1126809630f8737b-04 05 Extd
> ** Can't read partition table on 0:4491264 **
> ** Can't read partition table on 0:4902912 **
> ** Invalid partition 7 **
> Loading Recovery

here recovery system is loaded from Flash, not mmc.
After a "reboot" from linux I get:

> [48634.981029] reboot: Restarting system
> [48634.984764] ralink_restart
>
> U-Boot SPL 2020.10-rc5 (Oct 01 2020 - 17:14:04 +0200)
> Trying to boot from NOR
>
>
> U-Boot 2020.10-rc5 (Oct 01 2020 - 17:14:04 +0200)
>
> CPU:   MediaTek MT7628A ver:1 eco:2
> Boot:  DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL
> Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
> DRAM:  128 MiB
> WDT:   Started with servicing (60s timeout)
> MMC:   mmc@1013: 0
> Loading Environment from SPIFlash... SF: Detected w25q128 with page size 256 
> Bytes, erase size 4 KiB, total 16 MiB
> OK
> In:uart2@e00
> Out:   uart2@e00
> Err:   uart2@e00
> Model: VoCore2
> Net:   
> Warning: eth@1011 (eth0) using random MAC address - be:c5:7e:06:ca:a1
> eth0: eth@1011
> Hit any key to stop autoboot:  0 


Here I stop autoboot.
This is my complete environment.

> => printenv 
> BOOT_CURRENT=B
> SYSTEM_R=/dev/mtdblock5
> arch=mips
> baudrate=115200
> board=vocore2
> board_name=vocore2
> boot_a=echo "Loading System A";part=6;run boot_x
> boot_b=echo "Loading System B";part=7;run boot_x
> boot_now=if test "${BOOT_CURRENT}" = A; then run boot_a; elif test 
> "${BOOT_CURRENT}" = B; then run boot_b; fi; if env exists BOOT_A_GOOD; then 
> run boot_a; fi; if env exists BOOT_B_GOOD; then run boot_b; fi; run boot_r
> boot_r=echo "Loading Recovery"; setenv bootargs "${default_bootargs} 
> mtdparts=${mtdparts} root=/dev/mtdblock5"; bootm bc05
> boot_x=mmc rescan && mmc part && ls mmc 0:${part} && load mmc 0:${part} 
> 8500 /boot/uImage && setenv bootargs "${default_bootargs} 
> mtdparts=${mtdparts} root=/dev/mmcblk0p${part}" && bootm ${fileaddr}
> bootcmd=mmc rescan && sleep 1 && run do_boot
> bootcount=1
> bootdelay=2
> cpu=mips32
> default_bootargs=earlyprintk rootwait console=ttyS2,115200
> do_boot=test ${bootcount} -gt 1 && run remove_boot; run boot_now
> fdtcontroladdr=86f6d350
> fileaddr=8500
> filesize=268c63
> fupdate=mmc rescan && load mmc 0:1 8400 uboot.scr && fatrm mmc 0:1 
> uboot.scr && source 8400 && echo Flash updated
> mtdids=nor0=spi0.0
> mtdparts=spi0.0:312k(u-boot),4k(env),4k(factory),2368k(kernel),-(filesystem)
> remove_boot=if env exists BOOT_CURRENT; then setenv BOOT_CURRENT; saveenv; 
> elif env exists BOOT_A_GOOD; then setenv BOOT_A_GOOD; saveenv; elif env 
> exists BOOT_B_GOOD; then setenv BOOT_B_GOOD; saveenv; fi
> soc=mt7628
> stderr=uart2@e00
> stdin=uart2@e00
> stdout=uart2@e00
> vendor=vocore
> ver=U-Boot 2020.10-rc5 (Oct 01 2020 - 17:14:04 +0200)
>
> Environment size: 1558/4092 bytes


I have two full systems on SD (partitions 6 and 7) and a fallback on Flash.
Idea is to try to boot from 

Re: [RFC PATCH v2 1/1] Fix missing __udivdi3 in SquashFS implementation.

[Mauro Condarelli]

Ok, Thanks.
Patch is ready, I'll send it after some extended testing on my system (vocore2).

Regards
Mauro

On 10/1/20 10:56 AM, Miquel Raynal wrote:
> Hi Mauro,
>
> Mauro Condarelli  wrote on Thu, 1 Oct 2020 10:53:30
> +0200:
>
>> Correcting myself.
>> See below.
>>
>> On 10/1/20 10:41 AM, Mauro Condarelli wrote:
>>> Thanks for Your review.
>>>
>>> On 10/1/20 9:59 AM, Miquel Raynal wrote:  
>>>> Hello,
>>>>
>>>> Thomas Petazzoni  wrote on Thu, 1 Oct
>>>> 2020 09:28:41 +0200:
>>>>  
>>>>> Hello,
>>>>>
>>>>> On Wed, 30 Sep 2020 17:45:11 +0200
>>>>> Mauro Condarelli  wrote:
>>>>>  
>>>>>> Use right shift to avoid 64-bit divisions.
>>>>>>
>>>>>> These divisions are needed to convert from file length (potentially
>>>>>> over 32-bit range) to block number, so result and remainder are
>>>>>> guaranteed to fit in 32-bit integers.
>>>>>>
>>>>>> Signed-off-by: Mauro Condarelli 
>>>>> Perhaps the commit log should contain an example U-Boot
>>>>> configuration/platform where it fails to build. Indeed, we did test the
>>>>> SquashFS code on ARM 32-bit, and it built and worked fine.  
>>> This fails on mips32, specifically for the vocore2 board.
>>> Problem here is __udivdi3 is not defined for this architecture
>>> while it is for ARM32.
>>> My (limited) understanding suggests it should be removed for ARM
>>> since its usage has been (is being?) weeded out from both kernel
>>> and u-boot. This is not my call, though.
>>>
>>> I will add a note to v3.
>>>  
>>>>>> ---
>>>>>>
>>>>>> Changes in v2:
>>>>>> - replace division with right shift (Daniel Schwierzeck).
>>>>>> - remove vocore2-specific change (Daniel Schwierzeck).
>>>>>> - add warning to Kconfig about CONFIG_SYS_MALLOC_LEN (Tom Rini).
>>>>>>
>>>>>>  fs/squashfs/Kconfig  |  2 ++
>>>>>>  fs/squashfs/sqfs.c   | 30 +++---
>>>>>>  fs/squashfs/sqfs_inode.c |  6 +++---
>>>>>>  3 files changed, 20 insertions(+), 18 deletions(-)
>>>>>>
>>>>>> diff --git a/fs/squashfs/Kconfig b/fs/squashfs/Kconfig
>>>>>> index 54ab1618f1..7c3f83d007 100644
>>>>>> --- a/fs/squashfs/Kconfig
>>>>>> +++ b/fs/squashfs/Kconfig
>>>>>> @@ -9,3 +9,5 @@ config FS_SQUASHFS
>>>>>>filesystem use, for archival use (i.e. in cases where a 
>>>>>> .tar.gz file
>>>>>>may be used), and in constrained block device/memory systems 
>>>>>> (e.g.
>>>>>>embedded systems) where low overhead is needed.
>>>>>> +  WARNING: if compression is enabled SquashFS needs a large 
>>>>>> amount
>>>>>> +  of dynamic memory; make sure CONFIG_SYS_MALLOC_LEN >= 0x4000. 
>>>>>>
>>>>> This change is completely unrelated, and should be in a separate patch.  
>>>> I was about to tell you the same thing, this warning is useful but
>>>> should definitely lay into its own commit.  
>>> Will do in v3.
>>>
>>>  
>>>>>> -n_blks = DIV_ROUND_UP(table_size + table_offset,
>>>>>> -  ctxt.cur_dev->blksz);
>>>>>> +n_blks = (table_size + table_offset + 
>>>>>> ctxt.cur_dev->blksz - 1) >>
>>>>>> +ctxt.cur_dev->log2blksz;
>>>>> I understand why you have to add blksz - 1 before doing the shift, but
>>>>> I find that it's overall a lot less readable/clear. Is there a way to
>>>>> do better ?
>>>>>
>>>>> We could use DIV_ROUND_UP_ULL() I guess.  
>>> I did not do this because DIV_ROUND_UP() is in a global 
>>> (non-architecture-specific)
>>> header and it unconditionally uses division; I did not know how to handle 
>>> this.
>>> Would a comment suffice to clarify intent? Something like:
>>>
>>> n_blks = (table_size + table_offset + ctxt.cur_dev->blksz - 1) >>
>>>   ctxt.cur_dev->log2blksz; /* ROUND_UP division */
>>>
&g

Re: [RFC PATCH v2 1/1] Fix missing __udivdi3 in SquashFS implementation.

[Mauro Condarelli]

Correcting myself.
See below.

On 10/1/20 10:41 AM, Mauro Condarelli wrote:
> Thanks for Your review.
>
> On 10/1/20 9:59 AM, Miquel Raynal wrote:
>> Hello,
>>
>> Thomas Petazzoni  wrote on Thu, 1 Oct
>> 2020 09:28:41 +0200:
>>
>>> Hello,
>>>
>>> On Wed, 30 Sep 2020 17:45:11 +0200
>>> Mauro Condarelli  wrote:
>>>
>>>> Use right shift to avoid 64-bit divisions.
>>>>
>>>> These divisions are needed to convert from file length (potentially
>>>> over 32-bit range) to block number, so result and remainder are
>>>> guaranteed to fit in 32-bit integers.
>>>>
>>>> Signed-off-by: Mauro Condarelli   
>>> Perhaps the commit log should contain an example U-Boot
>>> configuration/platform where it fails to build. Indeed, we did test the
>>> SquashFS code on ARM 32-bit, and it built and worked fine.
> This fails on mips32, specifically for the vocore2 board.
> Problem here is __udivdi3 is not defined for this architecture
> while it is for ARM32.
> My (limited) understanding suggests it should be removed for ARM
> since its usage has been (is being?) weeded out from both kernel
> and u-boot. This is not my call, though.
>
> I will add a note to v3.
>
>>>> ---
>>>>
>>>> Changes in v2:
>>>> - replace division with right shift (Daniel Schwierzeck).
>>>> - remove vocore2-specific change (Daniel Schwierzeck).
>>>> - add warning to Kconfig about CONFIG_SYS_MALLOC_LEN (Tom Rini).
>>>>
>>>>  fs/squashfs/Kconfig  |  2 ++
>>>>  fs/squashfs/sqfs.c   | 30 +++---
>>>>  fs/squashfs/sqfs_inode.c |  6 +++---
>>>>  3 files changed, 20 insertions(+), 18 deletions(-)
>>>>
>>>> diff --git a/fs/squashfs/Kconfig b/fs/squashfs/Kconfig
>>>> index 54ab1618f1..7c3f83d007 100644
>>>> --- a/fs/squashfs/Kconfig
>>>> +++ b/fs/squashfs/Kconfig
>>>> @@ -9,3 +9,5 @@ config FS_SQUASHFS
>>>>  filesystem use, for archival use (i.e. in cases where a .tar.gz file
>>>>  may be used), and in constrained block device/memory systems (e.g.
>>>>  embedded systems) where low overhead is needed.
>>>> +WARNING: if compression is enabled SquashFS needs a large amount
>>>> +of dynamic memory; make sure CONFIG_SYS_MALLOC_LEN >= 0x4000.  
>>> This change is completely unrelated, and should be in a separate patch.
>> I was about to tell you the same thing, this warning is useful but
>> should definitely lay into its own commit.
> Will do in v3.
>
>
>>>> -  n_blks = DIV_ROUND_UP(table_size + table_offset,
>>>> -ctxt.cur_dev->blksz);
>>>> +  n_blks = (table_size + table_offset + ctxt.cur_dev->blksz - 1) 
>>>> >>
>>>> +  ctxt.cur_dev->log2blksz;  
>>> I understand why you have to add blksz - 1 before doing the shift, but
>>> I find that it's overall a lot less readable/clear. Is there a way to
>>> do better ?
>>>
>>> We could use DIV_ROUND_UP_ULL() I guess.
> I did not do this because DIV_ROUND_UP() is in a global 
> (non-architecture-specific)
> header and it unconditionally uses division; I did not know how to handle 
> this.
> Would a comment suffice to clarify intent? Something like:
>
> n_blks = (table_size + table_offset + ctxt.cur_dev->blksz - 1) >>
> ctxt.cur_dev->log2blksz; /* ROUND_UP division */
>
> Note: this problem stays even if we roll-back to use do_div(); see below.
actually include/linux/kernel.h defines both DIV_ROUND_DOWN_ULL()
and DIV_ROUND_UP_ULL() I suppose we should use those in all cases.


>>>>else
>>>> -  blk_list_size = file_size / blk_size;
>>>> +  blk_list_size = file_size > LOG2(blk_size);  
>>> Very bad mistake here: > should be >>.
> Sorry, my bad.
> Corrected for v3.
>
>> I personally highly dislike replacing divisions into shifts. I think
>> it's too much effort when trying to understand code you did not write
>> yourself. Is it possible to use something like do_div? plus, you can
>> check the remainder to be 0 in this case.
> Please make up your mind about this.
> I personally tend to agree with Miquèl and my v1 patch used
> do_div() exclusively (i did not use even the lldiv() wrapper), but
> I will not insist either way... just let me know what's considered
> better.
As said above: it seems using the macros is both "standard" and
safer than using shifts.
If I get a go-ahead I'll use those macros in v3.

>
>> Thanks,
>> Miquèl
> Many thanks
> Mauro

Re: [RFC PATCH v2 1/1] Fix missing __udivdi3 in SquashFS implementation.

[Mauro Condarelli]

Thanks for Your review.

On 10/1/20 9:59 AM, Miquel Raynal wrote:
> Hello,
>
> Thomas Petazzoni  wrote on Thu, 1 Oct
> 2020 09:28:41 +0200:
>
>> Hello,
>>
>> On Wed, 30 Sep 2020 17:45:11 +0200
>> Mauro Condarelli  wrote:
>>
>>> Use right shift to avoid 64-bit divisions.
>>>
>>> These divisions are needed to convert from file length (potentially
>>> over 32-bit range) to block number, so result and remainder are
>>> guaranteed to fit in 32-bit integers.
>>>
>>> Signed-off-by: Mauro Condarelli   
>> Perhaps the commit log should contain an example U-Boot
>> configuration/platform where it fails to build. Indeed, we did test the
>> SquashFS code on ARM 32-bit, and it built and worked fine.
This fails on mips32, specifically for the vocore2 board.
Problem here is __udivdi3 is not defined for this architecture
while it is for ARM32.
My (limited) understanding suggests it should be removed for ARM
since its usage has been (is being?) weeded out from both kernel
and u-boot. This is not my call, though.

I will add a note to v3.

>>
>>> ---
>>>
>>> Changes in v2:
>>> - replace division with right shift (Daniel Schwierzeck).
>>> - remove vocore2-specific change (Daniel Schwierzeck).
>>> - add warning to Kconfig about CONFIG_SYS_MALLOC_LEN (Tom Rini).
>>>
>>>  fs/squashfs/Kconfig  |  2 ++
>>>  fs/squashfs/sqfs.c   | 30 +++---
>>>  fs/squashfs/sqfs_inode.c |  6 +++---
>>>  3 files changed, 20 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/fs/squashfs/Kconfig b/fs/squashfs/Kconfig
>>> index 54ab1618f1..7c3f83d007 100644
>>> --- a/fs/squashfs/Kconfig
>>> +++ b/fs/squashfs/Kconfig
>>> @@ -9,3 +9,5 @@ config FS_SQUASHFS
>>>   filesystem use, for archival use (i.e. in cases where a .tar.gz file
>>>   may be used), and in constrained block device/memory systems (e.g.
>>>   embedded systems) where low overhead is needed.
>>> + WARNING: if compression is enabled SquashFS needs a large amount
>>> + of dynamic memory; make sure CONFIG_SYS_MALLOC_LEN >= 0x4000.  
>> This change is completely unrelated, and should be in a separate patch.
> I was about to tell you the same thing, this warning is useful but
> should definitely lay into its own commit.
Will do in v3.


>>> -   n_blks = DIV_ROUND_UP(table_size + table_offset,
>>> - ctxt.cur_dev->blksz);
>>> +   n_blks = (table_size + table_offset + ctxt.cur_dev->blksz - 1) 
>>> >>
>>> +   ctxt.cur_dev->log2blksz;  
>> I understand why you have to add blksz - 1 before doing the shift, but
>> I find that it's overall a lot less readable/clear. Is there a way to
>> do better ?
>>
>> We could use DIV_ROUND_UP_ULL() I guess.
I did not do this because DIV_ROUND_UP() is in a global 
(non-architecture-specific)
header and it unconditionally uses division; I did not know how to handle this.
Would a comment suffice to clarify intent? Something like:

n_blks = (table_size + table_offset + ctxt.cur_dev->blksz - 1) >>
  ctxt.cur_dev->log2blksz; /* ROUND_UP division */

Note: this problem stays even if we roll-back to use do_div(); see below.

>>> else
>>> -   blk_list_size = file_size / blk_size;
>>> +   blk_list_size = file_size > LOG2(blk_size);  
>> Very bad mistake here: > should be >>.
Sorry, my bad.
Corrected for v3.

> I personally highly dislike replacing divisions into shifts. I think
> it's too much effort when trying to understand code you did not write
> yourself. Is it possible to use something like do_div? plus, you can
> check the remainder to be 0 in this case.
Please make up your mind about this.
I personally tend to agree with Miquèl and my v1 patch used
do_div() exclusively (i did not use even the lldiv() wrapper), but
I will not insist either way... just let me know what's considered
better.

>
> Thanks,
> Miquèl
Many thanks
Mauro

[RFC PATCH v2 1/1] Fix missing __udivdi3 in SquashFS implementation.

[Mauro Condarelli]

Use right shift to avoid 64-bit divisions.

These divisions are needed to convert from file length (potentially
over 32-bit range) to block number, so result and remainder are
guaranteed to fit in 32-bit integers.

Signed-off-by: Mauro Condarelli 
---

Changes in v2:
- replace division with right shift (Daniel Schwierzeck).
- remove vocore2-specific change (Daniel Schwierzeck).
- add warning to Kconfig about CONFIG_SYS_MALLOC_LEN (Tom Rini).

 fs/squashfs/Kconfig  |  2 ++
 fs/squashfs/sqfs.c   | 30 +++---
 fs/squashfs/sqfs_inode.c |  6 +++---
 3 files changed, 20 insertions(+), 18 deletions(-)

diff --git a/fs/squashfs/Kconfig b/fs/squashfs/Kconfig
index 54ab1618f1..7c3f83d007 100644
--- a/fs/squashfs/Kconfig
+++ b/fs/squashfs/Kconfig
@@ -9,3 +9,5 @@ config FS_SQUASHFS
  filesystem use, for archival use (i.e. in cases where a .tar.gz file
  may be used), and in constrained block device/memory systems (e.g.
  embedded systems) where low overhead is needed.
+ WARNING: if compression is enabled SquashFS needs a large amount
+ of dynamic memory; make sure CONFIG_SYS_MALLOC_LEN >= 0x4000.
diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
index 15208b4dab..90e6848e6c 100644
--- a/fs/squashfs/sqfs.c
+++ b/fs/squashfs/sqfs.c
@@ -85,10 +85,10 @@ static int sqfs_calc_n_blks(__le64 start, __le64 end, u64 
*offset)
u64 start_, table_size;
 
table_size = le64_to_cpu(end) - le64_to_cpu(start);
-   start_ = le64_to_cpu(start) / ctxt.cur_dev->blksz;
-   *offset = le64_to_cpu(start) - (start_ * ctxt.cur_dev->blksz);
+   start_ = le64_to_cpu(start) >> ctxt.cur_dev->log2blksz;
+   *offset = le64_to_cpu(start) - (start_ << ctxt.cur_dev->log2blksz);
 
-   return DIV_ROUND_UP(table_size + *offset, ctxt.cur_dev->blksz);
+   return (table_size + *offset + ctxt.cur_dev->blksz - 1) >> 
ctxt.cur_dev->log2blksz;
 }
 
 /*
@@ -109,8 +109,8 @@ static int sqfs_frag_lookup(u32 inode_fragment_index,
if (inode_fragment_index >= get_unaligned_le32(>fragments))
return -EINVAL;
 
-   start = get_unaligned_le64(>fragment_table_start) /
-   ctxt.cur_dev->blksz;
+   start = get_unaligned_le64(>fragment_table_start) >>
+   ctxt.cur_dev->log2blksz;
n_blks = sqfs_calc_n_blks(sblk->fragment_table_start,
  sblk->export_table_start,
  _offset);
@@ -135,7 +135,7 @@ static int sqfs_frag_lookup(u32 inode_fragment_index,
start_block = get_unaligned_le64(table + table_offset + block *
 sizeof(u64));
 
-   start = start_block / ctxt.cur_dev->blksz;
+   start = start_block >> ctxt.cur_dev->log2blksz;
n_blks = sqfs_calc_n_blks(cpu_to_le64(start_block),
  sblk->fragment_table_start, _offset);
 
@@ -641,8 +641,8 @@ static int sqfs_read_inode_table(unsigned char 
**inode_table)
 
table_size = get_unaligned_le64(>directory_table_start) -
get_unaligned_le64(>inode_table_start);
-   start = get_unaligned_le64(>inode_table_start) /
-   ctxt.cur_dev->blksz;
+   start = get_unaligned_le64(>inode_table_start) >>
+   ctxt.cur_dev->log2blksz;
n_blks = sqfs_calc_n_blks(sblk->inode_table_start,
  sblk->directory_table_start, _offset);
 
@@ -725,8 +725,8 @@ static int sqfs_read_directory_table(unsigned char 
**dir_table, u32 **pos_list)
/* DIRECTORY TABLE */
table_size = get_unaligned_le64(>fragment_table_start) -
get_unaligned_le64(>directory_table_start);
-   start = get_unaligned_le64(>directory_table_start) /
-   ctxt.cur_dev->blksz;
+   start = get_unaligned_le64(>directory_table_start) >>
+   ctxt.cur_dev->log2blksz;
n_blks = sqfs_calc_n_blks(sblk->directory_table_start,
  sblk->fragment_table_start, _offset);
 
@@ -1334,11 +1334,11 @@ int sqfs_read(const char *filename, void *buf, loff_t 
offset, loff_t len,
}
 
for (j = 0; j < datablk_count; j++) {
-   start = data_offset / ctxt.cur_dev->blksz;
+   start = data_offset >> ctxt.cur_dev->log2blksz;
table_size = SQFS_BLOCK_SIZE(finfo.blk_sizes[j]);
table_offset = data_offset - (start * ctxt.cur_dev->blksz);
-   n_blks = DIV_ROUND_UP(table_size + table_offset,
- ctxt.cur_dev->blksz);
+   n_blks = (table_size + table_offset + ctxt.cur_dev->blksz - 1) 
>>
+   ctxt.cur_dev->log2blksz;
 
data_buffer = malloc_cache_aligned(n_blks * 
ctxt.cur_dev->blks

[RFC PATCH v2 0/1] Current strategy is to use right/left shift to implement div/mult

[Mauro Condarelli]

this work *only* under the assumption block-size is always a power
of 2; I was unable to find where it is enforced.

Alternative strategy would be to use directly the lower-level do_div(),
or the lldiv() wrapper instead.

Please review because I did not find a place where it is enforced
that struct blk_desc blksz is a a power of 2 and thus using log2blksz
is actually correct.

Changes in v2:
- replace division with right shift (Daniel Schwierzeck).
- remove vocore2-specific change (Daniel Schwierzeck).
- add warning to Kconfig about CONFIG_SYS_MALLOC_LEN (Tom Rini).

Mauro Condarelli (1):
  Fix missing __udivdi3 in SquashFS implementation.

 fs/squashfs/Kconfig  |  2 ++
 fs/squashfs/sqfs.c   | 30 +++---
 fs/squashfs/sqfs_inode.c |  6 +++---
 3 files changed, 20 insertions(+), 18 deletions(-)

-- 
2.25.1

Re: [PATCH 3/3] Fix missing __udivdi3 in SquashFS implementation.

[Mauro Condarelli]

Thanks for the review,
I'll prepare a v2 ASAP.

On 9/23/20 12:05 AM, Daniel Schwierzeck wrote:
> Am Sonntag, den 20.09.2020, 21:21 -0400 schrieb Tom Rini:
>> On Sun, Sep 20, 2020 at 06:29:01PM +0200, Mauro Condarelli wrote:
>>
>>> Signed-off-by: Mauro Condarelli 
>>> ---
>>>  fs/squashfs/sqfs.c| 45 +--
>>>  fs/squashfs/sqfs_inode.c  |  8 +++
>>>  include/configs/vocore2.h |  2 +-
> remove that file which is unrelated to this patch
I will as this is fixing things just for my target and that is clearly wrong.
OTOH I feel some provision should be implemented (probably at Config.in
level) to ensure SquashFS has enough malloc space for its needs.
What are the best practices to handle this?


>>>  3 files changed, 34 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
>>> index 15208b4dab..b49331ce93 100644
>>> --- a/fs/squashfs/sqfs.c
>>> +++ b/fs/squashfs/sqfs.c
>>> @@ -18,6 +18,8 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>> +#include 
>>>  
>>>  #include "sqfs_decompressor.h"
>>>  #include "sqfs_filesystem.h"
>>> @@ -82,13 +84,16 @@ static int sqfs_count_tokens(const char *filename)
>>>   */
>>>  static int sqfs_calc_n_blks(__le64 start, __le64 end, u64 *offset)
>>>  {
>>> -   u64 start_, table_size;
>>> +   u64 start_, table_size, blks;
>>>  
>>> table_size = le64_to_cpu(end) - le64_to_cpu(start);
>>> -   start_ = le64_to_cpu(start) / ctxt.cur_dev->blksz;
>>> +   start_ = le64_to_cpu(start);
>>> +   do_div(start_, ctxt.cur_dev->blksz);
> have you tried with lldiv() which returns the 64bit result? Also it
> would be a little cleaner:
>
> start_ = lldiv(le64_to_cpu(start), ctxt.cur_dev->blksz);
I thought of that (actually my first attempt was quite similar,
but I noticed that lldiv() actually uses do_div() internally and
so I decided to go directly for the lower level (and presumably
faster) solution.
If You (or the maintainers) feel otherwise I can revert with
no problems.

>>> *offset = le64_to_cpu(start) - (start_ * ctxt.cur_dev->blksz);
>>>  
>>> -   return DIV_ROUND_UP(table_size + *offset, ctxt.cur_dev->blksz);
>>> +   blks = table_size + *offset;
>>> +   if (do_div(blks, ctxt.cur_dev->blksz)) blks++;
>>> +   return blks;
> maybe define something like this and use that instead of DIV_ROUND_UP:
>
> #define lldiv_round_up(n, d) lldiv((n) + (d) - 1, (d))
Again: IMHO having a macro does not add much value here
and using lldiv() only adds a further level of call nesting, but
I'm open to switch; I would like to understand the rationale
behind these requests, though.

>>>  }
>>>  
>>>  /*
>>> @@ -109,8 +114,8 @@ static int sqfs_frag_lookup(u32 inode_fragment_index,
>>> if (inode_fragment_index >= get_unaligned_le32(>fragments))
>>> return -EINVAL;
>>>  
>>> -   start = get_unaligned_le64(>fragment_table_start) /
>>> -   ctxt.cur_dev->blksz;
>>> +   start = get_unaligned_le64(>fragment_table_start);
>>> +   do_div(start, ctxt.cur_dev->blksz);
>>> n_blks = sqfs_calc_n_blks(sblk->fragment_table_start,
>>>   sblk->export_table_start,
>>>   _offset);
>>> @@ -135,7 +140,8 @@ static int sqfs_frag_lookup(u32 inode_fragment_index,
>>> start_block = get_unaligned_le64(table + table_offset + block *
>>>  sizeof(u64));
>>>  
>>> -   start = start_block / ctxt.cur_dev->blksz;
>>> +   start = start_block;
>>> +   do_div(start, ctxt.cur_dev->blksz);
>>> n_blks = sqfs_calc_n_blks(cpu_to_le64(start_block),
>>>   sblk->fragment_table_start, _offset);
>>>  
>>> @@ -641,8 +647,8 @@ static int sqfs_read_inode_table(unsigned char 
>>> **inode_table)
>>>  
>>> table_size = get_unaligned_le64(>directory_table_start) -
>>> get_unaligned_le64(>inode_table_start);
>>> -   start = get_unaligned_le64(>inode_table_start) /
>>> -   ctxt.cur_dev->blksz;
>>> +   start = get_unaligned_le64(>inode_table_start);
>>> +   do_div(start, ctxt.cur_dev->blksz);
>>> n_blks = sqfs_calc_n_blks(sblk->inode_table_start,
>>>   sblk->direc

[PATCH 1/3] Small fixes to reduce size and ensure correct console output.

[Mauro Condarelli]

Signed-off-by: Mauro Condarelli 
---
 arch/mips/dts/vocore_vocore2.dts | 2 +-
 include/configs/vocore2.h| 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/mips/dts/vocore_vocore2.dts b/arch/mips/dts/vocore_vocore2.dts
index 3502e4b8b7..9adf39652f 100644
--- a/arch/mips/dts/vocore_vocore2.dts
+++ b/arch/mips/dts/vocore_vocore2.dts
@@ -59,7 +59,7 @@
#address-cells = <1>;
#size-cells = <1>;
compatible = "jedec,spi-nor";
-   spi-max-frequency = <2500>;
+   spi-max-frequency = <4000>;
reg = <0>;
};
 };
diff --git a/include/configs/vocore2.h b/include/configs/vocore2.h
index 40467b737c..29a57ad233 100644
--- a/include/configs/vocore2.h
+++ b/include/configs/vocore2.h
@@ -25,6 +25,7 @@
 #define CONFIG_SPL_BSS_START_ADDR  0x8001
 #define CONFIG_SPL_BSS_MAX_SIZE0x1
 #define CONFIG_SPL_MAX_SIZE0x1
+#define CONFIG_SPL_PAD_TO  0
 
 /* Dummy value */
 #define CONFIG_SYS_UBOOT_BASE  0
@@ -34,6 +35,7 @@
 #define CONFIG_SYS_NS16550_CLK 4000
 #define CONFIG_SYS_NS16550_REG_SIZE-4
 #define CONFIG_SYS_NS16550_COM30xbe00
+#define CONFIG_CONS_INDEX  3
 
 /* RAM */
 
-- 
2.25.1

[PATCH 3/3] Fix missing __udivdi3 in SquashFS implementation.

[Mauro Condarelli]

Signed-off-by: Mauro Condarelli 
---
 fs/squashfs/sqfs.c| 45 +--
 fs/squashfs/sqfs_inode.c  |  8 +++
 include/configs/vocore2.h |  2 +-
 3 files changed, 34 insertions(+), 21 deletions(-)

diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
index 15208b4dab..b49331ce93 100644
--- a/fs/squashfs/sqfs.c
+++ b/fs/squashfs/sqfs.c
@@ -18,6 +18,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "sqfs_decompressor.h"
 #include "sqfs_filesystem.h"
@@ -82,13 +84,16 @@ static int sqfs_count_tokens(const char *filename)
  */
 static int sqfs_calc_n_blks(__le64 start, __le64 end, u64 *offset)
 {
-   u64 start_, table_size;
+   u64 start_, table_size, blks;
 
table_size = le64_to_cpu(end) - le64_to_cpu(start);
-   start_ = le64_to_cpu(start) / ctxt.cur_dev->blksz;
+   start_ = le64_to_cpu(start);
+   do_div(start_, ctxt.cur_dev->blksz);
*offset = le64_to_cpu(start) - (start_ * ctxt.cur_dev->blksz);
 
-   return DIV_ROUND_UP(table_size + *offset, ctxt.cur_dev->blksz);
+   blks = table_size + *offset;
+   if (do_div(blks, ctxt.cur_dev->blksz)) blks++;
+   return blks;
 }
 
 /*
@@ -109,8 +114,8 @@ static int sqfs_frag_lookup(u32 inode_fragment_index,
if (inode_fragment_index >= get_unaligned_le32(>fragments))
return -EINVAL;
 
-   start = get_unaligned_le64(>fragment_table_start) /
-   ctxt.cur_dev->blksz;
+   start = get_unaligned_le64(>fragment_table_start);
+   do_div(start, ctxt.cur_dev->blksz);
n_blks = sqfs_calc_n_blks(sblk->fragment_table_start,
  sblk->export_table_start,
  _offset);
@@ -135,7 +140,8 @@ static int sqfs_frag_lookup(u32 inode_fragment_index,
start_block = get_unaligned_le64(table + table_offset + block *
 sizeof(u64));
 
-   start = start_block / ctxt.cur_dev->blksz;
+   start = start_block;
+   do_div(start, ctxt.cur_dev->blksz);
n_blks = sqfs_calc_n_blks(cpu_to_le64(start_block),
  sblk->fragment_table_start, _offset);
 
@@ -641,8 +647,8 @@ static int sqfs_read_inode_table(unsigned char 
**inode_table)
 
table_size = get_unaligned_le64(>directory_table_start) -
get_unaligned_le64(>inode_table_start);
-   start = get_unaligned_le64(>inode_table_start) /
-   ctxt.cur_dev->blksz;
+   start = get_unaligned_le64(>inode_table_start);
+   do_div(start, ctxt.cur_dev->blksz);
n_blks = sqfs_calc_n_blks(sblk->inode_table_start,
  sblk->directory_table_start, _offset);
 
@@ -725,8 +731,8 @@ static int sqfs_read_directory_table(unsigned char 
**dir_table, u32 **pos_list)
/* DIRECTORY TABLE */
table_size = get_unaligned_le64(>fragment_table_start) -
get_unaligned_le64(>directory_table_start);
-   start = get_unaligned_le64(>directory_table_start) /
-   ctxt.cur_dev->blksz;
+   start = get_unaligned_le64(>directory_table_start);
+   do_div(start, ctxt.cur_dev->blksz);
n_blks = sqfs_calc_n_blks(sblk->directory_table_start,
  sblk->fragment_table_start, _offset);
 
@@ -1158,6 +1164,7 @@ static int sqfs_get_regfile_info(struct 
squashfs_reg_inode *reg,
   fentry);
if (ret < 0)
return -EINVAL;
+
finfo->comp = true;
if (fentry->size < 1 || fentry->start == 0x7FFF)
return -EINVAL;
@@ -1328,17 +1335,19 @@ int sqfs_read(const char *filename, void *buf, loff_t 
offset, loff_t len,
data_offset = finfo.start;
datablock = malloc(get_unaligned_le32(>block_size));
if (!datablock) {
+   printf("Error: malloc(%u) failed.\n", 
get_unaligned_le32(>block_size));
ret = -ENOMEM;
goto free_paths;
}
}
 
for (j = 0; j < datablk_count; j++) {
-   start = data_offset / ctxt.cur_dev->blksz;
+   start = data_offset;
+   do_div(start, ctxt.cur_dev->blksz);
table_size = SQFS_BLOCK_SIZE(finfo.blk_sizes[j]);
table_offset = data_offset - (start * ctxt.cur_dev->blksz);
-   n_blks = DIV_ROUND_UP(table_size + table_offset,
- ctxt.cur_dev->blksz);
+   n_blks = table_size + table_offset;
+   if (do_div(n_blks, ctxt.cur_dev->blksz)) n_blks++;
 
data_buffer = malloc_cache_aligned(n_blks * 
ctxt.cur_dev->blksz);
 
@@ -1365,8 +1374,10 @@ in

[PATCH 0/3] Patches to allow running u-boot on vocore2 board

[Mauro Condarelli]

There are two distinct things here:
- a few small fixes specific to vocore2 board.
- fixes to SquashFS to allow compilation on 32-bit architectures.

Mauro Condarelli (3):
  Small fixes to reduce size and ensure correct console output.
  Enlarge SPL malloc area to prevent failure in lzma decompression.
  Fix missing __udivdi3 in SquashFS implementation.

 arch/mips/dts/vocore_vocore2.dts |  2 +-
 configs/vocore2_defconfig|  2 +-
 fs/squashfs/sqfs.c   | 45 
 fs/squashfs/sqfs_inode.c |  8 +++---
 include/configs/vocore2.h|  4 ++-
 5 files changed, 38 insertions(+), 23 deletions(-)

-- 
2.25.1

[PATCH 2/3] Enlarge SPL malloc area to prevent failure in lzma decompression.

[Mauro Condarelli]

Signed-off-by: Mauro Condarelli 
---
 configs/vocore2_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/vocore2_defconfig b/configs/vocore2_defconfig
index 99a1143e6e..5776aada15 100644
--- a/configs/vocore2_defconfig
+++ b/configs/vocore2_defconfig
@@ -6,7 +6,7 @@ CONFIG_ENV_SIZE=0x1000
 CONFIG_ENV_OFFSET=0x04e000
 CONFIG_ENV_SECT_SIZE=0x1000
 CONFIG_SYS_BOOTCOUNT_ADDR=0xb06c
-CONFIG_SPL_SYS_MALLOC_F_LEN=0x2
+CONFIG_SPL_SYS_MALLOC_F_LEN=0x4
 CONFIG_SPL=y
 CONFIG_SYS_BOOTCOUNT_SINGLEWORD=y
 CONFIG_ARCH_MTMIPS=y
-- 
2.25.1

Re: Cold boot consistently fails to load file from SD

[Mauro Condarelli]

Hi Daniel,
comments inline below.

On 9/19/20 9:15 PM, Daniel Schwierzeck wrote:
> Hi Mauro,
>
> Am Samstag, den 19.09.2020, 15:39 +0200 schrieb Mauro Condarelli:
>
>> Hi,
>> I'm facing a new problem for my Mt7628/vocore2 target.
>>
>> I moved the Linux kernel from a ext4 partition to the "proper" SquashFS 
>> partition (I say "proper" because I'm using a dual-system with fallback to 
>> avoid updating the currently working rootFS and kernel lies into rootFS).
>>
>> I am using u-boot v2020.10-rc3 plus the attached patches (one pertains 
>> SquashFS).
>>
>> Problem is a real cold boot (target off for more than one minute) leads to a 
>> load failure for the kernel. A warm boot ("reboot" from a running Linux) or 
>> a not-so-cold boot (turn target off and power it on again after a few 
>> seconds) seems to work as expected.
> which distro or Linux version do you use? Can you provide a full boot
> log?
I am using a self-compiled Buildroot RootFS, but this is hardly a problem.
Error is in pain u-boot.
I try to load Linux kernel in memory (from SD, from SquashFS) and this fails.
Linux has no chance to start at all.

> Linux MIPS had a bug with setting up memory for its exception vectors
> and handlers if the CPU didn't report support for vectored interrupts.
> mtmips is one of those CPUs. AFAIK this should have been fixed in
> mainline since some months. Could be one reason. 
I am using v2020.10-rc3 which should be "recent enough"... or am I wrong?

> You could also try to disable CONFIG_RESTORE_EXCEPTION_VECTOR_BASE in
> U-Boot. 
>
> Stefan also had cache issues on the Gardena board. He solved it with
> some memory allocation and copying, see arch/mips/mach-mtmips/cpu.c.
>
> The cmd_cache interface is not supported on MIPS as there is no
> reliable way to disable or enable caches or to separately control i-
> cache and d-cache.
>
> Can you send patches 0001 and 0002 to the mailing list in the proper
> way so that patchwork can pick them up? I'd like to prepare a small
> bugfix pull request for v2020.10. Thanks.
I'll do that tomorrow 'couse I'm too groggy now to be reliable ;)

Thanks
Mauro

Cold boot consistently fails to load file from SD

[Mauro Condarelli]

Hi,
I'm facing a new problem for my Mt7628/vocore2 target.

I moved the Linux kernel from a ext4 partition to the "proper" SquashFS 
partition (I say "proper" because I'm using a dual-system with fallback to 
avoid updating the currently working rootFS and kernel lies into rootFS).

I am using u-boot v2020.10-rc3 plus the attached patches (one pertains 
SquashFS).

Problem is a real cold boot (target off for more than one minute) leads to a 
load failure for the kernel. A warm boot ("reboot" from a running Linux) or a 
not-so-cold boot (turn target off and power it on again after a few seconds) 
seems to work as expected.

I tried to insert delays and/or "mmc rescan", but that does not seem to have 
any effect.
Also error message is not always the same; sometimes I get:

Error: too many data blocks to be read.
Failed to load '/boot/uImage'

other times:

** fs_devread read error - block
Failed to mount ext2 filesystem...
** Unrecognized filesystem type **


My full environment is:

BOOT_CURRENT=A
SYSTEM_R=/dev/mtdblock5
arch=mips
baudrate=115200
board=vocore2
board_name=vocore2
boot_a=echo "Loading System A";part=6;run boot_x
boot_b=echo "Loading System B";part=7;run boot_x
boot_now=if test "${BOOT_CURRENT}" = A; then run boot_a; elif test 
"${BOOT_CURRENT}" = B; then run boot_b; fi; if env exists BOOT_A_GOOD; then run 
boot_a; fi; if env exists BOOT_B_GOOD; then run boot_b; fi; run boot_r
boot_r=echo "Loading Recovery"; setenv bootargs "${default_bootargs} 
mtdparts=${mtdparts} root=/dev/mtdblock5"; bootm bc05
boot_x=load mmc 0:${part} 8500 /boot/uImage && setenv bootargs 
"${default_bootargs} mtdparts=${mtdparts} root=/dev/mmcblk0p${part}" && bootm 
${fileaddr}
bootcmd=run do_boot
bootcount=1
bootdelay=2
cpu=mips32
default_bootargs=earlyprintk rootwait console=ttyS2,115200
do_boot=test ${bootcount} -gt 1 && run remove_boot; run boot_now
fdtcontroladdr=86f6d340
fileaddr=8400
filesize=154
fupdate=mmc rescan && load mmc 0:1 8400 uboot.scr && fatrm mmc 0:1 
uboot.scr && source 8400 && echo Flash updated || Flash update FAILED!
mtdids=nor0=spi0.0
mtdparts=spi0.0:312k(u-boot),4k(env),4k(factory),2368k(kernel),-(filesystem)
remove_boot=if env exists BOOT_CURRENT; then setenv BOOT_CURRENT; saveenv; 
elif env exists BOOT_A_GOOD; then setenv BOOT_A_GOOD; saveenv; elif env exists 
BOOT_B_GOOD; then setenv BOOT_B_GOOD; saveenv; fi
soc=mt7628
stderr=uart2@e00
stdin=uart2@e00
stdout=uart2@e00
vendor=vocore
ver=U-Boot 2020.10-rc3 (Sep 16 2020 - 19:43:03 +0200)


It was suggested (on IRC) it could be a cache problem. unfortunately trying to 
enable cache control (CONFIG_CMD_CACHE) raises error in compilation:

  ...
  LD      u-boot

/home/valeria/MyProject/VoCore/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
 cmd/built-in.o: in function `do_icache':
cmd/cache.c:(.text.do_icache+0x5c): undefined reference to `icache_disable'

/home/valeria/MyProject/VoCore/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
 cmd/cache.c:(.text.do_icache+0x6c): undefined reference to `icache_enable'

/home/valeria/MyProject/VoCore/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
 cmd/cache.c:(.text.do_icache+0x8c): undefined reference to `icache_status'
Makefile:1753: recipe for target 'u-boot' failed
make[2]: *** [u-boot] Error 1
package/pkg-generic.mk:266 <http://pkg-generic.mk:266>: recipe for target 
'/home/valeria/MyProject/VoCore/Buildroot-2/recov/build/uboot-v2020.10-rc3/.stamp_built'
 failed
make[1]: *** 
[/home/valeria/MyProject/VoCore/Buildroot-2/recov/build/uboot-v2020.10-rc3/.stamp_built]
 Error 2
Makefile:23: recipe for target '_all' failed
make: *** [_all] Error 2

and I have no idea how to fix this.

Any hint would be very welcome as this is a real show-stopper for me.

Thanks in Advance
Mauro
From 4a9d0b3ce9fcfca9fcb987f26c51600fee66b4e3 Mon Sep 17 00:00:00 2001
From: Mauro Condarelli 
Date: Wed, 2 Sep 2020 16:04:40 +0200
Subject: [PATCH 1/4] Small fixes to reduce size and ensure correct console
 output.

Signed-off-by: Mauro Condarelli 
---
 arch/mips/dts/vocore_vocore2.dts | 2 +-
 include/configs/vocore2.h| 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/mips/dts/vocore_vocore2.dts b/arch/mips/dts/vocore_vocore2.dts
index 3502e4b8b7..9adf39652f 100644
--- a/arch/mips/dts/vocore_vocore2.dts
+++ b/arch/mips/dts/vocore_vocore2.dts
@@ -59,7 +59,7 @@
 		#address-cells = <1>;
 		#size-cells = <1>;
 		compatible = "jedec,spi-nor";
-		spi-max-frequency = <2500>;
+		spi-max-frequency = <4000>;
 		reg = <0>;
 	};
 };
diff --

[RFC, v2] SquashFS not compiling due to missing __udivdi3 and __umoddi3

[Mauro Condarelli]

Second update.
It turns out I was  bit too aggressive in my "fix".
Unfortunately that is not cause of malfunction and
code is still unable to load files.
Any hint on how to proceed would be useful, current
plan is to add printouts to code to trace what happens,
but that is going to be a real PITA.

Thanks in Advance
Mauro


>From 74ba63e93099515950a8dcd57162d8f5b98b9e5d Mon Sep 17 00:00:00 2001
From: Mauro Condarelli 
Date: Thu, 3 Sep 2020 08:37:58 +0200
Subject: [PATCH 4/4] Fix missing __udivdi3 in SquashFS implementation.

Signed-off-by: Mauro Condarelli 
---
 fs/squashfs/sqfs.c   | 40 
 fs/squashfs/sqfs_inode.c |  8 
 2 files changed, 28 insertions(+), 20 deletions(-)

diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
index f67f7c4a40..2abb603afc 100644
--- a/fs/squashfs/sqfs.c
+++ b/fs/squashfs/sqfs.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "sqfs_decompressor.h"
 #include "sqfs_filesystem.h"
@@ -82,13 +83,16 @@ static int sqfs_count_tokens(const char *filename)
  */
 static int sqfs_calc_n_blks(__le64 start, __le64 end, u64 *offset)
 {
-    u64 start_, table_size;
+    u64 start_, table_size, blks;
 
 table_size = le64_to_cpu(end) - le64_to_cpu(start);
-    start_ = le64_to_cpu(start) / ctxt.cur_dev->blksz;
+    start_ = le64_to_cpu(start);
+    do_div(start_, ctxt.cur_dev->blksz);
 *offset = le64_to_cpu(start) - (start_ * ctxt.cur_dev->blksz);
 
-    return DIV_ROUND_UP(table_size + *offset, ctxt.cur_dev->blksz);
+    blks = table_size + *offset;
+    if (do_div(blks, ctxt.cur_dev->blksz)) blks++;
+    return blks;
 }
 
 /*
@@ -109,8 +113,8 @@ static int sqfs_frag_lookup(u32 inode_fragment_index,
 if (inode_fragment_index >= get_unaligned_le32(>fragments))
     return -EINVAL;
 
-    start = get_unaligned_le64(>fragment_table_start) /
-        ctxt.cur_dev->blksz;
+    start = get_unaligned_le64(>fragment_table_start);
+    do_div(start, ctxt.cur_dev->blksz);
 n_blks = sqfs_calc_n_blks(sblk->fragment_table_start,
               sblk->export_table_start,
               _offset);
@@ -135,7 +139,8 @@ static int sqfs_frag_lookup(u32 inode_fragment_index,
 start_block = get_unaligned_le64(table + table_offset + block *
                  sizeof(u64));
 
-    start = start_block / ctxt.cur_dev->blksz;
+    start = start_block;
+    do_div(start, ctxt.cur_dev->blksz);
 n_blks = sqfs_calc_n_blks(cpu_to_le64(start_block),
               sblk->fragment_table_start, _offset);
 
@@ -641,8 +646,8 @@ static int sqfs_read_inode_table(unsigned char 
**inode_table)
 
 table_size = get_unaligned_le64(>directory_table_start) -
     get_unaligned_le64(>inode_table_start);
-    start = get_unaligned_le64(>inode_table_start) /
-        ctxt.cur_dev->blksz;
+    start = get_unaligned_le64(>inode_table_start);
+    do_div(start, ctxt.cur_dev->blksz);
 n_blks = sqfs_calc_n_blks(sblk->inode_table_start,
               sblk->directory_table_start, _offset);
 
@@ -725,8 +730,8 @@ static int sqfs_read_directory_table(unsigned char 
**dir_table, u32 **pos_list)
 /* DIRECTORY TABLE */
 table_size = get_unaligned_le64(>fragment_table_start) -
     get_unaligned_le64(>directory_table_start);
-    start = get_unaligned_le64(>directory_table_start) /
-        ctxt.cur_dev->blksz;
+    start = get_unaligned_le64(>directory_table_start);
+    do_div(start, ctxt.cur_dev->blksz);
 n_blks = sqfs_calc_n_blks(sblk->directory_table_start,
               sblk->fragment_table_start, _offset);
 
@@ -1159,7 +1164,7 @@ static int sqfs_get_regfile_info(struct 
squashfs_reg_inode *reg,
     if (fentry->size < 1 || fentry->start < 0)
         return -EINVAL;
 } else {
-        datablk_count = DIV_ROUND_UP(finfo->size, le32_to_cpu(blksz));
+    datablk_count = DIV_ROUND_UP(finfo->size, le32_to_cpu(blksz));
 }
 
 finfo->blk_sizes = malloc(datablk_count * sizeof(u32));
@@ -1328,11 +1333,12 @@ int sqfs_read(const char *filename, void *buf, loff_t 
offset, loff_t len,
 }
 
 for (j = 0; j < datablk_count; j++) {
-        start = data_offset / ctxt.cur_dev->blksz;
+        start = data_offset;
+        do_div(start, ctxt.cur_dev->blksz);
     table_size = SQFS_BLOCK_SIZE(finfo.blk_sizes[j]);
     table_offset = data_offset - (start * ctxt.cur_dev->blksz);
-        n_blks = DIV_ROUND_UP(table_size + table_offset,
-                  ctxt.cur_dev->blksz);
+        n_blks = table_size + table_offset;
+        if (do_div(n_blks, ctxt.cur_dev->blksz)) n_blks++;
 
     data_buffer = malloc_cache_aligned(n_blks * ctxt.cur_dev->blksz);
 
@@ -1382,10 +1388,12 @@ int sqfs_read(const char *filename, void *buf, loff_t 
offset, loff_t len,
     goto free_buffer;
 }
 
-  

Re: SquashFS not compiling due to missing __udivdi3 and __umoddi3

[Mauro Condarelli]

Small update, see below.

On 9/3/20 10:41 AM, Mauro Condarelli wrote:
> Hi,
> enabling squashfs on my target (vocore2) result in multiple errors:
>
>> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>>  fs/built-in.o: in function `sqfs_calc_n_blks':
>> fs/squashfs/sqfs.c:(.text.sqfs_calc_n_blks+0x44): undefined reference to 
>> `__umoddi3'
>> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>>  fs/squashfs/sqfs.c:(.text.sqfs_calc_n_blks+0x98): undefined reference to 
>> `__udivdi3'
>> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>>  fs/built-in.o: in function `sqfs_frag_lookup':
>> fs/squashfs/sqfs.c:(.text.sqfs_frag_lookup+0x74): undefined reference to 
>> `__udivdi3'
>> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>>  fs/squashfs/sqfs.c:(.text.sqfs_frag_lookup+0x1b0): undefined reference to 
>> `__udivdi3'
>> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>>  fs/built-in.o: in function `sqfs_opendir':
>> (.text.sqfs_opendir+0xbc): undefined reference to `__udivdi3'
>> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>>  (.text.sqfs_opendir+0x178): undefined reference to `__udivdi3'
>> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>>  fs/built-in.o:(.text.sqfs_read+0x324): more undefined references to 
>> `__udivdi3' follow
>> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>>  fs/built-in.o: in function `sqfs_read':
>> (.text.sqfs_read+0x348): undefined reference to `__umoddi3'
>> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>>  (.text.sqfs_read+0x388): undefined reference to `__udivdi3'
>> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>>  (.text.sqfs_read+0x5bc): undefined reference to `__umoddi3'
>> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>>  (.text.sqfs_read+0x600): undefined reference to `__udivdi3'
>> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>>  (.text.sqfs_read+0x64c): undefined reference to `__udivdi3'
>> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>>  fs/built-in.o: in function `sqfs_inode_size':
>> (.text.sqfs_inode_size+0x140): undefined reference to `__udivdi3'
>> make[2]: *** [Makefile:1753: u-boot] Error 1
>> make[1]: *** [package/pkg-generic.mk:269: 
>> /home/mcon/vocore/__V2__/Buildroot-2/recov/build/uboot-v2020.10-rc3/.stamp_built]
>>  Error 2
>> make: *** [Makefile:23: _all] Error 2
> Following some advice on IRC (I can be contacted there as "mcon")
> I tried to fix issue by explicit calling `lldiv()` (full patch below).
> Fix allows full compilation, and is also somewhat working:
> Directory list works, file load does not :(
>
>> => ls mmc 0:6 /boot    
>>     0   not_mounted
>>   2512916   uImage
>>
>> 2 file(s), 0 dir(s)
>>
>> => load mmc 0:6 8500 /boot/uImage
>> Failed to load '/boot/uImage'
After load failure also dir listing becomes non-functional.
I didn't find any way to cure problem without full reboot.
I have no idea how to debug this.

=> ls mmc 0:6 /boot
    0   not_mounted
  2512916   uImage

2 file(s), 0 dir(s)

=> ls mmc 0:6 /root
   26   .profile
    .ssh/
  673   is_ssh3
 1251   kmsgd
    65536   master.bin
   77   persist_data.lst
  451   public.pem
 1186   termsize
 1675   update
 2853   verkey
 2336   wifi.py

10 file(s), 1 dir(s)

=> load mmc 0:6 8500 /root/persist_data.lst
Failed to load '/root/persist_data.lst'
=> ls mmc 0:6 /root   
=>

> Here I have two questions:
> 1) can someone check my patch end tell me where I goofed?
> 2) is this supposedly the right way to fix? One other suggestion I had
> on IRC is to simply implement __udivdi3/__umoddi3 in my architecture
> (i.e.: u-boot/arch/mips/lib), but that doesn't seem like what has been
> done in other places. I would like to provide an upstreamable patch.
>
>
> ==8<--- Here comes the (tentative) patch==
> From cfd07aac0aa00345df1a0f2fac04ee549c78f87a Mon Sep 17 00:00:00 2001
> From: Mauro Condarelli 
> Date: Thu, 3 Sep 2020 08:37:58 +0200
> Subject: [PATCH 4/4] Fix missing __udivdi3 in SquashFS implementation.
>
> Signed-off-by: 

SquashFS not compiling due to missing __udivdi3 and __umoddi3

[Mauro Condarelli]

Hi,
enabling squashfs on my target (vocore2) result in multiple errors:

> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>  fs/built-in.o: in function `sqfs_calc_n_blks':
> fs/squashfs/sqfs.c:(.text.sqfs_calc_n_blks+0x44): undefined reference to 
> `__umoddi3'
> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>  fs/squashfs/sqfs.c:(.text.sqfs_calc_n_blks+0x98): undefined reference to 
> `__udivdi3'
> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>  fs/built-in.o: in function `sqfs_frag_lookup':
> fs/squashfs/sqfs.c:(.text.sqfs_frag_lookup+0x74): undefined reference to 
> `__udivdi3'
> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>  fs/squashfs/sqfs.c:(.text.sqfs_frag_lookup+0x1b0): undefined reference to 
> `__udivdi3'
> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>  fs/built-in.o: in function `sqfs_opendir':
> (.text.sqfs_opendir+0xbc): undefined reference to `__udivdi3'
> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>  (.text.sqfs_opendir+0x178): undefined reference to `__udivdi3'
> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>  fs/built-in.o:(.text.sqfs_read+0x324): more undefined references to 
> `__udivdi3' follow
> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>  fs/built-in.o: in function `sqfs_read':
> (.text.sqfs_read+0x348): undefined reference to `__umoddi3'
> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>  (.text.sqfs_read+0x388): undefined reference to `__udivdi3'
> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>  (.text.sqfs_read+0x5bc): undefined reference to `__umoddi3'
> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>  (.text.sqfs_read+0x600): undefined reference to `__udivdi3'
> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>  (.text.sqfs_read+0x64c): undefined reference to `__udivdi3'
> /home/mcon/vocore/__V2__/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd:
>  fs/built-in.o: in function `sqfs_inode_size':
> (.text.sqfs_inode_size+0x140): undefined reference to `__udivdi3'
> make[2]: *** [Makefile:1753: u-boot] Error 1
> make[1]: *** [package/pkg-generic.mk:269: 
> /home/mcon/vocore/__V2__/Buildroot-2/recov/build/uboot-v2020.10-rc3/.stamp_built]
>  Error 2
> make: *** [Makefile:23: _all] Error 2

Following some advice on IRC (I can be contacted there as "mcon")
I tried to fix issue by explicit calling `lldiv()` (full patch below).
Fix allows full compilation, and is also somewhat working:
Directory list works, file load does not :(

> => ls mmc 0:6 /boot    
>     0   not_mounted
>   2512916   uImage
>
> 2 file(s), 0 dir(s)
>
> => load mmc 0:6 8500 /boot/uImage
> Failed to load '/boot/uImage'

Here I have two questions:
1) can someone check my patch end tell me where I goofed?
2) is this supposedly the right way to fix? One other suggestion I had
on IRC is to simply implement __udivdi3/__umoddi3 in my architecture
(i.e.: u-boot/arch/mips/lib), but that doesn't seem like what has been
done in other places. I would like to provide an upstreamable patch.


==8<--- Here comes the (tentative) patch==
>From cfd07aac0aa00345df1a0f2fac04ee549c78f87a Mon Sep 17 00:00:00 2001
From: Mauro Condarelli 
Date: Thu, 3 Sep 2020 08:37:58 +0200
Subject: [PATCH 4/4] Fix missing __udivdi3 in SquashFS implementation.

Signed-off-by: Mauro Condarelli 
---
 fs/squashfs/sqfs.c   | 27 ---
 fs/squashfs/sqfs_inode.c | 11 +--
 2 files changed, 25 insertions(+), 13 deletions(-)

diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
index f67f7c4a40..12115b6baa 100644
--- a/fs/squashfs/sqfs.c
+++ b/fs/squashfs/sqfs.c
@@ -23,6 +23,12 @@
 #include "sqfs_filesystem.h"
 #include "sqfs_utils.h"
 
+#include 
+#ifdef DIV_ROUND_UP
+#undef DIV_ROUND_UP
+#endif
+#define DIV_ROUND_UP(n,d) (lldiv(((n) + (d) - 1), (d)))
+
 static struct squashfs_ctxt ctxt;
 
 static int sqfs_disk_read(__u32 block, __u32 nr_blocks, void *buf)
@@ -85,7 +91,7 @@ static int sqfs_calc_n_blks(__le64 start, __le64 end, u64 
*offset)
 u64 start_, table_size;
 
 table_size = le64_to_cpu(end) - le64_to_cpu(start);
-    start_ = le64_to_cpu(start) / ctxt.cur_dev->blksz;
+    start_ = lldiv(le64_to_cpu(start), ctxt.cur_dev->blksz);
 *offset = le64_to_cpu(start) - (start_ * ctxt.cur_dev->blksz);
 
 return DIV_ROUND_UP(

Re: from https://gitlab.denx.de/u-boot/custodians/u-boot-mips:f3d8c7f8d3c02ff1de172aff7e6392a9ddd1f5b2 to master:

[Mauro Condarelli]

Hi Daniel,
Hi Stefan,
comments inline below.

Many Thanks
Mauro

On 9/1/20 1:41 AM, Daniel Schwierzeck wrote:
> Am Montag, den 31.08.2020, 23:53 +0200 schrieb Mauro Condarelli:
>> Thanks Daniel.
>>
>> On 8/31/20 10:36 PM, Daniel Schwierzeck wrote:
>>> Hi Mauro,
>>>
>>> Am Montag, den 31.08.2020, 21:57 +0200 schrieb Mauro Condarelli:
>>>> Sorry to disturb :(
>>>>
>>>> I am trying to switch from  
>>>> https://gitlab.denx.de/u-boot/custodians/u-boot-mips commit 
>>>> f3d8c7f8d3c02ff1de172aff7e6392a9ddd1f5b2 to master.
>>>> In both case I'm using plain "vocore2_defconfig".
>>>>
>>>> Actually I'm using:
>>>>   make ARCH=mips 
>>>> CROSS_COMPILE=~/vocore/__V2__/Buildroot-2/mipsel-buildroot-linux-uclibc_sdk-buildroot/bin/mipsel-linux-
>>>>  all
>>>> for master and Buildroot compilation environment for `u-boot-mips`, but I 
>>>> don't think that's the problem (compiler is the same, if needed I'll 
>>>> recompile manually "old" also).
>>>>
>>>> Of course the two versions have tons of differences, but .config is 
>>>> essentially the same (some reordering and a few apparently harmless new 
>>>> CONFIG_s; iff deemed useful I can post both, but, as said, I'm using 
>>>> in-tree vocore2_defconfig in both cases).
>>>>
>>>> First thing is something changed in compilation and the old 
>>>> "u-boot-mtmips.bin" si nowhere to be found, apparently replaced by 
>>>> "u-boot-with-spl.bin".
>>>>
>>>> Second data point is new u-boot is substantially larger:
>>>>
>>>> -rwxr-xr-x1 root root244580 Aug 31 20:06 u-boot-mtmips.bin
>>>> -rwxr-xr-x1 root root275005 Aug 31 20:00 
>>>> u-boot-with-spl.bin
>>>>
>>>> Third and most important new version does not work:
>>>>
>>>> ===
>>>> U-Boot SPL 2020.04-rc1 (Mar 29 2020 - 17:07:13 +0200)
>>>> Trying to boot from NOR
>>>>
>>>>
>>>> U-Boot 2020.04-rc1 (Mar 29 2020 - 17:07:13 +0200)
>>>>
>>>> CPU:   MediaTek MT7628A ver:1 eco:2
>>>> Boot:  DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL
>>>> Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
>>>> DRAM:  128 MiB
>>>> WDT:   Started with servicing (60s timeout)
>>>> MMC:   mmc@1013: 0
>>>> Loading Environment from SPI Flash... SF: Detected w25q128 with page size 
>>>> 256 Bytes, erase size 4 KiB, total 16 MiB
>>>> OK
>>>> In:uart2@e00
>>>> Out:   uart2@e00
>>>> Err:   uart2@e00
>>>> Model: VoCore2
>>>> Net:  
>>>> Warning: eth@1011 (eth0) using random MAC address - b6:bf:30:14:ba:25
>>>> eth0: eth@1011
>>>> Hit any key to stop autoboot:  0
>>>> => load mmc  0:1 8001 u-boot-mtmips.bin && go ${fileaddr}
>>>> 244580 bytes read in 17 ms (13.7 MiB/s)
>>>> ## Starting application at 0x8001 ...
>>>>
>>>> U-Boot SPL 2020.04-rc1 (Mar 29 2020 - 17:07:13 +0200)
>>>> Trying to boot from NOR
>>>>
>>>>
>>>> U-Boot 2020.04-rc1 (Mar 29 2020 - 17:07:13 +0200)
>>>>
>>>> CPU:   MediaTek MT7628A ver:1 eco:2
>>>> Boot:  DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL
>>>> Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
>>>> DRAM:  128 MiB
>>>> WDT:   Started with servicing (60s timeout)
>>>> MMC:   mmc@1013: 0
>>>> Loading Environment from SPI Flash... SF: Detected w25q128 with page size 
>>>> 256 Bytes, erase size 4 KiB, total 16 MiB
>>>> OK
>>>> In:uart2@e00
>>>> Out:   uart2@e00
>>>> Err:   uart2@e00
>>>> Model: VoCore2
>>>> Net:  
>>>> Warning: eth@1011 (eth0) using random MAC address - 36:f2:c3:0a:27:a4
>>>> eth0: eth@1011
>>>> Hit any key to stop autoboot:  0
>>>> =>
>>>> ===
>>>> U-Boot SPL 2020.04-rc1 (Mar 29 2020 - 17:07:13 +0200)
>>>> Trying to boot from NOR
>>>>
>>>>
>>>> U-Boot 2020.04-rc1 (Mar 29 2020 - 17:07:13 +0200)
>>>>
>>>> CPU:   MediaTek MT7628A ver:1 eco:2
>>>> Boot:  DDR2, SPI-NOR 3-Byte Addr, CPU clo

Re: from https://gitlab.denx.de/u-boot/custodians/u-boot-mips:f3d8c7f8d3c02ff1de172aff7e6392a9ddd1f5b2 to master:

[Mauro Condarelli]

Thanks Daniel.

On 8/31/20 10:36 PM, Daniel Schwierzeck wrote:
> Hi Mauro,
>
> Am Montag, den 31.08.2020, 21:57 +0200 schrieb Mauro Condarelli:
>> Sorry to disturb :(
>>
>> I am trying to switch from  
>> https://gitlab.denx.de/u-boot/custodians/u-boot-mips commit 
>> f3d8c7f8d3c02ff1de172aff7e6392a9ddd1f5b2 to master.
>> In both case I'm using plain "vocore2_defconfig".
>>
>> Actually I'm using:
>>   make ARCH=mips 
>> CROSS_COMPILE=~/vocore/__V2__/Buildroot-2/mipsel-buildroot-linux-uclibc_sdk-buildroot/bin/mipsel-linux-
>>  all
>> for master and Buildroot compilation environment for `u-boot-mips`, but I 
>> don't think that's the problem (compiler is the same, if needed I'll 
>> recompile manually "old" also).
>>
>> Of course the two versions have tons of differences, but .config is 
>> essentially the same (some reordering and a few apparently harmless new 
>> CONFIG_s; iff deemed useful I can post both, but, as said, I'm using in-tree 
>> vocore2_defconfig in both cases).
>>
>> First thing is something changed in compilation and the old 
>> "u-boot-mtmips.bin" si nowhere to be found, apparently replaced by 
>> "u-boot-with-spl.bin".
>>
>> Second data point is new u-boot is substantially larger:
>>
>> -rwxr-xr-x1 root root244580 Aug 31 20:06 u-boot-mtmips.bin
>> -rwxr-xr-x1 root root275005 Aug 31 20:00 u-boot-with-spl.bin
>>
>> Third and most important new version does not work:
>>
>> ===
>> U-Boot SPL 2020.04-rc1 (Mar 29 2020 - 17:07:13 +0200)
>> Trying to boot from NOR
>>
>>
>> U-Boot 2020.04-rc1 (Mar 29 2020 - 17:07:13 +0200)
>>
>> CPU:   MediaTek MT7628A ver:1 eco:2
>> Boot:  DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL
>> Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
>> DRAM:  128 MiB
>> WDT:   Started with servicing (60s timeout)
>> MMC:   mmc@1013: 0
>> Loading Environment from SPI Flash... SF: Detected w25q128 with page size 
>> 256 Bytes, erase size 4 KiB, total 16 MiB
>> OK
>> In:uart2@e00
>> Out:   uart2@e00
>> Err:   uart2@e00
>> Model: VoCore2
>> Net:  
>> Warning: eth@1011 (eth0) using random MAC address - b6:bf:30:14:ba:25
>> eth0: eth@1011
>> Hit any key to stop autoboot:  0
>> => load mmc  0:1 8001 u-boot-mtmips.bin && go ${fileaddr}
>> 244580 bytes read in 17 ms (13.7 MiB/s)
>> ## Starting application at 0x8001 ...
>>
>> U-Boot SPL 2020.04-rc1 (Mar 29 2020 - 17:07:13 +0200)
>> Trying to boot from NOR
>>
>>
>> U-Boot 2020.04-rc1 (Mar 29 2020 - 17:07:13 +0200)
>>
>> CPU:   MediaTek MT7628A ver:1 eco:2
>> Boot:  DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL
>> Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
>> DRAM:  128 MiB
>> WDT:   Started with servicing (60s timeout)
>> MMC:   mmc@1013: 0
>> Loading Environment from SPI Flash... SF: Detected w25q128 with page size 
>> 256 Bytes, erase size 4 KiB, total 16 MiB
>> OK
>> In:uart2@e00
>> Out:   uart2@e00
>> Err:   uart2@e00
>> Model: VoCore2
>> Net:  
>> Warning: eth@1011 (eth0) using random MAC address - 36:f2:c3:0a:27:a4
>> eth0: eth@1011
>> Hit any key to stop autoboot:  0
>> =>
>> ===
>> U-Boot SPL 2020.04-rc1 (Mar 29 2020 - 17:07:13 +0200)
>> Trying to boot from NOR
>>
>>
>> U-Boot 2020.04-rc1 (Mar 29 2020 - 17:07:13 +0200)
>>
>> CPU:   MediaTek MT7628A ver:1 eco:2
>> Boot:  DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL
>> Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
>> DRAM:  128 MiB
>> WDT:   Started with servicing (60s timeout)
>> MMC:   mmc@1013: 0
>> Loading Environment from SPI Flash... SF: Detected w25q128 with page size 
>> 256 Bytes, erase size 4 KiB, total 16 MiB
>> OK
>> In:uart2@e00
>> Out:   uart2@e00
>> Err:   uart2@e00
>> Model: VoCore2
>> Net:  
>> Warning: eth@1011 (eth0) using random MAC address - 1e:a9:c5:a8:35:82
>> eth0: eth@1011
>> Hit any key to stop autoboot:  0
>> => load mmc  0:1 8001 u-boot-with-spl.bin && go ${fileaddr}
>> 275005 bytes read in 20 ms (13.1 MiB/s)
>> ## Starting application at 0x8001 ...
>> <>
>> ===
>>
>> What am I doing so wrong?
>>
>> I'm available to all possible tests, but I'm, most likely, just m

from https://gitlab.denx.de/u-boot/custodians/u-boot-mips:f3d8c7f8d3c02ff1de172aff7e6392a9ddd1f5b2 to master:

[Mauro Condarelli]

Sorry to disturb :(

I am trying to switch from  
https://gitlab.denx.de/u-boot/custodians/u-boot-mips commit 
f3d8c7f8d3c02ff1de172aff7e6392a9ddd1f5b2 to master.
In both case I'm using plain "vocore2_defconfig".

Actually I'm using:
  make ARCH=mips 
CROSS_COMPILE=~/vocore/__V2__/Buildroot-2/mipsel-buildroot-linux-uclibc_sdk-buildroot/bin/mipsel-linux-
 all
for master and Buildroot compilation environment for `u-boot-mips`, but I don't 
think that's the problem (compiler is the same, if needed I'll recompile 
manually "old" also).

Of course the two versions have tons of differences, but .config is essentially 
the same (some reordering and a few apparently harmless new CONFIG_s; iff 
deemed useful I can post both, but, as said, I'm using in-tree 
vocore2_defconfig in both cases).

First thing is something changed in compilation and the old "u-boot-mtmips.bin" 
si nowhere to be found, apparently replaced by "u-boot-with-spl.bin".

Second data point is new u-boot is substantially larger:

-rwxr-xr-x    1 root root    244580 Aug 31 20:06 u-boot-mtmips.bin
-rwxr-xr-x    1 root root    275005 Aug 31 20:00 u-boot-with-spl.bin

Third and most important new version does not work:

===
U-Boot SPL 2020.04-rc1 (Mar 29 2020 - 17:07:13 +0200)
Trying to boot from NOR


U-Boot 2020.04-rc1 (Mar 29 2020 - 17:07:13 +0200)

CPU:   MediaTek MT7628A ver:1 eco:2
Boot:  DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL
Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
DRAM:  128 MiB
WDT:   Started with servicing (60s timeout)
MMC:   mmc@1013: 0
Loading Environment from SPI Flash... SF: Detected w25q128 with page size 256 
Bytes, erase size 4 KiB, total 16 MiB
OK
In:    uart2@e00
Out:   uart2@e00
Err:   uart2@e00
Model: VoCore2
Net:  
Warning: eth@1011 (eth0) using random MAC address - b6:bf:30:14:ba:25
eth0: eth@1011
Hit any key to stop autoboot:  0
=> load mmc  0:1 8001 u-boot-mtmips.bin && go ${fileaddr}
244580 bytes read in 17 ms (13.7 MiB/s)
## Starting application at 0x8001 ...

U-Boot SPL 2020.04-rc1 (Mar 29 2020 - 17:07:13 +0200)
Trying to boot from NOR


U-Boot 2020.04-rc1 (Mar 29 2020 - 17:07:13 +0200)

CPU:   MediaTek MT7628A ver:1 eco:2
Boot:  DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL
Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
DRAM:  128 MiB
WDT:   Started with servicing (60s timeout)
MMC:   mmc@1013: 0
Loading Environment from SPI Flash... SF: Detected w25q128 with page size 256 
Bytes, erase size 4 KiB, total 16 MiB
OK
In:    uart2@e00
Out:   uart2@e00
Err:   uart2@e00
Model: VoCore2
Net:  
Warning: eth@1011 (eth0) using random MAC address - 36:f2:c3:0a:27:a4
eth0: eth@1011
Hit any key to stop autoboot:  0
=>
===
U-Boot SPL 2020.04-rc1 (Mar 29 2020 - 17:07:13 +0200)
Trying to boot from NOR


U-Boot 2020.04-rc1 (Mar 29 2020 - 17:07:13 +0200)

CPU:   MediaTek MT7628A ver:1 eco:2
Boot:  DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL
Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
DRAM:  128 MiB
WDT:   Started with servicing (60s timeout)
MMC:   mmc@1013: 0
Loading Environment from SPI Flash... SF: Detected w25q128 with page size 256 
Bytes, erase size 4 KiB, total 16 MiB
OK
In:    uart2@e00
Out:   uart2@e00
Err:   uart2@e00
Model: VoCore2
Net:  
Warning: eth@1011 (eth0) using random MAC address - 1e:a9:c5:a8:35:82
eth0: eth@1011
Hit any key to stop autoboot:  0
=> load mmc  0:1 8001 u-boot-with-spl.bin && go ${fileaddr}
275005 bytes read in 20 ms (13.1 MiB/s)
## Starting application at 0x8001 ...
<>
===

What am I doing so wrong?

I'm available to all possible tests, but I'm, most likely, just missing 
something obvious.
I'm also available on IRC as "mcon".

Thanks in advance.
Mauro Condarelli

Status of "Refactor the architecture parts of mt7628" series?

[Mauro Condarelli]

Hi,
just a timid information request.

What is current status of Weijie Gao patch series in subject? (actually
"Untitled series #158043 - #158064")
AFAIK they are in u-boot-mips/testing.
Is there chance to see them in mainline? (my own "[v6] Add support for
SoM "VoCore2"." needs them)
They seem to work well for me.

TiA!
Mauro

[PATCH v6] Add support for SoM "VoCore2".

[Mauro Condarelli]

Small patch to add support for VoCore/VoCore2 board.

VoCore is open hardware and runs OpenWrt/LEDE.
It has WIFI, USB, UART, 20+ GPIOs but is only one inch square.
It will help you to make a smart house, study embedded system
or even make the tiniest router in the world.

Details about this SoM can be found at "https://vocore.io/v2.html;.

Signed-off-by: Mauro Condarelli 
---

Changes in v6:
- Added MAINTAINERS file.
- Removed project-specific configs/vocore2_defconfig_ENV_IN_FAT.
- Removed guard for SPL Serial definitions in include/configs/vocore2.h.
- Removed Baudrate Table definition in include/configs/vocore2.h.
- Moved board-specific DTS settingsto arch/mips/dts/vocore_vocore2.dts.
- Added UART2 pin definitions to arch/mips/dts/vocore_vocore2.dts.
- Removed unused mmc pin definition from arch/mips/dts/vocore_vocore2.dts.
- Added select of SPL_UART2_SPIS_PINMUX in board choice.
- Updated configs/vocore2_defconfig.

Changes in v5:
- Removed unneeded (and wrong) UART2 initialization in board.c
- Added network setup.
- Removed project-specific code.
- Move back environment to SPI NOR.
- Changes to environment default settings.
- Rebase on current u-boot-mips/testing.

Changes in v4:
- Reverted some overzealous DTS cleaning.
- Added support for bootcount.

Changes in v3:
- based on top of Weijie Gao patchset:
"[v3,xx/20]Refactor the architecture parts of mt7628"

Changes in v2:
- Removed some dead code
- Changed Author to my full name (no nick)
- Removed unwanted fixup to .dts generation (not my call).
- Fixed commit message
- Fixed various variables/filenames to include Vendor name
- Changed Vendor name (Vonger -> Vocore)

 arch/mips/dts/Makefile   |   1 +
 arch/mips/dts/vocore_vocore2.dts |  85 ++
 arch/mips/mach-mtmips/Kconfig|  10 +++
 board/vocore/vocore2/Kconfig |  12 
 board/vocore/vocore2/MAINTAINERS |   7 +++
 board/vocore/vocore2/Makefile|   3 +
 board/vocore/vocore2/board.c |   6 ++
 configs/vocore2_defconfig| 101 +++
 include/configs/vocore2.h|  54 +
 9 files changed, 279 insertions(+)
 create mode 100644 arch/mips/dts/vocore_vocore2.dts
 create mode 100644 board/vocore/vocore2/Kconfig
 create mode 100644 board/vocore/vocore2/MAINTAINERS
 create mode 100644 board/vocore/vocore2/Makefile
 create mode 100644 board/vocore/vocore2/board.c
 create mode 100644 configs/vocore2_defconfig
 create mode 100644 include/configs/vocore2.h

diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
index cbd0c8bc8b..f711e9fb59 100644
--- a/arch/mips/dts/Makefile
+++ b/arch/mips/dts/Makefile
@@ -23,6 +23,7 @@ dtb-$(CONFIG_BOARD_NETGEAR_DGND3700V2) += 
netgear,dgnd3700v2.dtb
 dtb-$(CONFIG_BOARD_SAGEM_FAST1704) += sagem,f...@st1704.dtb
 dtb-$(CONFIG_BOARD_SFR_NB4_SER) += sfr,nb4-ser.dtb
 dtb-$(CONFIG_BOARD_TPLINK_WDR4300) += tplink_wdr4300.dtb
+dtb-$(CONFIG_BOARD_VOCORE2) += vocore_vocore2.dtb
 dtb-$(CONFIG_TARGET_JZ4780_CI20) += ci20.dtb
 dtb-$(CONFIG_SOC_LUTON) += luton_pcb090.dtb luton_pcb091.dtb
 dtb-$(CONFIG_SOC_OCELOT) += ocelot_pcb120.dtb ocelot_pcb123.dtb
diff --git a/arch/mips/dts/vocore_vocore2.dts b/arch/mips/dts/vocore_vocore2.dts
new file mode 100644
index 00..3502e4b8b7
--- /dev/null
+++ b/arch/mips/dts/vocore_vocore2.dts
@@ -0,0 +1,85 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Mauro Condarelli 
+ */
+
+/dts-v1/;
+
+#include "mt7628a.dtsi"
+#include 
+
+/ {
+   compatible = "vocore,vocore2", "ralink,mt7628a-soc";
+   model = "VoCore2";
+
+   aliases {
+   serial0 = 
+   spi0 = 
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x0800>;
+   };
+   leds {
+   compatible = "gpio-leds";
+
+   power {
+   label = "vocore:power";
+   gpios = < 12 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   };
+   };
+
+   chosen {
+   bootargs = "console=ttyS2,115200";
+   stdout-path = 
+   };
+};
+
+ {
+   state_default: pin_state {
+   p0led {
+   groups = "p0led_a";
+   function = "led";
+   };
+   };
+};
+
+ {
+   status = "okay";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_pwm_pins>;
+};
+
+ {
+   status = "okay";
+   nor0: spi-flash@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "jedec,spi-nor";
+   spi-max-frequency = <2500>;
+   reg = <0>;
+   };
+};
+
+ {
+   status = "okay";
+
+   pinctrl-names = "defau

Re: [PATCH v5] Add support for SoM "VoCore2".

[Mauro Condarelli]

Hi Daniel,
a gentle reminder...

I was unable to comply with a few of Your remarks (see below),
What should I do?
Submit v6 as is or do You have specific instructions?

Thanks a lot
Mauro

On 2/12/20 11:01 PM, Mauro Condarelli wrote:
> Thanks Daniel,
>
> On 2/12/20 5:58 PM, Daniel Schwierzeck wrote:
>> On Wed, Feb 12, 2020 at 4:30 PM Mauro Condarelli  wrote:
>>> Small patch series to add support for VoCore/VoCore2 board.
>>>
>>> VoCore is open hardware and runs OpenWrt/LEDE.
>>> It has WIFI, USB, UART, 20+ GPIOs but is only one inch square.
>>> It will help you to make a smart house, study embedded system
>>> or even make the tiniest router in the world.
>>>
>>> ===8<---
>>> diff --git a/board/vocore/vocore2/board.c b/board/vocore/vocore2/board.c
>>> new file mode 100644
>>> index 00..27e42d1414
>>> --- /dev/null
>>> +++ b/board/vocore/vocore2/board.c
>>> @@ -0,0 +1,6 @@
>>> +// SPDX-License-Identifier: GPL-2.0+
>>> +/*
>>> + * Copyright (C) 2019 Mauro Condarelli 
>>> + *
>>> + * Nothing actually needed here
>>> + */
>> if that file is empty, don't add it at all
> Ahem...
>
> I tried to remove it, but if I do I also have to remove entry
> in board/vocore/vocore2/Makefile (leaving it empty) and this
> leads (on a clean compile) to error:
>   mipsel-linux-ld.bfd: cannot find board/vocore/vocore2/built-in.o: No
> such file or directory
> Completely removing both files bombs with:
>   scripts/Makefile.build:57: board/vocore/vocore2/Makefile: No such file
> or directory
> It seems I should also remove board/vocore/vocore2/Kconfig,
> but I'm unsure this is the right thing to do.
>
> I have no idea about how to solve this, sorry.
> Can You point me in the right direction, please?
>
>
>>> ===8<---
>>> diff --git a/include/configs/vocore2.h b/include/configs/vocore2.h
>>> new file mode 100644
>>> index 00..6b43aa766e
>>> --- /dev/null
>>> +++ b/include/configs/vocore2.h
>>> @@ -0,0 +1,61 @@
>>> +/* SPDX-License-Identifier: GPL-2.0+ */
>>> +/*
>>> + * Copyright (C) 2019 Mauro Condarelli 
>>> + */
>>> +
>>> +#ifndef __VOCORE2_CONFIG_H__
>>> +#define __VOCORE2_CONFIG_H__
>>> +
>>> +/* CPU */
>>> +#define CONFIG_SYS_MIPS_TIMER_FREQ 29000
>> is this still necessary? Weijie implemented a custom CPU clock
>> handling which supports
>> dynamic timer clocks.
> This is referenced in arch/mips/cpu/time.c
> I don't know if it's still relevant, but removing it doesn't seem
> task for this patch.
>
>
>>> +
>>> +/* RAM */
>>> +#define CONFIG_SYS_SDRAM_BASE  0x8000
>>> +
>>> +#define CONFIG_SYS_LOAD_ADDR   CONFIG_SYS_SDRAM_BASE + 0x10
>>> +
>>> +#define CONFIG_SYS_INIT_SP_OFFSET  0x40
>>> +
>>> +/* SPL */
>>> +#if defined(CONFIG_SPL) && !defined(CONFIG_SPL_BUILD)
>>> +#define CONFIG_SKIP_LOWLEVEL_INIT
>>> +#endif
>> CONFIG_SPL_BUILD is only relevant in Makefiles and shouldn't be used
>> in config header files
> Removed, apparently without adverse consequences.
Appearence was misguiding.
Any change to this guard leads to code unable to boot from SPI NOR.
I'll have to leave it is as-is.
Someone more knowledgeable than me will have to understand why
they are needed and how to remove them, if that's a requirement.
After all the other boards with this SoC use the same code.


>>> +
>>> +#define CONFIG_SYS_UBOOT_START CONFIG_SYS_TEXT_BASE
>>> +#define CONFIG_SPL_BSS_START_ADDR  0x8001
>>> +#define CONFIG_SPL_BSS_MAX_SIZE0x1
>>> +#define CONFIG_SPL_MAX_SIZE0x1
>>> +
>>> +/* Dummy value */
>>> +#define CONFIG_SYS_UBOOT_BASE  0
>> where is that needed?
> This is referenced in common/spl/spl_nor.c
> I don't know if it's still relevant, but removing it doesn't seem
> task for this patch.
>
>>> ==8<---
>>>
> I'll wait for input before submitting another iteration.
>
> Thanks a lot
> Mauro

Re: [PATCH v5] Add support for SoM "VoCore2".

[Mauro Condarelli]

Hi Daniel,

On 2/12/20 11:01 PM, Mauro Condarelli wrote:
>>> +
>>> +/* SPL */
>>> +#if defined(CONFIG_SPL) && !defined(CONFIG_SPL_BUILD)
>>> +#define CONFIG_SKIP_LOWLEVEL_INIT
>>> +#endif
>> CONFIG_SPL_BUILD is only relevant in Makefiles and shouldn't be used
>> in config header files
> Removed, apparently without adverse consequences.
Appearence was misguiding.
Any change to this guard leads to code unable to boot from SPI NOR.
I'll have to leave it is as-is.
Someone more knowledgeable than me will have to understand why
they are needed and how to remove them, if that's a requirement.
After all the other boards with this SoC use the same code.

Regards
Mauro

Re: [PATCH v5] Add support for SoM "VoCore2".

[Mauro Condarelli]

Hi Weijie,

On 2/13/20 10:09 AM, Mauro Condarelli wrote:
>>> +};
>>> diff --git a/arch/mips/mach-mtmips/Kconfig b/arch/mips/mach-mtmips/Kconfig
>>> index bcd635f438..489e466daf 100644
>>> --- a/arch/mips/mach-mtmips/Kconfig
>>> +++ b/arch/mips/mach-mtmips/Kconfig
>>> @@ -83,6 +83,13 @@ config BOARD_MT7628_RFB
>>>   SPI-NOR flash, 1 built-in switch with 5 ports, 1 UART, 1 USB host,
>>>   1 SDXC, 1 PCIe socket and JTAG pins.
>>>  
>>> +config BOARD_VOCORE2
>>> +   bool "VoCore2"
>>> +   depends on SOC_MT7628
>>> +   help
>>> + VoCore VoCore2 board has a MT7628 SoC with 128 MiB of RAM
>>> + and 16 MiB of flash (SPI).
>>> +
>> if CONFIG_SPL_UART2_SPIS_PINMUX is the only uart pinmux used by the
>> board, you can add "select CONFIG_SPL_UART2_SPIS_PINMUX" here.
> I thought about this, but I was unsure.
> Will do in v6.

While testing this I noticed it's possible to select SPL_UART2_SPIS_PINMUX
*without* SPL_SERIAL_SUPPORT, leading to an invalid configuration.

IMHO we should have either a:
  "depends on SPL_SERIAL_SUPPORT"
or (perhaps better) a:
  "select SPL_SERIAL_SUPPORT"
in definition of SPL_UART2_SPIS_PINMUX.

I can provide a separate patch as this is not board-specific, but it seems
to be Your call.

Alternatively I can add "select SPL_SERIAL_SUPPORT" to my board
definition, but this doesn't look right to me.

Please advise.

Many Thanks
Mauro

Re: [PATCH v5] Add support for SoM "VoCore2".

[Mauro Condarelli]

Thanks Stefan.

On 2/13/20 10:21 AM, Stefan wrote:
> On 13.02.20 10:18, Mauro Condarelli wrote:
>> Thanks Stefan.
>>
>> On 2/13/20 7:50 AM, Stefan wrote:
>>> On 12.02.20 16:30, Mauro Condarelli wrote:
>>>> Small patch series to add support for VoCore/VoCore2 board.
>>>>
>>>> VoCore is open hardware and runs OpenWrt/LEDE.
>>>> It has WIFI, USB, UART, 20+ GPIOs but is only one inch square.
>>>> It will help you to make a smart house, study embedded system
>>>> or even make the tiniest router in the world.
>>>>
>>>> Details about this SoM can be found at "https://vocore.io/v2.html;.
>>>>
>>>> Signed-off-by: Mauro Condarelli 
>>>> ---
>>>>
>>>> Changes in v5:
>>>> - Removed unneeded (and wrong) UART2 initialization in board.c
>>>> - Added network setup.
>>>> - Removed project-specific code.
>>>> - Move back environment to SPI NOR.
>>>> - Changes to environment default settings.
>>>> - Rebase on current u-boot-mips/testing
>>>>
>>>> Changes in v4:
>>>> - Reverted some overzealous DTS cleaning.
>>>> - Added support for bootcount
>>>>
>>>> Changes in v3:
>>>> - based on top of Weijie Gao patchset:
>>>>   "[v3,xx/20]Refactor the architecture parts of mt7628"
>>>>
>>>> Changes in v2:
>>>> - Removed some dead code
>>>> - Changed Author to my full name (no nick)
>>>> - Removed unwanted fixup to .dts generation (not my call).
>>>> - Fixed commit message
>>>> - Fixed various variables/filenames to include Vendor name
>>>> - Changed Vendor name (Vonger -> Vocore)
>>>>
>>>>    arch/mips/dts/Makefile   |   1 +
>>>>    arch/mips/dts/mt7628a.dtsi   |   5 ++
>>>>    arch/mips/dts/vocore_vocore2.dts |  78 
>>>>    arch/mips/mach-mtmips/Kconfig    |   8 +++
>>>>    board/vocore/vocore2/Kconfig |  12 
>>>>    board/vocore/vocore2/Makefile    |   3 +
>>>>    board/vocore/vocore2/board.c |   6 ++
>>>>    configs/vocore2_defconfig    | 103
>>>> ++
>>>>    configs/vocore2_defconfig_ENV_IN_FAT | 104
>>>> +++
>>>>    include/configs/vocore2.h    |  61 
>>>>    10 files changed, 381 insertions(+)
>>>>    create mode 100644 arch/mips/dts/vocore_vocore2.dts
>>>>    create mode 100644 board/vocore/vocore2/Kconfig
>>>>    create mode 100644 board/vocore/vocore2/Makefile
>>>>    create mode 100644 board/vocore/vocore2/board.c
>>>>    create mode 100644 configs/vocore2_defconfig
>>>>    create mode 100644 configs/vocore2_defconfig_ENV_IN_FAT
>>>>    create mode 100644 include/configs/vocore2.h
>>>
>>> Apart from the other comments, the MAINTAINERS file is missing. Please
>>> add it in the next patch version.
>> Yes, I know.
>> Also patman was complaining.
>> I perused MAINTAINERS and it didn't look like specific board
>> maintainers are in.
>> I have no problems adding me to the list, but I'm unsure I have
>> the privilege and it's unclear where I should add myself.
>
> I was not referring to the global MAINTAINERS file but the one located
> in the board directory. Please see:
>
> board/gardena/smart-gateway-mt7688/MAINTAINERS
Oops!
I completely overlooked that.
Done.


> Thanks,
> Stefan

Many Thanks
Mauro

Re: [PATCH v5] Add support for SoM "VoCore2".

[Mauro Condarelli]

Thanks Stefan.

On 2/13/20 7:50 AM, Stefan wrote:
> On 12.02.20 16:30, Mauro Condarelli wrote:
>> Small patch series to add support for VoCore/VoCore2 board.
>>
>> VoCore is open hardware and runs OpenWrt/LEDE.
>> It has WIFI, USB, UART, 20+ GPIOs but is only one inch square.
>> It will help you to make a smart house, study embedded system
>> or even make the tiniest router in the world.
>>
>> Details about this SoM can be found at "https://vocore.io/v2.html;.
>>
>> Signed-off-by: Mauro Condarelli 
>> ---
>>
>> Changes in v5:
>> - Removed unneeded (and wrong) UART2 initialization in board.c
>> - Added network setup.
>> - Removed project-specific code.
>> - Move back environment to SPI NOR.
>> - Changes to environment default settings.
>> - Rebase on current u-boot-mips/testing
>>
>> Changes in v4:
>> - Reverted some overzealous DTS cleaning.
>> - Added support for bootcount
>>
>> Changes in v3:
>> - based on top of Weijie Gao patchset:
>>  "[v3,xx/20]Refactor the architecture parts of mt7628"
>>
>> Changes in v2:
>> - Removed some dead code
>> - Changed Author to my full name (no nick)
>> - Removed unwanted fixup to .dts generation (not my call).
>> - Fixed commit message
>> - Fixed various variables/filenames to include Vendor name
>> - Changed Vendor name (Vonger -> Vocore)
>>
>>   arch/mips/dts/Makefile   |   1 +
>>   arch/mips/dts/mt7628a.dtsi   |   5 ++
>>   arch/mips/dts/vocore_vocore2.dts |  78 
>>   arch/mips/mach-mtmips/Kconfig    |   8 +++
>>   board/vocore/vocore2/Kconfig |  12 
>>   board/vocore/vocore2/Makefile    |   3 +
>>   board/vocore/vocore2/board.c |   6 ++
>>   configs/vocore2_defconfig    | 103 ++
>>   configs/vocore2_defconfig_ENV_IN_FAT | 104 +++
>>   include/configs/vocore2.h    |  61 
>>   10 files changed, 381 insertions(+)
>>   create mode 100644 arch/mips/dts/vocore_vocore2.dts
>>   create mode 100644 board/vocore/vocore2/Kconfig
>>   create mode 100644 board/vocore/vocore2/Makefile
>>   create mode 100644 board/vocore/vocore2/board.c
>>   create mode 100644 configs/vocore2_defconfig
>>   create mode 100644 configs/vocore2_defconfig_ENV_IN_FAT
>>   create mode 100644 include/configs/vocore2.h
>
> Apart from the other comments, the MAINTAINERS file is missing. Please
> add it in the next patch version.
Yes, I know.
Also patman was complaining.
I perused MAINTAINERS and it didn't look like specific board
maintainers are in.
I have no problems adding me to the list, but I'm unsure I have
the privilege and it's unclear where I should add myself.

Please advise.

>
> Thanks,
> Stefan
Thanks in Advance
Mauro

Re: [PATCH v5] Add support for SoM "VoCore2".

[Mauro Condarelli]

Thanks Weijie.

On 2/13/20 3:32 AM, Weijie Gao wrote:
> On Wed, 2020-02-12 at 16:30 +0100, Mauro Condarelli wrote:
>> Small patch series to add support for VoCore/VoCore2 board.
>>
>> VoCore is open hardware and runs OpenWrt/LEDE.
>> It has WIFI, USB, UART, 20+ GPIOs but is only one inch square.
>> It will help you to make a smart house, study embedded system
>> or even make the tiniest router in the world.
>>
>> Details about this SoM can be found at "https://vocore.io/v2.html;.
>>
>> Signed-off-by: Mauro Condarelli 
>> ---
>>
>> Changes in v5:
>> - Removed unneeded (and wrong) UART2 initialization in board.c
>> - Added network setup.
>> - Removed project-specific code.
>> - Move back environment to SPI NOR.
>> - Changes to environment default settings.
>> - Rebase on current u-boot-mips/testing
>>
>> Changes in v4:
>> - Reverted some overzealous DTS cleaning.
>> - Added support for bootcount
>>
>> Changes in v3:
>> - based on top of Weijie Gao patchset:
>> "[v3,xx/20]Refactor the architecture parts of mt7628"
>>
>> Changes in v2:
>> - Removed some dead code
>> - Changed Author to my full name (no nick)
>> - Removed unwanted fixup to .dts generation (not my call).
>> - Fixed commit message
>> - Fixed various variables/filenames to include Vendor name
>> - Changed Vendor name (Vonger -> Vocore)
>>
>>  arch/mips/dts/Makefile   |   1 +
>>  arch/mips/dts/mt7628a.dtsi   |   5 ++
>>  arch/mips/dts/vocore_vocore2.dts |  78 
>>  arch/mips/mach-mtmips/Kconfig|   8 +++
>>  board/vocore/vocore2/Kconfig |  12 
>>  board/vocore/vocore2/Makefile|   3 +
>>  board/vocore/vocore2/board.c |   6 ++
>>  configs/vocore2_defconfig| 103 ++
>>  configs/vocore2_defconfig_ENV_IN_FAT | 104 +++
>>  include/configs/vocore2.h|  61 
>>  10 files changed, 381 insertions(+)
>>  create mode 100644 arch/mips/dts/vocore_vocore2.dts
>>  create mode 100644 board/vocore/vocore2/Kconfig
>>  create mode 100644 board/vocore/vocore2/Makefile
>>  create mode 100644 board/vocore/vocore2/board.c
>>  create mode 100644 configs/vocore2_defconfig
>>  create mode 100644 configs/vocore2_defconfig_ENV_IN_FAT
>>  create mode 100644 include/configs/vocore2.h
>>
>> diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
>> index cbd0c8bc8b..f711e9fb59 100644
>> --- a/arch/mips/dts/Makefile
>> +++ b/arch/mips/dts/Makefile
>> @@ -23,6 +23,7 @@ dtb-$(CONFIG_BOARD_NETGEAR_DGND3700V2) += 
>> netgear,dgnd3700v2.dtb
>>  dtb-$(CONFIG_BOARD_SAGEM_FAST1704) += sagem,f...@st1704.dtb
>>  dtb-$(CONFIG_BOARD_SFR_NB4_SER) += sfr,nb4-ser.dtb
>>  dtb-$(CONFIG_BOARD_TPLINK_WDR4300) += tplink_wdr4300.dtb
>> +dtb-$(CONFIG_BOARD_VOCORE2) += vocore_vocore2.dtb
>>  dtb-$(CONFIG_TARGET_JZ4780_CI20) += ci20.dtb
>>  dtb-$(CONFIG_SOC_LUTON) += luton_pcb090.dtb luton_pcb091.dtb
>>  dtb-$(CONFIG_SOC_OCELOT) += ocelot_pcb120.dtb ocelot_pcb123.dtb
>> diff --git a/arch/mips/dts/mt7628a.dtsi b/arch/mips/dts/mt7628a.dtsi
>> index 6baa63add3..192599c37f 100644
>> --- a/arch/mips/dts/mt7628a.dtsi
>> +++ b/arch/mips/dts/mt7628a.dtsi
>> @@ -402,6 +402,11 @@
>>  builtin-cd = <1>;
>>  r_smpl = <1>;
>>  
>> +bus-width = <4>;
>> +max-frequency = <4800>;
>> +cap-sd-highspeed;
>> +cap-mmc-highspeed;
>> +
> could you please move these lines to vocore_vocore2.dts? these are board
> specific properties.
Done.

>>  clocks = <>, < CLK_SDXC>;
>>  clock-names = "source", "hclk";
>>  
>> diff --git a/arch/mips/dts/vocore_vocore2.dts 
>> b/arch/mips/dts/vocore_vocore2.dts
>> new file mode 100644
>> index 00..1d611abb73
>> --- /dev/null
>> +++ b/arch/mips/dts/vocore_vocore2.dts
>> @@ -0,0 +1,78 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * Copyright (C) 2019 Mauro Condarelli 
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "mt7628a.dtsi"
>> +#include 
>> +
>> +/ {
>> +compatible = "vocore,vocore2", "ralink,mt7628a-soc";
>> +model = "VoCore2";
>> +
>> +aliases {
>> +serial0 = 
>> +spi0 = 
>> +};
>> +
>> 

Re: [PATCH v5] Add support for SoM "VoCore2".

[Mauro Condarelli]

Thanks Daniel,

On 2/12/20 5:58 PM, Daniel Schwierzeck wrote:
> On Wed, Feb 12, 2020 at 4:30 PM Mauro Condarelli  wrote:
>> Small patch series to add support for VoCore/VoCore2 board.
>>
>> VoCore is open hardware and runs OpenWrt/LEDE.
>> It has WIFI, USB, UART, 20+ GPIOs but is only one inch square.
>> It will help you to make a smart house, study embedded system
>> or even make the tiniest router in the world.
>>
>> Details about this SoM can be found at "https://vocore.io/v2.html;.
>>
>> Signed-off-by: Mauro Condarelli 
>> ---
>>
>> Changes in v5:
>> - Removed unneeded (and wrong) UART2 initialization in board.c
>> - Added network setup.
>> - Removed project-specific code.
>> - Move back environment to SPI NOR.
>> - Changes to environment default settings.
>> - Rebase on current u-boot-mips/testing
>>
>> Changes in v4:
>> - Reverted some overzealous DTS cleaning.
>> - Added support for bootcount
>>
>> Changes in v3:
>> - based on top of Weijie Gao patchset:
>> "[v3,xx/20]Refactor the architecture parts of mt7628"
>>
>> Changes in v2:
>> - Removed some dead code
>> - Changed Author to my full name (no nick)
>> - Removed unwanted fixup to .dts generation (not my call).
>> - Fixed commit message
>> - Fixed various variables/filenames to include Vendor name
>> - Changed Vendor name (Vonger -> Vocore)
>>
>>  arch/mips/dts/Makefile   |   1 +
>>  arch/mips/dts/mt7628a.dtsi   |   5 ++
>>  arch/mips/dts/vocore_vocore2.dts |  78 
>>  arch/mips/mach-mtmips/Kconfig|   8 +++
>>  board/vocore/vocore2/Kconfig |  12 
>>  board/vocore/vocore2/Makefile|   3 +
>>  board/vocore/vocore2/board.c |   6 ++
>>  configs/vocore2_defconfig| 103 ++
>>  configs/vocore2_defconfig_ENV_IN_FAT | 104 +++
>>  include/configs/vocore2.h|  61 
>>  10 files changed, 381 insertions(+)
>>  create mode 100644 arch/mips/dts/vocore_vocore2.dts
>>  create mode 100644 board/vocore/vocore2/Kconfig
>>  create mode 100644 board/vocore/vocore2/Makefile
>>  create mode 100644 board/vocore/vocore2/board.c
>>  create mode 100644 configs/vocore2_defconfig
>>  create mode 100644 configs/vocore2_defconfig_ENV_IN_FAT
>>  create mode 100644 include/configs/vocore2.h
>>
>> diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
>> index cbd0c8bc8b..f711e9fb59 100644
>> --- a/arch/mips/dts/Makefile
>> +++ b/arch/mips/dts/Makefile
>> @@ -23,6 +23,7 @@ dtb-$(CONFIG_BOARD_NETGEAR_DGND3700V2) += 
>> netgear,dgnd3700v2.dtb
>>  dtb-$(CONFIG_BOARD_SAGEM_FAST1704) += sagem,f...@st1704.dtb
>>  dtb-$(CONFIG_BOARD_SFR_NB4_SER) += sfr,nb4-ser.dtb
>>  dtb-$(CONFIG_BOARD_TPLINK_WDR4300) += tplink_wdr4300.dtb
>> +dtb-$(CONFIG_BOARD_VOCORE2) += vocore_vocore2.dtb
>>  dtb-$(CONFIG_TARGET_JZ4780_CI20) += ci20.dtb
>>  dtb-$(CONFIG_SOC_LUTON) += luton_pcb090.dtb luton_pcb091.dtb
>>  dtb-$(CONFIG_SOC_OCELOT) += ocelot_pcb120.dtb ocelot_pcb123.dtb
>> diff --git a/arch/mips/dts/mt7628a.dtsi b/arch/mips/dts/mt7628a.dtsi
>> index 6baa63add3..192599c37f 100644
>> --- a/arch/mips/dts/mt7628a.dtsi
>> +++ b/arch/mips/dts/mt7628a.dtsi
>> @@ -402,6 +402,11 @@
>> builtin-cd = <1>;
>> r_smpl = <1>;
>>
>> +   bus-width = <4>;
>> +   max-frequency = <4800>;
>> +   cap-sd-highspeed;
>> +   cap-mmc-highspeed;
>> +
>> clocks = <>, < CLK_SDXC>;
>> clock-names = "source", "hclk";
>>
>> diff --git a/arch/mips/dts/vocore_vocore2.dts 
>> b/arch/mips/dts/vocore_vocore2.dts
>> new file mode 100644
>> index 00..1d611abb73
>> --- /dev/null
>> +++ b/arch/mips/dts/vocore_vocore2.dts
>> @@ -0,0 +1,78 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * Copyright (C) 2019 Mauro Condarelli 
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "mt7628a.dtsi"
>> +#include 
>> +
>> +/ {
>> +   compatible = "vocore,vocore2", "ralink,mt7628a-soc";
>> +   model = "VoCore2";
>> +
>> +   aliases {
>> +   serial0 = 
>> +   spi0 = 
>> +   };
>> +
>> +   memory@0 {
>> +   device_type =

[PATCH v5] Add support for SoM "VoCore2".

[Mauro Condarelli]

Small patch series to add support for VoCore/VoCore2 board.

VoCore is open hardware and runs OpenWrt/LEDE.
It has WIFI, USB, UART, 20+ GPIOs but is only one inch square.
It will help you to make a smart house, study embedded system
or even make the tiniest router in the world.

Details about this SoM can be found at "https://vocore.io/v2.html;.

Signed-off-by: Mauro Condarelli 
---

Changes in v5:
- Removed unneeded (and wrong) UART2 initialization in board.c
- Added network setup.
- Removed project-specific code.
- Move back environment to SPI NOR.
- Changes to environment default settings.
- Rebase on current u-boot-mips/testing

Changes in v4:
- Reverted some overzealous DTS cleaning.
- Added support for bootcount

Changes in v3:
- based on top of Weijie Gao patchset:
"[v3,xx/20]Refactor the architecture parts of mt7628"

Changes in v2:
- Removed some dead code
- Changed Author to my full name (no nick)
- Removed unwanted fixup to .dts generation (not my call).
- Fixed commit message
- Fixed various variables/filenames to include Vendor name
- Changed Vendor name (Vonger -> Vocore)

 arch/mips/dts/Makefile   |   1 +
 arch/mips/dts/mt7628a.dtsi   |   5 ++
 arch/mips/dts/vocore_vocore2.dts |  78 
 arch/mips/mach-mtmips/Kconfig|   8 +++
 board/vocore/vocore2/Kconfig |  12 
 board/vocore/vocore2/Makefile|   3 +
 board/vocore/vocore2/board.c |   6 ++
 configs/vocore2_defconfig| 103 ++
 configs/vocore2_defconfig_ENV_IN_FAT | 104 +++
 include/configs/vocore2.h|  61 
 10 files changed, 381 insertions(+)
 create mode 100644 arch/mips/dts/vocore_vocore2.dts
 create mode 100644 board/vocore/vocore2/Kconfig
 create mode 100644 board/vocore/vocore2/Makefile
 create mode 100644 board/vocore/vocore2/board.c
 create mode 100644 configs/vocore2_defconfig
 create mode 100644 configs/vocore2_defconfig_ENV_IN_FAT
 create mode 100644 include/configs/vocore2.h

diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
index cbd0c8bc8b..f711e9fb59 100644
--- a/arch/mips/dts/Makefile
+++ b/arch/mips/dts/Makefile
@@ -23,6 +23,7 @@ dtb-$(CONFIG_BOARD_NETGEAR_DGND3700V2) += 
netgear,dgnd3700v2.dtb
 dtb-$(CONFIG_BOARD_SAGEM_FAST1704) += sagem,f...@st1704.dtb
 dtb-$(CONFIG_BOARD_SFR_NB4_SER) += sfr,nb4-ser.dtb
 dtb-$(CONFIG_BOARD_TPLINK_WDR4300) += tplink_wdr4300.dtb
+dtb-$(CONFIG_BOARD_VOCORE2) += vocore_vocore2.dtb
 dtb-$(CONFIG_TARGET_JZ4780_CI20) += ci20.dtb
 dtb-$(CONFIG_SOC_LUTON) += luton_pcb090.dtb luton_pcb091.dtb
 dtb-$(CONFIG_SOC_OCELOT) += ocelot_pcb120.dtb ocelot_pcb123.dtb
diff --git a/arch/mips/dts/mt7628a.dtsi b/arch/mips/dts/mt7628a.dtsi
index 6baa63add3..192599c37f 100644
--- a/arch/mips/dts/mt7628a.dtsi
+++ b/arch/mips/dts/mt7628a.dtsi
@@ -402,6 +402,11 @@
builtin-cd = <1>;
r_smpl = <1>;
 
+   bus-width = <4>;
+   max-frequency = <4800>;
+   cap-sd-highspeed;
+   cap-mmc-highspeed;
+
clocks = <>, < CLK_SDXC>;
clock-names = "source", "hclk";
 
diff --git a/arch/mips/dts/vocore_vocore2.dts b/arch/mips/dts/vocore_vocore2.dts
new file mode 100644
index 00..1d611abb73
--- /dev/null
+++ b/arch/mips/dts/vocore_vocore2.dts
@@ -0,0 +1,78 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Mauro Condarelli 
+ */
+
+/dts-v1/;
+
+#include "mt7628a.dtsi"
+#include 
+
+/ {
+   compatible = "vocore,vocore2", "ralink,mt7628a-soc";
+   model = "VoCore2";
+
+   aliases {
+   serial0 = 
+   spi0 = 
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x0800>;
+   };
+   leds {
+   compatible = "gpio-leds";
+
+   power {
+   label = "vocore:power";
+   gpios = < 12 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   };
+   };
+
+   chosen {
+   bootargs = "console=ttyS2,115200";
+   stdout-path = 
+   };
+};
+
+ {
+   state_default: pin_state {
+   p0led {
+   groups = "p0led_a";
+   function = "led";
+   };
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+   nor0: spi-flash@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "jedec,spi-nor";
+   spi-max-frequency = <2500>;
+   reg = <0>;
+   };
+};
+
+ {
+   status = "okay";
+
+   pinctrl-names 

Re: [PATCH] mips: cmd: go: Flush cache before jumping to app/image

[Mauro Condarelli]

Tested on VoCore2 board.
RAM loading seems to work flawlessly.

Tested-by: Mauro Condarelli 

Regards
Mauro


On 2/12/20 3:26 PM, Stefan Roese wrote:
> It has been noticed on MT7628/88 platforms, that booting the RAM image
> does not work reliably. Sometimes it works and sometimes not. Debugging
> showed that this "might" be a cache related issue as very strange
> errors occurred (e.g. output corrupted etc).
>
> This patch adds a cache flush for the complete SDRAM area to the go cmd
> before jumping to the entry point for the MIPS architecture. The
> complete area is flushed as we don't know at this point, how big the
> area of the "application" really is.
>
> Signed-off-by: Stefan Roese 
> Cc: Daniel Schwierzeck 
> Cc: Mauro Condarelli 
> Cc: Weijie Gao 
> ---
>  arch/mips/lib/Makefile |  1 +
>  arch/mips/lib/boot.c   | 23 +++
>  2 files changed, 24 insertions(+)
>  create mode 100644 arch/mips/lib/boot.c
>
> diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile
> index 589bc651f9..24a72d9c97 100644
> --- a/arch/mips/lib/Makefile
> +++ b/arch/mips/lib/Makefile
> @@ -11,5 +11,6 @@ obj-y   += stack.o
>  obj-y+= traps.o
>  
>  obj-$(CONFIG_CMD_BOOTM) += bootm.o
> +obj-$(CONFIG_CMD_GO) += boot.o
>  
>  lib-$(CONFIG_USE_PRIVATE_LIBGCC) += ashldi3.o ashrdi3.o lshrdi3.o
> diff --git a/arch/mips/lib/boot.c b/arch/mips/lib/boot.c
> new file mode 100644
> index 00..6186f72090
> --- /dev/null
> +++ b/arch/mips/lib/boot.c
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2020 Stefan Roese 
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +unsigned long do_go_exec(ulong (*entry)(int, char * const []),
> +  int argc, char * const argv[])
> +{
> + /*
> +  * Flush cache before jumping to application. Let's flush the
> +  * whole SDRAM area, since we don't know the size of the image
> +  * that was loaded.
> +  */
> + flush_cache(gd->bd->bi_memstart, gd->bd->bi_memsize);
> +
> + return entry(argc, argv);
> +}

Re: [PATCH] cmd: go: Flush cache before jumping to app/image

[Mauro Condarelli]

Hi Stefan,

On 2/12/20 2:22 PM, Stefan wrote:
> Hi Mauro,
>
> On 12.02.20 14:09, Mauro Condarelli wrote:
>> Hi Daniel,
>> Hi Stefan,
>>
>> I'll test this ASAP, but, in the meantime, please have a look at the
>> strange (and perhaps related) code in arch/mips/mach-mtmips/cpu.c
>
> You are most likely referring to the code in last_stage_init() that
> also deals with a potential cache issue. Its still unresolved and
> this "hack" is still needed for a working U-Boot image (e.g. no timeouts
> in tftp).
Yes, I was referring to that strange "D-cache" cleanup.
Why not just a cache-flush()?

> Its only partly related to the current issue though as it also deals
> with "cache" but addresses a different issue. Please test and report
> back.
Done.
Confirmed.
With new version in SPI NOR I could load (and execute successfully)
all versions I had saved on my tftp server.
If some further testing is useful don't hesitate to ask.

> Thanks,
> Stefan
>
Many thanks
Mauro

Re: [PATCH] cmd: go: Flush cache before jumping to app/image

[Mauro Condarelli]

Hi Daniel,
Hi Stefan,

I'll test this ASAP, but, in the meantime, please have a look at the
strange (and perhaps related) code in arch/mips/mach-mtmips/cpu.c

Regards
Mauro

On 2/12/20 2:00 PM, Daniel Schwierzeck wrote:
> On Wed, Feb 12, 2020 at 1:21 PM Stefan Roese  wrote:
>> It has been noticed on MT7628/88 platforms, that booting the RAM image
>> does not work reliably. Sometimes it works and sometimes not. Debugging
>> showed that this "might" be a cache related issue as very strange
>> errors occured (output corrupted etc).
>>
>> This patch adds a cache flush for the complete SDRAM area to the go cmd
>> before jumping to the entry point. The complete area is flushed as we
>> don't know at this point, how big the area of the "application" really
>> is.
>>
>> Signed-off-by: Stefan Roese 
>> Cc: Daniel Schwierzeck 
>> Cc: Mauro Condarelli 
>> Cc: Weijie Gao 
>> ---
>>  cmd/boot.c | 10 ++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/cmd/boot.c b/cmd/boot.c
>> index 9150fce80b..968522face 100644
>> --- a/cmd/boot.c
>> +++ b/cmd/boot.c
>> @@ -9,10 +9,13 @@
>>   */
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>
>>  #ifdef CONFIG_CMD_GO
>>
>> +DECLARE_GLOBAL_DATA_PTR;
>> +
>>  /* Allow ports to override the default behavior */
>>  __attribute__((weak))
>>  unsigned long do_go_exec(ulong (*entry)(int, char * const []), int argc,
>> @@ -33,6 +36,13 @@ static int do_go(cmd_tbl_t *cmdtp, int flag, int argc, 
>> char * const argv[])
>>
>> printf ("## Starting application at 0x%08lX ...\n", addr);
>>
>> +   /*
>> +* Flush cache before jumping to application. Let's flush the
>> +* whole SDRAM area, since we don't know the size of the image
>> +* that was loaded.
>> +*/
>> +   flush_cache(gd->bd->bi_memstart, gd->bd->bi_memsize);
>> +
>> /*
>>  * pass address parameter as argv[0] (aka command name),
>>  * and all remaining args
>> --
>> 2.25.0
>>
> I think that's not right for all architectures or cache-coherent
> systems. It would be better
> to implement do_go_exec() in arch/mips/libs/bootm.c because this function is
> already annotated as weak.
>

Re: [PATCH v3 00/20] Refactor the architecture parts of mt7628

[Mauro Condarelli]

Hi Stefan,
Hi Daniel,

On 2/12/20 7:39 AM, Stefan wrote:
> Hi Mauro,
> Hi Daniel,
>
> On 11.02.20 19:05, Mauro Condarelli wrote:
>> ===8<---
>>
>> What *does NOT* work is loading RAM version or, to be more precise:
>> It works IF (and only if) you load the same code already running.
>> I *think* this is because current Weijie code unpacks to this same
>> location
>> (8020) before relocating. If you are rewriting the same code in the
>> same location any cache inconsistencies are unimportant, otherwise
>> Bad Things happen.
>> I spoke with Stephan about this, but we never found a fix.
>>
>> ===8<---
>
> I also noticed that "RAM loading" the U-Boot proper does not work all
> the time on my MT7688 targets. It seems to depend on the image size
> and some other factors (moon phase...). ;)
>
> So there is very likely a bug somewhere hidden - perhaps in the
> relocaton code. I will probably try to dig into this in sometime soon.
> But I need a reproducable "bad" image for this. Right now, RAM loading
> is working just fine.
As said: In my setup RAM loading is consistently failing if I try to load
an u-boot build consistently different from the one currently running.
OTOH loading the same (or very similar, a rebuild is considered "the
same") version is _always_ working for me.

To rephrase: I have two setups; one based on master+weijiev3 and
the other based on plain mtmips/testing.
I can flash either one and it works from SPI NOR. no problems here.
I can always RAM load successfully the same kernel as flashed.
If I RAM load the "other" setup it always fails.

I did a few tests:
- erasing download area (mw.b 8020 0 8).
- do some other loading (e.g.: the Linux kernel) between RAM load and
"go" (attempt to clean caches, but I suspect this would only effectively
clear D-cache, not I-cache).
The above behavior does not change.

>
> BTW: I noticed that RAM loading does work even when loading into a
> different address than TEXT_BASE. On the new MTMIPS targets TEXT_BASE is
> 0x8020 and loadind to e.g. 0x8100 does also work.
I do confirm this:
  setenv autoload no; dhcp; tftpboot 8100
192.168.7.101:u-boot.bin-mips.testing; go ${fileaddr}
works as expected (loading  same-as-flashed)

>
> Daniel, perhaps a dumb question, but is the MIPS U-Boot code position
> independant?
>
> Mauro, please try loading into a different address on your non-working
> setup and report back if RAM loading works in this case.
Attempt to load, even at different address, the "other" u-boot fails:
  setenv autoload no; dhcp; tftpboot 8100
192.168.7.101:u-boot.bin-weijie.v3.vocore2; go ${fileaddr}
hangs after "## Starting application at 0x8100 ..." (I currently have
in SPI NOR the u-boot-mtmips.bin-mips.testing built together
u-boot.bin-mips.testing).

>> ===8<---
>> I don't think so.
>> As said problem is with RAM loading.
>
> I also have this problem (sometimes). Please see above.
>
>> ===8<---
>> For the Ram-lading problem I do not currently plan any
>> action, but I'm available.
>
> A test with a different load address would be interesting.
Done (see above).
Tell me if You want me to rebuild with a different TEXT_BASE
and test that.

>
> Thanks,
> Stefan
Regards
Mauro

Re: [PATCH v3 00/20] Refactor the architecture parts of mt7628

[Mauro Condarelli]

Thanks Daniel.

On 2/11/20 5:49 PM, Daniel Schwierzeck wrote:
> On Tue, Feb 11, 2020 at 5:11 PM Mauro Condarelli  wrote:
>> ===8<
>> Hit any key to stop autoboot:  0
>> =>
> ok, booting from RAM works. But what I meant with bootable is, that
> you can write the
> the u-boot-mtmips.bin to SPI flash and do a cold boot. Only then we
> can merge your patch.
It *does* work.
The U-Boot I have flashed is essentially the same as the one built
in the "master" directory, just a few days old (I changed essentially
my project-specific CONFIG_EXTRA_ENV_SETTINGS).

... which reminds me of something...

... it turns out that flashing *does* work:

=> setenv autoload no; dhcp; tftpboot 8500
192.168.7.101:u-boot-mtmips.bin; sf probe; sf update ${fileaddr} 0
${filesize}
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
DHCP client bound to address 192.168.7.110 (2953 ms)
Using eth@1011 device
TFTP from server 192.168.7.101; our IP address is 192.168.7.110
Filename 'u-boot-mtmips.bin'.
Load address: 0x8500
Loading: #
     762.7 KiB/s
done
Bytes transferred = 244458 (3baea hex)
device 0 offset 0x0, size 0x3baea
240362 bytes written, 4096 bytes skipped in 2.232s, speed 111952 B/s
=> reset
resetting ...

U-Boot SPL 2020.04-rc1-01620-gcd23ee2179 (Feb 11 2020 - 18:33:48 +0100)
Trying to boot from NOR


U-Boot 2020.04-rc1-01620-gcd23ee2179 (Feb 11 2020 - 18:33:48 +0100)

CPU:   MediaTek MT7628A ver:1 eco:2
Boot:  DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL
Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
Model: VoCore2
DRAM:  128 MiB
WDT:   Started with servicing (60s timeout)
MMC:   mmc@1013: 0
Loading Environment from SPI Flash... SF: Detected w25q128 with page
size 256 Bytes, erase size 4 KiB, total 16 MiB
OK
Model: VoCore2
Net:  
Warning: eth@1011 (eth0) using random MAC address - 8a:fb:d0:3b:d1:93
eth0: eth@1011
Hit any key to stop autoboot:  0
=>

What *does NOT* work is loading RAM version or, to be more precise:
It works IF (and only if) you load the same code already running.
I *think* this is because current Weijie code unpacks to this same location
(8020) before relocating. If you are rewriting the same code in the
same location any cache inconsistencies are unimportant, otherwise
Bad Things happen.
I spoke with Stephan about this, but we never found a fix.

Now that I reflashed "u-boot-mips/testing" version I can run it also
"from RAM", while trying to load "master" hangs (I tried just now).

If this is considered "acceptable" (probably it has nothing to do with my
vocore2 port) I can clean-up my patches and resubmit.
I'm not a mips expert and I don't know how to debug this "RAM load"
misbehavior, but I'm available for testing, if useful.


>> ===8<---
>>>> I *do* have a bootable patchset built on top of master + Nemirovsky
>>>> "reconfigurable cpu clocks" + Weijie v3.
>>>> Result is fully working, including net and mmc/SD.
>>>>
>>>> This patchset applies cleanly to uboot-mips/testing and compile
>>>> apparently without errors, but resulting u-boot.bin does not work.
>>>> By "does not work" I mean it does not utter a single char on debug
>>>> serial.
>>>>
>>>> I tried to do a complete diff between my working tree and this
>>>> non-working one and there are tons of differences, but I couldn't
>>>> spot anything that might be relevant.
>>>>
>>>> I am unsure on how to proceed; please advise.
> maybe you have a big diff because you are not on the latest master
> branch. I currently
> have ae347120eed8204b1fdf018ddf79131964e57016. The u-boot-mips/testing is 
> based
> on u-boot-mips/next and only contains Weijie's v3 patches from 14/20
> to 20/20. For
> u-boot-mips/next I intend to create a pull request soon. The existing
> mtmips boards should
> still work without SPL support. Maybe Stefan could give it a quick test.
>
> Maybe I messed something up in u-boot-mips/testing. There were some
> merge conflicts.
I don't think so.
As said problem is with RAM loading.

> Could you build a new patch queue on top of u-boot-mips/next with the 
> remaining
> Weijie v3 patches and your VoCore2 patches?
I can do that if You think it's still useful, otherwise we can
just use testing.

> As long as all u-boot-mips changes aren't merged to mainline, your
> patches must work with
> the latest u-boot-mips/next branch. There could always be new and
> incompatible changes
Understood.

> in mainline or in other MIPS patches which you have to figure out then.
I don't think  there'll be problems.
My patches are quite basic and board-only.

I plan to clean my patch expunging all project-specific stuff,
rebase from the (current) tip of uboot-mips-mips/testing and
resubmit (unless You tell me to do something different,
of course).

For the Ram-lading problem I do not currently plan any
action, but I'm available.

Best Regards (and pardon me for the noise, please)
Mauro Condarelli

Re: [PATCH v3 00/20] Refactor the architecture parts of mt7628

[Mauro Condarelli]

 some difference, somewhere,
but it's not evident (to me) where it is and how to find it.

Thanks in Advance for any advice
Best Regards
Mauro

On 2/11/20 2:54 PM, Daniel Schwierzeck wrote:
> On Tue, Feb 11, 2020 at 11:58 AM Mauro Condarelli  wrote:
>> Thanks Daniel.
>>
>> On 2/10/20 10:28 PM, Daniel Schwierzeck wrote:
>>> Hi Mauro,
>>>
>>> Am 10.02.20 um 21:20 schrieb Mauro Condarelli:
>>>> FYI
>>>> I've been using this patchset for over a week without any adverse effect.
>>>> It allowed me to port to VoCore2 board.
>>>> Should I add a "Tested-by" flag?
>>>> If so: how should I do it?
>>>>
>>>> Regards
>>>> Mauro Codarelli
>>>>
>>> sorry that I could respond to your questions earlier. I've pushed the
>>> complete patch set from Weijie to:
>>>
>>> https://gitlab.denx.de/u-boot/custodians/u-boot-mips/commits/testing
>> I tried to use this repo/branch, but something is wrong (or I goofed badly).
>>> Maybe this helps you with development. If you have a bootable patch set
>>> (you can do MMC later) for your VoCore2 board, please submit a regular
>>> patch series based on that branch so that we can review again.
>> I *do* have a bootable patchset built on top of master + Nemirovsky
>> "reconfigurable cpu clocks" + Weijie v3.
>> Result is fully working, including net and mmc/SD.
>>
>> This patchset applies cleanly to uboot-mips/testing and compile
>> apparently without errors, but resulting u-boot.bin does not work.
>> By "does not work" I mean it does not utter a single char on debug
>> serial.
>>
>> I tried to do a complete diff between my working tree and this
>> non-working one and there are tons of differences, but I couldn't
>> spot anything that might be relevant.
>>
>> I am unsure on how to proceed; please advise.
> but do you reach the U-Boot prompt? If I apply your patch and build
> it, I need to be able to program the resulting U-Boot image to SPI
> flash and boot to U-Boot prompt. Also note that the final U-Boot image
> with SPL is now called u-boot-mtmips.bin. Don't try to use u-boot.bin.
>
> Regarding debug UART you also need to configure the serial driver with
> "make menuconfig" (register base, clocks, baud rate etc.). There is no
> driver model or device-tree involved at that point. I think Stefan
> already told you the correct settings and you need this
> board_early_init_f magic for the pinmux (don't forget to enable
> CONFIG_BOARD_EARLY_INIT_F). But for the production mode debug UART
> should be disabled anyway. SPL UART is different than debug UART.
> AFAIU the regular driver model and device-tree stuff should work
> there. For the pinmux you'll need the new CONFIG_SPL_UART2_SPIS_PINMUX
> option. According to the code, you'll also need to configure
> CONFIG_CONS_INDEX = 3.
>

Re: [PATCH v3 00/20] Refactor the architecture parts of mt7628

[Mauro Condarelli]

Thanks for the fast answer, Stefan.

On 2/11/20 12:16 PM, Stefan wrote:
> Hi Mauro,
> ===8<
>>> https://gitlab.denx.de/u-boot/custodians/u-boot-mips/commits/testing
>> I tried to use this repo/branch, but something is wrong (or I goofed
>> badly).
>
> Just a quick reply: I tested u-boot-mips/testing today and it works just
> fine on both LinkIt and the GARDENA board. So there is nothing wrong
> with this repository AFAICT.
Suspect is there's something wrong with handling of SPL_UART2_SPIS_PINMUX
(that's where our boards are different), but I couldn't spot any relevant
difference.

> You might need to rebase your patch on top of this branch, as some files
> might have changes in the meantime.
What is the recommended procedure, in this case?
I did a:
  git format-patch --full-index -o ../transport weijie.v3
on old branch ("weijie.v3" is the branch on which I added Weijie's patches,
of course), an then I tried simply (on u-boot-mips):
  git checkout -b vocore2 testing
  git am -3 ../transport/*

>
> Thanks,
> Stefan
> ===8<
Regards
Mauro

Re: [PATCH v3 00/20] Refactor the architecture parts of mt7628

[Mauro Condarelli]

Thanks Daniel.

On 2/10/20 10:28 PM, Daniel Schwierzeck wrote:
> Hi Mauro,
>
> Am 10.02.20 um 21:20 schrieb Mauro Condarelli:
>> FYI
>> I've been using this patchset for over a week without any adverse effect.
>> It allowed me to port to VoCore2 board.
>> Should I add a "Tested-by" flag?
>> If so: how should I do it?
>>
>> Regards
>> Mauro Codarelli
>>
> sorry that I could respond to your questions earlier. I've pushed the
> complete patch set from Weijie to:
>
> https://gitlab.denx.de/u-boot/custodians/u-boot-mips/commits/testing
I tried to use this repo/branch, but something is wrong (or I goofed badly).
> Maybe this helps you with development. If you have a bootable patch set
> (you can do MMC later) for your VoCore2 board, please submit a regular
> patch series based on that branch so that we can review again.
I *do* have a bootable patchset built on top of master + Nemirovsky
"reconfigurable cpu clocks" + Weijie v3.
Result is fully working, including net and mmc/SD.

This patchset applies cleanly to uboot-mips/testing and compile
apparently without errors, but resulting u-boot.bin does not work.
By "does not work" I mean it does not utter a single char on debug
serial.

I tried to do a complete diff between my working tree and this
non-working one and there are tons of differences, but I couldn't
spot anything that might be relevant.

I am unsure on how to proceed; please advise.
> ===8<
Many thanks
Mauro Condarelli


My complete patchset follows:
This includes some project-specific settings I need to remove
before actual submission, but I left them in because *this*
is working for me.
======
>From f1828bcacbd3fc3bc8aa9243b302ab2b7a509d88 Mon Sep 17 00:00:00 2001
From: Mauro Condarelli 
Date: Tue, 17 Dec 2019 10:54:21 +0100
Subject: [PATCH] Add support for SoM "VoCore2".

Small patch series to add support for VoCore/VoCore2 board.

VoCore is open hardware and runs OpenWrt/LEDE.
It has WIFI, USB, UART, 20+ GPIOs but is only one inch square.
It will help you to make a smart house, study embedded system
or even make the tiniest router in the world.

Details about this SoM can be found at "https://vocore.io/v2.html;.

Series-notes:
This port is working for me and able to boot Linux v5.0.
Standard subsystems are enabled (SPI NOR, MMC/SD and USB).
Network is not currently enabled as my Vocore2 board networking
relies essentially on WiFi (which works under Linux).
END

Series-to: uboot
Series-name: VoCore2
Series-cc: danielschwierzeck
Series-cc: stroese
Series-cc: Weijie Gao 
Series-version: 5

Series-changes: 2
- Removed some dead code
- Changed Author to my full name (no nick)
- Removed unwanted fixup to .dts generation (not my call).
- Fixed commit message
- Fixed various variables/filenames to include Vendor name
- Changed Vendor name (Vonger -> Vocore)

Series-changes: 3
- based on top of Weijie Gao patchset:
    "[v3,xx/20]Refactor the architecture parts of mt7628"

Series-changes: 4
- Reverted some overzealous DTS cleaning.
- Added support for bootcount

Series-changes: 5
- Added network setup.
- Move back environment to SPI NOR.
- Changes to environment default settings.

Signed-off-by: Mauro Condarelli 
---
 arch/mips/dts/Makefile   |   1 +
 arch/mips/dts/mt7628a.dtsi   |   5 ++
 arch/mips/dts/vocore_vocore2.dts |  78 
 arch/mips/mach-mtmips/Kconfig    |   8 ++
 board/vocore/vocore2/Kconfig |  12 +++
 board/vocore/vocore2/Makefile    |   3 +
 board/vocore/vocore2/board.c |  33 +
 configs/vocore2_defconfig    | 105 +++
 configs/vocore2_defconfig_ENV_IN_FAT | 104 ++
 include/configs/vocore2.h    |  76 +++
 10 files changed, 425 insertions(+)
 create mode 100644 arch/mips/dts/vocore_vocore2.dts
 create mode 100644 board/vocore/vocore2/Kconfig
 create mode 100644 board/vocore/vocore2/Makefile
 create mode 100644 board/vocore/vocore2/board.c
 create mode 100644 configs/vocore2_defconfig
 create mode 100644 configs/vocore2_defconfig_ENV_IN_FAT
 create mode 100644 include/configs/vocore2.h

diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
index cbd0c8bc8b..f711e9fb59 100644
--- a/arch/mips/dts/Makefile
+++ b/arch/mips/dts/Makefile
@@ -23,6 +23,7 @@ dtb-$(CONFIG_BOARD_NETGEAR_DGND3700V2) +=
netgear,dgnd3700v2.dtb
 dtb-$(CONFIG_BOARD_SAGEM_FAST1704) += sagem,f...@st1704.dtb
 dtb-$(CONFIG_BOARD_SFR_NB4_SER) += sfr,nb4-ser.dtb
 dtb-$(CONFIG_BOARD_TPLINK_WDR4300) += tplink_wdr4300.dtb
+dtb-$(CONFIG_BOARD_VOCORE2) += vocore_vocore2.dtb
 dtb-$(CONFIG_TARGET_JZ4780_CI20) += ci20.dtb
 dtb-$(CONFIG_SOC_LUTON) += luton_pcb090.dtb luton_pcb091.dtb
 dtb-$(CONFIG_SOC_OCELOT) += ocelot_pcb120.dtb ocelot_pcb123.dtb
diff --git a/arch/mips/dts/mt7628a.dt

Re: [PATCH v3 00/20] Refactor the architecture parts of mt7628

[Mauro Condarelli]

FYI
I've been using this patchset for over a week without any adverse effect.
It allowed me to port to VoCore2 board.
Should I add a "Tested-by" flag?
If so: how should I do it?

Regards
Mauro Codarelli

On 2/10/20 6:20 PM, Daniel Schwierzeck wrote:
> Hi Weije,
>
> Am 21.01.20 um 09:17 schrieb Weijie Gao:
>> This patch series are divided into two parts:
>>
>> The main part is to rewrite the whole architecture code of mt7628:
>> * Lock parts of the d-cache for initial stack so the rest of the code can
>>   be reimplemented in C.
>> * Memory controller & DDR initialization have been fully written to support
>>   detecting DDR size automatically.
>> * DDR calibration has also been reimplemented with a clear logic.
>> * Implemented a new sysreset driver to take advantage of the reset
>>   controller so we can drop the use of syscon-based sysreset to reduce size.
>>
>> The second part is to add SPL support for mt7628:
>> * With SPL enabled we can build the ROM-bootable and RAM-bootable binary
>>   simultaneously, and we can drop RAM boot related configs and defconfig
>>   files.
>> * Generate compressed u-boot.bin image for SPL to reduce size of final
>>   combined binary.
>> * Enable DM support for SPL for a more flexible device probing.
>> * Add a demo board (mt7628_rfb) aims at router application.
>>
>> Changes since v2:
>> * Dropped a patch which removes unused parts of mt7628a.dtsi
>> * Move lzma decompression support to common spl_nor.c
>> * Move u-boot,dm-pre-reloc to u-boot-mt7628.dtsi
>>
> could you resend patches from 14/20 to 20/20? Patch 16/20 should get a
> test as requested by Simon. From the remaining generic patches I'd like
> to have some more acks before applying. Thanks.
>

Re: Time frame for "Refactor the architecture parts of mt7628 "?

[Mauro Condarelli]

Timid reminder...
Is there any reason why these could *not* get into mainline?

These work for me, should I add a "tested-by" annotation?

Many Thanks
Mauro

On 1/30/20 3:28 PM, Mauro Condarelli wrote:
> Hi,
> I would like to have a tentative time frame for inclusion
> of Wiijie Gao "Refactor the architecture parts of mt7628"
> series into master.
> Reason why I ask is my own patches are based on it.
>
> Thanks in Advance
> Mauro
>

Time frame for "Refactor the architecture parts of mt7628 "?

[Mauro Condarelli]

Hi,
I would like to have a tentative time frame for inclusion
of Wiijie Gao "Refactor the architecture parts of mt7628"
series into master.
Reason why I ask is my own patches are based on it.

Thanks in Advance
Mauro

[RFC][PATCH v4] Add support for SoM "VoCore2"

[Mauro Condarelli]

n=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.00] rcu: Preemptible hierarchical RCU implementation.
[    0.00]     Tasks RCU enabled.
[    0.00] rcu: RCU calculated value of scheduler-enlistment delay
is 10 jiffies.
[    0.00] NR_IRQS: 256
[    0.00] intc: using register map from devicetree
[    0.00] random: get_random_bytes called from 0x804b4a4c with
crng_init=0
[    0.00] CPU Clock: 580MHz
[    0.00] timer_probe: no matching timers found
[    0.00] clocksource: MIPS: mask: 0x max_cycles:
0x, max_idle_ns: 6590553264 ns
[    0.12] sched_clock: 32 bits at 290MHz, resolution 3ns, wraps
every 7405115902ns
[    0.008046] Console: colour dummy device 80x25
[    0.012474] printk: console [tty0] enabled
[    0.016608] printk: bootconsole [early0] disabled

Here workaround is to have "setenv bootargs ${default_bootargs}
mtdparts=${mtdparts} root=/dev/mmcblk0p5 ${default_bootargs}"; I.e.:
insert ${default_bootargs} *twice* (simply moving it to end would result
in missing "mtdparts").

* given the above environment, shouldn't autoboot be attempted?

* I also tried enabling CONFIG_CMD_CACHE, but compilation fails with:
...
  LD  u-boot
mipsel-linux-ld.bfd: cmd/built-in.o: in function `do_icache':
cmd/cache.c:(.text.do_icache+0x5c): undefined reference to `icache_disable'
mipsel-linux-ld.bfd: cmd/cache.c:(.text.do_icache+0x6c): undefined
reference to `icache_enable'
mipsel-linux-ld.bfd: cmd/cache.c:(.text.do_icache+0x8c): undefined
reference to `icache_status'
make: *** [Makefile:1695: u-boot] Error 1

My only guess, ATM, is I goofed somehow applying Weijie patches: I'll
try rebuilding from a pristine "master".
Can someone confirm patchset "[v3,xx/20]Refactor the architecture parts
of mt7628" still applies cleanly?

Side issue: patman complain with:

mcon@cinderella:~/vocore/__V2__/u-boot$ ./tools/patman/patman -n -c1 -m
Cleaned 1 patches
0 errors, 1 warnings, 0 checks for 0001-Add-support-for-SoM-VoCore2.patch:
:0: warning: added, moved or deleted file(s), does MAINTAINERS
need updating?
checkpatch.pl found 0 error(s), 1 warning(s), 0 checks(s)

What should I do?

Any hint welcome.

Regards and TiA!
Mauro


=
Small patch series to add support for VoCore/VoCore2 board.

VoCore is open hardware and runs OpenWrt/LEDE.
It has WIFI, USB, UART, 20+ GPIOs but is only one inch square.
It will help you to make a smart house, study embedded system
or even make the tiniest router in the world.

Details about this SoM can be found at "https://vocore.io/v2.html;.

Signed-off-by: Mauro Condarelli 
---

Changes in v4:
- Reverted some overzealous DTS cleaning.
- Added support for bootcount

Changes in v3:
- based on top of Weijie Gao patchset:
    "[v3,xx/20]Refactor the architecture parts of mt7628"

Changes in v2:
- Removed some dead code
- Changed Author to my full name (no nick)
- Removed unwanted fixup to .dts generation (not my call).
- Fixed commit message
- Fixed various variables/filenames to include Vendor name
- Changed Vendor name (Vonger -> Vocore)

 arch/mips/dts/Makefile   |   1 +
 arch/mips/dts/mt7628a.dtsi   |   5 ++
 arch/mips/dts/vocore_vocore2.dts |  76 ++
 arch/mips/mach-mtmips/Kconfig    |   8 +++
 board/vocore/vocore2/Kconfig |  12 
 board/vocore/vocore2/Makefile    |   3 +
 board/vocore/vocore2/board.c |  33 ++
 configs/vocore2_defconfig    | 105 +++
 include/configs/vocore2.h    |  61 ++
 9 files changed, 304 insertions(+)
 create mode 100644 arch/mips/dts/vocore_vocore2.dts
 create mode 100644 board/vocore/vocore2/Kconfig
 create mode 100644 board/vocore/vocore2/Makefile
 create mode 100644 board/vocore/vocore2/board.c
 create mode 100644 configs/vocore2_defconfig
 create mode 100644 include/configs/vocore2.h

diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
index cbd0c8bc8b..f711e9fb59 100644
--- a/arch/mips/dts/Makefile
+++ b/arch/mips/dts/Makefile
@@ -23,6 +23,7 @@ dtb-$(CONFIG_BOARD_NETGEAR_DGND3700V2) +=
netgear,dgnd3700v2.dtb
 dtb-$(CONFIG_BOARD_SAGEM_FAST1704) += sagem,f...@st1704.dtb
 dtb-$(CONFIG_BOARD_SFR_NB4_SER) += sfr,nb4-ser.dtb
 dtb-$(CONFIG_BOARD_TPLINK_WDR4300) += tplink_wdr4300.dtb
+dtb-$(CONFIG_BOARD_VOCORE2) += vocore_vocore2.dtb
 dtb-$(CONFIG_TARGET_JZ4780_CI20) += ci20.dtb
 dtb-$(CONFIG_SOC_LUTON) += luton_pcb090.dtb luton_pcb091.dtb
 dtb-$(CONFIG_SOC_OCELOT) += ocelot_pcb120.dtb ocelot_pcb123.dtb
diff --git a/arch/mips/dts/mt7628a.dtsi b/arch/mips/dts/mt7628a.dtsi
index 6baa63add3..192599c37f 100644
--- a/arch/mips/dts/mt7628a.dtsi
+++ b/arch/mips/dts/mt7628a.dtsi
@@ -402,6 +402,11 @@
         builtin-cd = <1>;
         r_smpl = <1>;
 
+        bus-width = <4>;
+        max-frequency = <4800>;
+        cap-sd-highspeed;
+        cap-mmc-highspeed;
+
         clocks = <

Re: [PATCH v3] Add support for SoM "VoCore2".

[Mauro Condarelli]

I just trimmed too much.
This is also the cause of MMC/SD misbehavior (missing
interrupt).
I will send another patch *after* some serious testing.
Regards
Mauro

On 1/27/20 1:41 PM, Stefan Roese wrote:
> On 25.01.20 22:12, Mauro Condarelli wrote:
>> Small patch series to add support for VoCore/VoCore2 board.
>>
>> VoCore is open hardware and runs OpenWrt/LEDE.
>> It has WIFI, USB, UART, 20+ GPIOs but is only one inch square.
>> It will help you to make a smart house, study embedded system
>> or even make the tiniest router in the world.
>>
>> Details about this SoM can be found at "https://vocore.io/v2.html;.
>>
>> Signed-off-by: Mauro Condarelli 
>> ---
>>
>> Changes in v3:
>> - based on top of Weijie Gao patchset:
>>  "[v3,xx/20]Refactor the architecture parts of mt7628"
>>
>> Changes in v2:
>> - Removed some dead code
>> - Changed Author to my full name (no nick)
>> - Removed unwanted fixup to .dts generation (not my call).
>> - Fixed commit message
>> - Fixed various variables/filenames to include Vendor name
>> - Changed Vendor name (Vonger -> Vocore)
>>
>>   MAINTAINERS  |   1 +
>>   arch/mips/dts/Makefile   |   1 +
>>   arch/mips/dts/mt7628a.dtsi   |  56 -
>>   arch/mips/dts/vocore_vocore2.dts |  76 +++
>>   arch/mips/mach-mtmips/Kconfig    |   8 +++
>>   board/vocore/vocore2/Kconfig |  12 
>>   board/vocore/vocore2/Makefile    |   3 +
>>   board/vocore/vocore2/board.c |  33 ++
>>   configs/vocore2_defconfig    | 100 +++
>>   include/configs/vocore2.h    |  66 
>>   10 files changed, 311 insertions(+), 45 deletions(-)
>>   create mode 100644 arch/mips/dts/vocore_vocore2.dts
>>   create mode 100644 board/vocore/vocore2/Kconfig
>>   create mode 100644 board/vocore/vocore2/Makefile
>>   create mode 100644 board/vocore/vocore2/board.c
>>   create mode 100644 configs/vocore2_defconfig
>>   create mode 100644 include/configs/vocore2.h
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 7d2729dfb0..aef0f4a26d 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -1,3 +1,4 @@
>> +source /home/mcon/.basheditor/remote-debugging-v1.sh localhost 3
>> #BASHEDITOR-TMP-REMOTE-DEBUGGING-END|Origin line:
>>   Descriptions of section entries:
>>     P: Person (obsolete)
>> diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
>> index cbd0c8bc8b..f711e9fb59 100644
>> --- a/arch/mips/dts/Makefile
>> +++ b/arch/mips/dts/Makefile
>> @@ -23,6 +23,7 @@ dtb-$(CONFIG_BOARD_NETGEAR_DGND3700V2) +=
>> netgear,dgnd3700v2.dtb
>>   dtb-$(CONFIG_BOARD_SAGEM_FAST1704) += sagem,f...@st1704.dtb
>>   dtb-$(CONFIG_BOARD_SFR_NB4_SER) += sfr,nb4-ser.dtb
>>   dtb-$(CONFIG_BOARD_TPLINK_WDR4300) += tplink_wdr4300.dtb
>> +dtb-$(CONFIG_BOARD_VOCORE2) += vocore_vocore2.dtb
>>   dtb-$(CONFIG_TARGET_JZ4780_CI20) += ci20.dtb
>>   dtb-$(CONFIG_SOC_LUTON) += luton_pcb090.dtb luton_pcb091.dtb
>>   dtb-$(CONFIG_SOC_OCELOT) += ocelot_pcb120.dtb ocelot_pcb123.dtb
>> diff --git a/arch/mips/dts/mt7628a.dtsi b/arch/mips/dts/mt7628a.dtsi
>> index 6baa63add3..3d4f29e0c5 100644
>> --- a/arch/mips/dts/mt7628a.dtsi
>> +++ b/arch/mips/dts/mt7628a.dtsi
>> @@ -7,6 +7,11 @@
>>   #size-cells = <1>;
>>   compatible = "ralink,mt7628a-soc";
>>   +    resetc: reset-controller {
>> +    compatible = "ralink,rt2880-reset";
>> +    #reset-cells = <1>;
>> +    };
>> +
>>   cpus {
>>   #address-cells = <1>;
>>   #size-cells = <0>;
>> @@ -61,6 +66,12 @@
>>   u-boot,dm-pre-reloc;
>>   };
>>   +    clkgate: clkgate@0x30 {
>> +    reg = <0x30 0x4>;
>> +    compatible = "mediatek,mediatek,mt7628-clk";
>> +    #clock-cells = <1>;
>> +    };
>> +
>
> If these changes are really necessary, then please submit them as a
> separate patch with a description, why they are needed.
>
>>   rstctrl: rstctrl@0x34 {
>>   reg = <0x34 0x4>;
>>   compatible = "mediatek,mtmips-reset";
>> @@ -228,32 +239,6 @@
>>     resets = < MT7628_TIMER_RST>;
>>   reset-names = "wdt";
>> -
>> -    interrupt-parent = <>;
>> -    interrupts = <24>;
>> -    };
&

Re: [PATCH v3] Add support for SoM "VoCore2".

[Mauro Condarelli]

Update:

On 1/27/20 1:09 PM, Stefan Roese wrote:
> On 27.01.20 12:37, Mauro Condarelli wrote:
>> Unfortunately this still doesn't work as it should.
>>
>> I've been doing more tests and I found out MMC/SD *does*
>> work, but with a ridiculously low throughput (~20KB/s)
>> which is enough to trigger WDT loading uImage.
>>
>> Adding explicit "max-frequency = <4800>;" to
>> .dts *seems* to cure speed problem, but makes
>> transfer unreliable: relatively small files (<200k)
>> usually work fine, but larger files invariably exit
>> with error:
>>
>> Error reading cluster
>> ** Unable to read file uboot-ram.bin **
>>
>> after which mmc subsystem is unusable (till next reset).
>>
>> @Stefan: do MMC/SD work right on LinkIt/Gardena ?
>>     apparently neither define mmc section in .dts
>
> I have zero experience with MMC/SD on these platforms as this IF is
> not used on the GARDENA board at all. So sorry, I can't help.
>
> Thanks,
> Stefan
MANY Thanks just the same, Stefan!

===8<
Apparently it's really a speed problem: changing setting to:
  max-frequency = <2400>;
*seems* to work right (pending more tests).

I fear I'll have to wait Weijie input on this.
I'll keep this as is now, till further notice.

ANY input very welcome.

Regards
Mauro

Re: [PATCH v3] Add support for SoM "VoCore2".

[Mauro Condarelli]

,6,7      0x0900
CMD_SEND:12
        ARG             0x
        MMC_RSP_R1b         0x0b00
   179840   uboot-ram_20170210.bin
   179840   uboot-ram.bin
   183272   uboot-rom_20170213.bin
   183272   uboot-rom_20170423.bin
  1819846   uImage.initram
  1473392   initram.cpio.xz
  1819846   uImage

7 file(s), 0 dir(s)

=> load mmc 0:1 8500 uboot-ram.bin
CMD_SEND:16
        ARG             0x0200
        MMC_RSP_R1,5,6,7      0x0900
CMD_SEND:17
        ARG             0x
        MMC_RSP_R1,5,6,7      0x0900
CMD_SEND:16
        ARG             0x0200
        MMC_RSP_R1,5,6,7      0x0900
CMD_SEND:17
        ARG             0x0800
        MMC_RSP_R1,5,6,7      0x0900
CMD_SEND:16
        ARG             0x0200
        MMC_RSP_R1,5,6,7      0x0900
CMD_SEND:18
        ARG             0x0a04
        MMC_RSP_R1,5,6,7      0x0900
CMD_SEND:12
        ARG             0x
        MMC_RSP_R1b         0x0b00
CMD_SEND:16
        ARG             0x0200
        MMC_RSP_R1,5,6,7      0x0900
CMD_SEND:18
        ARG             0x0804
        MMC_RSP_R1,5,6,7      0x0900
CMD_SEND:12
        ARG             0x
        MMC_RSP_R1b         0x0b00
CMD_SEND:16
        ARG             0x0200
        MMC_RSP_R1,5,6,7      0x0900
CMD_SEND:18
        ARG             0x0b88
        RET             -5
Error reading cluster
** Unable to read file uboot-ram.bin **
=>

=
Any hint welcome (I'm out of my depth, here).

Thanks in Advance
Mauro


On 1/25/20 10:12 PM, Mauro Condarelli wrote:
> Small patch series to add support for VoCore/VoCore2 board.
>
> VoCore is open hardware and runs OpenWrt/LEDE.
> It has WIFI, USB, UART, 20+ GPIOs but is only one inch square.
> It will help you to make a smart house, study embedded system
> or even make the tiniest router in the world.
>
> Details about this SoM can be found at "https://vocore.io/v2.html;.
>
> Signed-off-by: Mauro Condarelli 
> ---
>
> Changes in v3:
> - based on top of Weijie Gao patchset:
> "[v3,xx/20]Refactor the architecture parts of mt7628"
>
> Changes in v2:
> - Removed some dead code
> - Changed Author to my full name (no nick)
> - Removed unwanted fixup to .dts generation (not my call).
> - Fixed commit message
> - Fixed various variables/filenames to include Vendor name
> - Changed Vendor name (Vonger -> Vocore)
>
>  MAINTAINERS  |   1 +
>  arch/mips/dts/Makefile   |   1 +
>  arch/mips/dts/mt7628a.dtsi   |  56 -
>  arch/mips/dts/vocore_vocore2.dts |  76 +++
>  arch/mips/mach-mtmips/Kconfig|   8 +++
>  board/vocore/vocore2/Kconfig |  12 
>  board/vocore/vocore2/Makefile|   3 +
>  board/vocore/vocore2/board.c |  33 ++
>  configs/vocore2_defconfig| 100 +++
>  include/configs/vocore2.h|  66 
>  10 files changed, 311 insertions(+), 45 deletions(-)
>  create mode 100644 arch/mips/dts/vocore_vocore2.dts
>  create mode 100644 board/vocore/vocore2/Kconfig
>  create mode 100644 board/vocore/vocore2/Makefile
>  create mode 100644 board/vocore/vocore2/board.c
>  create mode 100644 configs/vocore2_defconfig
>  create mode 100644 include/configs/vocore2.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7d2729dfb0..aef0f4a26d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1,3 +1,4 @@
> +source /home/mcon/.basheditor/remote-debugging-v1.sh localhost 3 
> #BASHEDITOR-TMP-REMOTE-DEBUGGING-END|Origin line:
>  Descriptions of section entries:
>  
>   P: Person (obsolete)
> diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
> index cbd0c8bc8b..f711e9fb59 100644
> --- a/arch/mips/dts/Makefile
> +++ b/arch/mips/dts/Makefile
> @@ -23,6 +23,7 @@ dtb-$(CONFIG_BOARD_NETGEAR_DGND3700V2) += 
> netgear,dgnd3700v2.dtb
>  dtb-$(CONFIG_BOARD_SAGEM_FAST1704) += sagem,f...@st1704.dtb
>  dtb-$(CONFIG_BOARD_SFR_NB4_SER) += sfr,nb4-ser.dtb
>  dtb-$(CONFIG_BOARD_TPLINK_WDR4300) += tplink_wdr4300.dtb
> +dtb-$(CONFIG_BOARD_VOCORE2) += vocore_vocore2.dtb
>  dtb-$(CONFIG_TARGET_JZ4780_CI20) += ci20.dtb
>  dtb-$(CONFIG_SOC_LUTON) += luton_pcb090.dtb luton_pcb091.dtb
>  dtb-$(CONFIG_SOC_OCELOT) += ocelot_pcb120.dtb ocelot_pcb123.dtb
> diff --git a/arch/mips/dts/mt7628a.dtsi b/arch/mips/dts/mt7628a.dtsi
> index 6baa63add3..3d4f29e0c5 100644
> --- a/arch/mips/dts/mt7628a.dtsi
> +++ b/arch/mips/dts/mt7628a.dtsi
> @@ -7,6 +7,11 @@
>   #size-cells = <1>;
>   compatible = "ralink,mt7628a-soc";
>  
> + resetc: reset-controller {
> + compatible = "ralink,rt2880-reset";
> + #reset-cells = <

[PATCH v3] Add support for SoM "VoCore2".

[Mauro Condarelli]

Small patch series to add support for VoCore/VoCore2 board.

VoCore is open hardware and runs OpenWrt/LEDE.
It has WIFI, USB, UART, 20+ GPIOs but is only one inch square.
It will help you to make a smart house, study embedded system
or even make the tiniest router in the world.

Details about this SoM can be found at "https://vocore.io/v2.html;.

Signed-off-by: Mauro Condarelli 
---

Changes in v3:
- based on top of Weijie Gao patchset:
"[v3,xx/20]Refactor the architecture parts of mt7628"

Changes in v2:
- Removed some dead code
- Changed Author to my full name (no nick)
- Removed unwanted fixup to .dts generation (not my call).
- Fixed commit message
- Fixed various variables/filenames to include Vendor name
- Changed Vendor name (Vonger -> Vocore)

 MAINTAINERS  |   1 +
 arch/mips/dts/Makefile   |   1 +
 arch/mips/dts/mt7628a.dtsi   |  56 -
 arch/mips/dts/vocore_vocore2.dts |  76 +++
 arch/mips/mach-mtmips/Kconfig|   8 +++
 board/vocore/vocore2/Kconfig |  12 
 board/vocore/vocore2/Makefile|   3 +
 board/vocore/vocore2/board.c |  33 ++
 configs/vocore2_defconfig| 100 +++
 include/configs/vocore2.h|  66 
 10 files changed, 311 insertions(+), 45 deletions(-)
 create mode 100644 arch/mips/dts/vocore_vocore2.dts
 create mode 100644 board/vocore/vocore2/Kconfig
 create mode 100644 board/vocore/vocore2/Makefile
 create mode 100644 board/vocore/vocore2/board.c
 create mode 100644 configs/vocore2_defconfig
 create mode 100644 include/configs/vocore2.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 7d2729dfb0..aef0f4a26d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1,3 +1,4 @@
+source /home/mcon/.basheditor/remote-debugging-v1.sh localhost 3 
#BASHEDITOR-TMP-REMOTE-DEBUGGING-END|Origin line:
 Descriptions of section entries:
 
P: Person (obsolete)
diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
index cbd0c8bc8b..f711e9fb59 100644
--- a/arch/mips/dts/Makefile
+++ b/arch/mips/dts/Makefile
@@ -23,6 +23,7 @@ dtb-$(CONFIG_BOARD_NETGEAR_DGND3700V2) += 
netgear,dgnd3700v2.dtb
 dtb-$(CONFIG_BOARD_SAGEM_FAST1704) += sagem,f...@st1704.dtb
 dtb-$(CONFIG_BOARD_SFR_NB4_SER) += sfr,nb4-ser.dtb
 dtb-$(CONFIG_BOARD_TPLINK_WDR4300) += tplink_wdr4300.dtb
+dtb-$(CONFIG_BOARD_VOCORE2) += vocore_vocore2.dtb
 dtb-$(CONFIG_TARGET_JZ4780_CI20) += ci20.dtb
 dtb-$(CONFIG_SOC_LUTON) += luton_pcb090.dtb luton_pcb091.dtb
 dtb-$(CONFIG_SOC_OCELOT) += ocelot_pcb120.dtb ocelot_pcb123.dtb
diff --git a/arch/mips/dts/mt7628a.dtsi b/arch/mips/dts/mt7628a.dtsi
index 6baa63add3..3d4f29e0c5 100644
--- a/arch/mips/dts/mt7628a.dtsi
+++ b/arch/mips/dts/mt7628a.dtsi
@@ -7,6 +7,11 @@
#size-cells = <1>;
compatible = "ralink,mt7628a-soc";
 
+   resetc: reset-controller {
+   compatible = "ralink,rt2880-reset";
+   #reset-cells = <1>;
+   };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -61,6 +66,12 @@
u-boot,dm-pre-reloc;
};
 
+   clkgate: clkgate@0x30 {
+   reg = <0x30 0x4>;
+   compatible = "mediatek,mediatek,mt7628-clk";
+   #clock-cells = <1>;
+   };
+
rstctrl: rstctrl@0x34 {
reg = <0x34 0x4>;
compatible = "mediatek,mtmips-reset";
@@ -228,32 +239,6 @@
 
resets = < MT7628_TIMER_RST>;
reset-names = "wdt";
-
-   interrupt-parent = <>;
-   interrupts = <24>;
-   };
-
-   intc: interrupt-controller@200 {
-   compatible = "ralink,rt2880-intc";
-   reg = <0x200 0x100>;
-
-   interrupt-controller;
-   #interrupt-cells = <1>;
-
-   resets = < MT7628_INT_RST>;
-   reset-names = "intc";
-
-   interrupt-parent = <>;
-   interrupts = <2>;
-
-   ralink,intc-registers = <0x9c 0xa0
-0x6c 0xa4
-0x80 0x78>;
-   };
-
-   memory-controller@300 {
-   compatible = "ralink,mt7620a-memc";
-   reg = <0x300 0x100>;
};
 
gpio@600 {
@@ -266,9 +251,6 @@
resets = < MT7628_PIO_RST>;
reset-names = "pio";
 
-   interrupt-parent = <>;
-   

Re: mmc init fails after soft reset on T1042

[Mauro Condarelli]

This might be a lng shot in the dark, but...

Many MMC/SD cards need to be fully reset, when left in
an "undefined" state.
This normally means power supply voltage (at SD card)
must drop below 1.3V for a sizable (>100ms) time.

Do you have means to physically remove power to eMMC?
Many eMMC chips don't have a usable Reset pin.

HiH
Mauro

On 1/25/20 4:42 PM, Amarnath MB wrote:
> Hi all,
>
> I working on a T1042RDB based custom board which has a 8GB eMMC (4bit mode)
> on board. I was able to successfully boot 2019.07 uboot on my board from
> NOR flash.
>
> After booting, mmcinfo command detects the on board eMMC and displays it's
> properties. But when I issue mmcinfo command after soft reset through reset
> command, it gives me mmc_init timeout error.
>
> After adding DEBUG and CONFIG_MMC_TRACE macros to my board header file, i
> came to know that the eMMC fails to respond to CMD 2.
>
> What can be the issue here? Can anyone guide me?
>
> Regards,
> Amarnath MB
>

Re: [RFC] Vocore2 MMC needs clock patches

[Mauro Condarelli]

Hi,
I'm clearly out of my depth:

=> icache flush
No arch specific invalidate_icache_all available!
=> dcache flush
No arch specific flush_dcache_all available!
=> icache off 
=> dcache off 

Ooops:
$ 0   :   87e806c8 
$ 4   : ffd0 0014 87e80518 87fce61c
$ 8   : 87e7bc00 0010  fffc
$12   :  000f 0006 0007
$16   : ffd0   002f
$20   : 87e81350 87fe8528  0001
$24   : 0016 87f84130 
$28   : 87f882a0 87e7bba8 87e81362 87fa9524
Hi    : 0006
Lo    : 000640a2
epc   : 87fa1600 (text 80221600)
ra    : 87fa9524 (text 80229524)
Status: 0006
Cause : d0008028 (ExcCode 0a)
PrId  : 00019655
### ERROR ### Please RESET the board ###

Thanks
Mauro

On 1/22/20 9:16 PM, Mauro Condarelli wrote:
> Hi Stefan,
>
> On 1/21/20 1:08 PM, Stefan Roese wrote:
>> Hi Mauro,
>>
>> On 21.01.20 12:27, Mauro Condarelli wrote:
>>> Thanks Weijie,
>>> I made the changes You suggested.
>>> I have also seen You sent a new version of Your patches.
>>> Since mine are based on yours I *think* I should suspend
>>> sending my VoCore2 patches till Yours are fixed and integrated
>>> into master.
>>>
>>> @Stefan Roese: is this the right course of action?
>> I think in the current state of Weijie's patches (v3), you can resume
>> sending your VoCore2 support based on this latest patchset to the
>> list. Please don't attach a patch but send it inline next time
>> (git send-email) to enable review.
> I will send next iteration as soon as I fix the reflash problem (see below).
>  
> ===8<
>>> Side Question: Stefan wrote:
>>>> Most of this can be done by using the
>>>> RAM version now (again). There is no additional RAM booting target now
>>>> any more. You can use the normal U-Boot image for this now. Please note
>>>> the changes TEXT_BASE here. Its now 0x8020.
>>> This actually seems to work right if I start from my original u-boot
>>> (1.1.3,
>>> flashed at start of SPI NOR), but it fails if I start from a flashed
>>> (at the
>>> same location) u-boot-mtmips.bin
>>> I *think* this happens because unpacking actually writes u-boot at
>>> 0x8020 and runs it from there, so "load usb 0:1 8020 u-boot.bin"
>>> (or equivalent) will overwrite the running u-boot and the following
>>> "go ${fileaddr}" fails:
>>>     ## Starting application at 0x8020 ...
>>>     
>> No, U-Boot relocates itself to the end of RAM and runs from there. So
>> this should work. Perhaps a cache flush is missing.
>>
>> I'll give it a try on my LinkIt board as well later.
> Did You manage to test this?
> I am currently testing loading from "paleolithic" u-boot, but I want to fix
> this before I finalize VoCore2 patches.
>
> I tried to do some manual testing enabling CONFIG_CMD_CACHE, but this
> bombs with Weijie patches with:
>
>   LD  u-boot
> mipsel-linux-ld.bfd: cmd/built-in.o: in function `do_icache':
> cmd/cache.c:(.text.do_icache+0x5c): undefined reference to `icache_disable'
> mipsel-linux-ld.bfd: cmd/cache.c:(.text.do_icache+0x6c): undefined
> reference to `icache_enable'
> mipsel-linux-ld.bfd: cmd/cache.c:(.text.do_icache+0x8c): undefined
> reference to `icache_status'
> make: *** [Makefile:1697: u-boot] Error 1
>
> icache seems enabled unconditionally in
> arch/mips/mach-mtmips/mt7628/lowlevel_init.S::73+
>
> I will try to add dummy functions just-to-play.
>
> Please advise
>
>> Thanks,
>> Stefan
> Regards and Many Thanks
> Mauro
>

Re: [RFC] Vocore2 MMC needs clock patches

[Mauro Condarelli]

Hi Stefan,

On 1/21/20 1:08 PM, Stefan Roese wrote:
> Hi Mauro,
>
> On 21.01.20 12:27, Mauro Condarelli wrote:
>> Thanks Weijie,
>> I made the changes You suggested.
>> I have also seen You sent a new version of Your patches.
>> Since mine are based on yours I *think* I should suspend
>> sending my VoCore2 patches till Yours are fixed and integrated
>> into master.
>>
>> @Stefan Roese: is this the right course of action?
>
> I think in the current state of Weijie's patches (v3), you can resume
> sending your VoCore2 support based on this latest patchset to the
> list. Please don't attach a patch but send it inline next time
> (git send-email) to enable review.
I will send next iteration as soon as I fix the reflash problem (see below).
 
===8<
>> Side Question: Stefan wrote:
>>> Most of this can be done by using the
>>> RAM version now (again). There is no additional RAM booting target now
>>> any more. You can use the normal U-Boot image for this now. Please note
>>> the changes TEXT_BASE here. Its now 0x8020.
>> This actually seems to work right if I start from my original u-boot
>> (1.1.3,
>> flashed at start of SPI NOR), but it fails if I start from a flashed
>> (at the
>> same location) u-boot-mtmips.bin
>> I *think* this happens because unpacking actually writes u-boot at
>> 0x8020 and runs it from there, so "load usb 0:1 8020 u-boot.bin"
>> (or equivalent) will overwrite the running u-boot and the following
>> "go ${fileaddr}" fails:
>>     ## Starting application at 0x8020 ...
>>     
>
> No, U-Boot relocates itself to the end of RAM and runs from there. So
> this should work. Perhaps a cache flush is missing.
>
> I'll give it a try on my LinkIt board as well later.
Did You manage to test this?
I am currently testing loading from "paleolithic" u-boot, but I want to fix
this before I finalize VoCore2 patches.

I tried to do some manual testing enabling CONFIG_CMD_CACHE, but this
bombs with Weijie patches with:

  LD  u-boot
mipsel-linux-ld.bfd: cmd/built-in.o: in function `do_icache':
cmd/cache.c:(.text.do_icache+0x5c): undefined reference to `icache_disable'
mipsel-linux-ld.bfd: cmd/cache.c:(.text.do_icache+0x6c): undefined
reference to `icache_enable'
mipsel-linux-ld.bfd: cmd/cache.c:(.text.do_icache+0x8c): undefined
reference to `icache_status'
make: *** [Makefile:1697: u-boot] Error 1

icache seems enabled unconditionally in
arch/mips/mach-mtmips/mt7628/lowlevel_init.S::73+

I will try to add dummy functions just-to-play.

Please advise

> Thanks,
> Stefan
Regards and Many Thanks
Mauro

Re: [RFC] Vocore2 MMC needs clock patches

[Mauro Condarelli]

Thanks Weijie,
I made the changes You suggested.
I have also seen You sent a new version of Your patches.
Since mine are based on yours I *think* I should suspend
sending my VoCore2 patches till Yours are fixed and integrated
into master.

@Stefan Roese: is this the right course of action?

I am happy what I have (pending further test, of course!),
but I want this integrated in upstream master, if possible,
so I'm prepared to rebase my patches after Weijie ones
are in.

Any comment welcome.

Side Question: Stefan wrote:
> Most of this can be done by using the
> RAM version now (again). There is no additional RAM booting target now
> any more. You can use the normal U-Boot image for this now. Please note
> the changes TEXT_BASE here. Its now 0x8020.
This actually seems to work right if I start from my original u-boot
(1.1.3,
flashed at start of SPI NOR), but it fails if I start from a flashed (at the
same location) u-boot-mtmips.bin
I *think* this happens because unpacking actually writes u-boot at
0x8020 and runs it from there, so "load usb 0:1 8020 u-boot.bin"
(or equivalent) will overwrite the running u-boot and the following
"go ${fileaddr}" fails:
   ## Starting application at 0x8020 ...
   
Note that if I load the same version flashed it works ok (presumably because
I'm  overwriting with the same content, so no harm done).
How can I load in RAM end test a new version once I flash new-style u-boot?
I am thinking about relinking at a different address, but I'm unsure.

TiA!

Regards
Mauro Condarelli

On 1/21/20 4:11 AM, Weijie Gao wrote:
> On Tue, 2020-01-21 at 00:55 +0100, Mauro Condarelli wrote:
>> Hi Weijie,
>> I attach my, apparently working, port to VoCore2 SoM.
>>
>> These patchsets are on top of Your 21 patch rewrite of MT7628 board,
>>
>> While the first patchset is relatively straightforward, but does not include
>> MMC handling, to enable it I had to backport from Linux Kernel several
>> pieces, essentially clock and interrupt handling.
> You are using a superseded patch series (v1) I submitted several months
> ago. These patches have already been replaced by v3 and merged into the
> mainline.
>
> * "mtmips-clk-gate" from v1 is replaced by "mediatek,mt7628-clk" and the
>   function of "mediatek,mt7628-clk" is a superset of "mtmips-clk-gate".
> * The node "intc" has no use at all. U-Boot for mips use no interrupts.
> * mmc property "hclk" is the gating clock of the SD controller module.
>   Using <> in the v1 patches was a bad idea. I changed it to
>   < CLK_SDXC> in v3 to make sure its clock will be always
>   enabled.
> * Please move pinctrl properties to your board's dts file.
> * pinctrl name "state_uhs" is not used by mtk-sd in U-Boot. MT7628 does
>   not support UHS. You should remove it.
> * vmmc-supply and vqmmc-supply are not used by mtk-sd in U-Boot because
>   UHS support is not added to the driver. Besides you have assigned
>   wrong values to them. You should remove it.
>
>> Those drivers appear written by You.
>> I am unsure if this is really needed or if there is some other (perhaps
>> cleaner)
>> way to enable MMC.
>>
>> As said this seems to work for me, but I would like to contribute this
>> board upstream, in the best possible way.
>>
>> Please let me know how I should proceed.
> I don't have a board with the "sd_iot_mode" pinmux for SDXC, so I can't
> tell you why you can't use it with my v3 patches. But I have tested v3
> patches on boards using "sd_router_mode" pinmux and they do work well.
>
>> Best Regards and Thanks in Advance
>>
>>

>From 4f09ebe1843b5ccdf9b0edb79be6a5110425df04 Mon Sep 17 00:00:00 2001
From: Mauro Condarelli 
Date: Tue, 21 Jan 2020 00:37:43 +0100
Subject: [PATCH] mips: mtmips: vocore2: add support for MMC/SD

Signed-off-by: Mauro Condarelli 
---
 arch/mips/dts/mt7628a.dtsi   | 18 ++
 arch/mips/dts/vocore_vocore2.dts |  4 
 configs/vocore2_defconfig| 10 +-
 drivers/phy/Kconfig  |  2 ++
 include/configs/vocore2.h| 22 +++---
 5 files changed, 44 insertions(+), 12 deletions(-)

diff --git a/arch/mips/dts/mt7628a.dtsi b/arch/mips/dts/mt7628a.dtsi
index f265cb6ad9..5e396e15f4 100644
--- a/arch/mips/dts/mt7628a.dtsi
+++ b/arch/mips/dts/mt7628a.dtsi
@@ -7,6 +7,18 @@
 	#size-cells = <1>;
 	compatible = "ralink,mt7628a-soc";
 
+	resetc: reset-controller {
+		compatible = "ralink,rt2880-reset";
+		#reset-cells = <1>;
+	};
+
+	cpuintc: interrupt-controller {
+		#address-cells = <0>;
+		#interrupt-cells = <1>;
+		interrupt-controller;
+		compatible = "mti,cpu-interrupt-controller";
+	};
+
 	clk48m

[RFC] Vocore2 MMC needs clock patches

[Mauro Condarelli]

Hi Weijie,
I attach my, apparently working, port to VoCore2 SoM.

These patchsets are on top of Your 21 patch rewrite of MT7628 board,

While the first patchset is relatively straightforward, but does not include
MMC handling, to enable it I had to backport from Linux Kernel several
pieces, essentially clock and interrupt handling.

Those drivers appear written by You.
I am unsure if this is really needed or if there is some other (perhaps
cleaner)
way to enable MMC.

As said this seems to work for me, but I would like to contribute this
board upstream, in the best possible way.

Please let me know how I should proceed.

Best Regards and Thanks in Advance


>From bee4d1255357c2e1f7546cdde3641380e95348e8 Mon Sep 17 00:00:00 2001
From: Mauro Condarelli 
Date: Mon, 20 Jan 2020 21:40:13 +0100
Subject: [PATCH 1/2] mtmips: Add support for VoCore2 board

Signed-off-by: Mauro Condarelli 
---
 arch/mips/dts/Makefile   |  1 +
 arch/mips/dts/vocore_vocore2.dts | 64 +
 arch/mips/mach-mtmips/Kconfig|  9 
 board/vocore/vocore2/Kconfig | 11 +
 board/vocore/vocore2/Makefile|  2 +
 board/vocore/vocore2/board.c | 35 
 configs/vocore2_defconfig| 69 +++
 include/configs/vocore2.h| 70 
 8 files changed, 261 insertions(+)
 create mode 100644 arch/mips/dts/vocore_vocore2.dts
 create mode 100644 board/vocore/vocore2/Kconfig
 create mode 100644 board/vocore/vocore2/Makefile
 create mode 100644 board/vocore/vocore2/board.c
 create mode 100644 configs/vocore2_defconfig
 create mode 100644 include/configs/vocore2.h

diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
index cbd0c8bc8b..f711e9fb59 100644
--- a/arch/mips/dts/Makefile
+++ b/arch/mips/dts/Makefile
@@ -23,6 +23,7 @@ dtb-$(CONFIG_BOARD_NETGEAR_DGND3700V2) += netgear,dgnd3700v2.dtb
 dtb-$(CONFIG_BOARD_SAGEM_FAST1704) += sagem,f...@st1704.dtb
 dtb-$(CONFIG_BOARD_SFR_NB4_SER) += sfr,nb4-ser.dtb
 dtb-$(CONFIG_BOARD_TPLINK_WDR4300) += tplink_wdr4300.dtb
+dtb-$(CONFIG_BOARD_VOCORE2) += vocore_vocore2.dtb
 dtb-$(CONFIG_TARGET_JZ4780_CI20) += ci20.dtb
 dtb-$(CONFIG_SOC_LUTON) += luton_pcb090.dtb luton_pcb091.dtb
 dtb-$(CONFIG_SOC_OCELOT) += ocelot_pcb120.dtb ocelot_pcb123.dtb
diff --git a/arch/mips/dts/vocore_vocore2.dts b/arch/mips/dts/vocore_vocore2.dts
new file mode 100644
index 00..ec9df70f55
--- /dev/null
+++ b/arch/mips/dts/vocore_vocore2.dts
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Mauro Condarelli 
+ */
+
+/dts-v1/;
+
+#include "mt7628a.dtsi"
+
+/ {
+	compatible = "vocore,vocore2", "ralink,mt7628a-soc";
+	model = "VoCore2";
+
+	aliases {
+		serial0 = 
+		spi0 = 
+	};
+
+	memory@0 {
+		device_type = "memory";
+		reg = <0x0 0x0800>;
+	};
+
+	chosen {
+		bootargs = "console=ttyS2,115200";
+		stdout-path = 
+	};
+};
+
+ {
+	state_default: pin_state {
+		p0led {
+			groups = "p0led_a";
+			function = "led";
+		};
+	};
+};
+
+ {
+	status = "okay";
+};
+
+ {
+	status = "okay";
+	num-cs = <2>;
+
+	nor0: spi-flash@0 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "jedec,spi-nor";
+		spi-max-frequency = <2500>;
+		reg = <0>;
+	};
+};
+
+ {
+	pinctrl-names = "default";
+	pinctrl-0 = <_iot_mode>;
+	mediatek,poll-link-phy = <0>;
+};
+
+ {
+	status = "okay";
+};
diff --git a/arch/mips/mach-mtmips/Kconfig b/arch/mips/mach-mtmips/Kconfig
index 1cd1d16022..3546b8f4f1 100644
--- a/arch/mips/mach-mtmips/Kconfig
+++ b/arch/mips/mach-mtmips/Kconfig
@@ -84,6 +84,14 @@ config BOARD_MT7628_RFB
 	  SPI-NOR flash, 1 built-in switch with 5 ports, 1 UART, 1 USB host,
 	  1 SDXC, 1 PCIe socket and JTAG pins.
 
+config BOARD_VOCORE2
+	bool "VoCore2"
+	depends on SOC_MT7628
+	select SUPPORTS_BOOT_RAM
+	help
+	  VoCore VoCore2 board has a MT7628 SoC with 128 MiB of RAM
+	  and 16 MiB of flash (SPI).
+
 endchoice
 
 config SPL_UART2_SPIS_PINMUX
@@ -97,5 +105,6 @@ config SPL_UART2_SPIS_PINMUX
 source "board/gardena/smart-gateway-mt7688/Kconfig"
 source "board/mediatek/mt7628/Kconfig"
 source "board/seeed/linkit-smart-7688/Kconfig"
+source "board/vocore/vocore2/Kconfig"
 
 endmenu
diff --git a/board/vocore/vocore2/Kconfig b/board/vocore/vocore2/Kconfig
new file mode 100644
index 00..9178c3ab32
--- /dev/null
+++ b/board/vocore/vocore2/Kconfig
@@ -0,0 +1,11 @@
+if BOARD_VOCORE2
+config SYS_BOARD
+	default "vocore2"
+
+config SYS_VENDOR
+	default "vocore"
+
+config SYS_CONFIG_NAME
+	default "vocore2"
+
+endif
diff --git a/board/vocore/vocore2/Makefile b/board/vocore/vocore2/Makefile
new file mode 100644
index 00..4b162318c2
--- /dev/null
+++ b/board/vocore/vocore2/Makefile
@@ -0,0 +1,2 @@
+
+obj-y := board.

Re: [PATCH v2 13/21] dts: mtmips: add alternative pinmux node for uart2

[Mauro Condarelli]

SUCCESS!!!

> => usb start; load usb 0:1 8500 u-boot-mtmips.bin
> starting USB...
> Bus ehci@101c: pinctrl_select_state_full('ehci@101c', 'default'):
> USB EHCI 1.00
> scanning bus ehci@101c for devices... 3 USB Device(s) found
>    scanning usb for storage devices... 1 Storage Device(s) found
> 213156 bytes read in 11 ms (18.5 MiB/s)
> => sf probe; sf update ${fileaddr} 0 ${filesize}
> pinctrl_select_state_full('spi@b00', 'default'):
> SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total
> 16 MiB
> device 0 offset 0x0, size 0x340a4
> 213156 bytes written, 0 bytes skipped in 5.465s, speed 39918 B/s
> => sf read 8600 0 ${filesize}; cmp 8600 ${fileaddr} ${filesize}
> device 0 offset 0x0, size 0x340a4
> SF: 213156 bytes @ 0x0 Read: OK
> word at 0x860340a4 (0x2e220918) != word at 0x850340a4 (0x1ab4834a)
> Total of 53289 word(s) were the same
> => reset
> resetting ...
> pinctrl_select_state_full('syscon-reboot', 'default'):
> pinctrl_select_state_full('system-controller@0', 'default'):
>
> U-Boot SPL 2020.01-00643-g1262a953f1 (Jan 20 2020 - 09:33:36 +0100)
> Trying to boot from NOR
>
>
> U-Boot 2020.01-00643-g1262a953f1 (Jan 20 2020 - 09:33:36 +0100)
>
> CPU:   MediaTek MT7628A ver:1 eco:2
> Boot:  DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL
> Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
> Model: LinkIt-Smart-7688
> DRAM:  128 MiB
> Loading Environment from SPI Flash... SF: Detected w25q128 with page
> size 256 Bytes, erase size 4 KiB, total 16 MiB
> *** Warning - bad CRC, using default environment
>
> Net:   
> Warning: eth@1011 (eth0) using random MAC address - 72:2c:95:10:90:e9
> eth0: eth@1011
> =>
>
*** THANKS!! ***

now I need to be able to duplicate this and, if needed, to modify.
I tried using last Weijie patch-set, but I got the same error You reported,
I "fixed" it removing `obj-y += time.o` from `arch/mips/cpu/Makefile`, but
I was afraid to test results ;)

What is the right sequence to get Your results?

Note: I will need to have also working MMC/SD; in stock U-Boot I had to
backport some drivers for that; is it supposed to work out-of-the-box
(given right config, of course) in this version?

Many, MANY thanks to You both.

Regards
Mauro


On 1/20/20 9:38 AM, Stefan Roese wrote:
> Hi Weijie,
> Hi Mauro,
>
> On 19.01.20 03:26, Weijie Gao wrote:
>> On Fri, 2020-01-17 at 15:50 +0100, Stefan Roese wrote:
>>> Added Mauro to Cc
>>>
>>> On 17.01.20 08:46, Weijie Gao wrote:
 This patch adds a new pinmux for UART2, which shares the pins with
 SPIS.

 Signed-off-by: Weijie Gao 
 ---
 Changes since v1: newly added
 ---
    arch/mips/dts/mt7628a.dtsi | 5 +
    1 file changed, 5 insertions(+)

 diff --git a/arch/mips/dts/mt7628a.dtsi b/arch/mips/dts/mt7628a.dtsi
 index 744594c45a..f265cb6ad9 100644
 --- a/arch/mips/dts/mt7628a.dtsi
 +++ b/arch/mips/dts/mt7628a.dtsi
 @@ -93,6 +93,11 @@
    function = "uart2";
    };
    +    uart2_pwm_pins: uart2_pwm_pins {
 +    groups = "spis";
 +    function = "pwm_uart2";
 +    };
 +
>>>
>>> Thanks. AFAIK, this will not be used by any of the currently supported
>>> boards. Is this correct?
>>
>> Yes.
>>
>>>
>>> Mauro is currently trying to port mainline U-Boot to the VoCore2 board
>>> which also uses UART2. I did not look to close, but might this pin mux
>>> option here be necessary for this VoCore2 board?
>>
>> Yes. I added this because of your discussions about the pinmux.
>> I've tested this pinmux and it worked well. I believe it's necessary for
>> the VoCore2.
>
> Thanks Weijie for your assistance here.
>
> I can confirm that your latest patchset works like a charm on the LinkIt
> 7688 board.
>
> Mauro, please find attached a new binary to flash at offset 0x0 in SPI
> NOR based on Weijie's latest patchset with this alternate UART pin mux
> setting enabled. I've also attached the defconfig for this. Please give
> it a try and let us know, if this works now for you.
>
> Thanks,
> Stefan

Re: Debugging VoCore2 ROM Startup

[Mauro Condarelli]

On 1/15/20 5:20 PM, Stefan Roese wrote:
> On 15.01.20 16:55, Mauro Condarelli wrote:
>
> 
===8<--
> in particular:
>>
>> b010: 00065144
>> System Configuration Register 0 ->   0110 0101 0001 0100
>> 0100
>>     TEST_CODE : None
>> 000 Reserved
>> 0 0110 0101 BS_SHADOW : ???
>> 000 Rseserved
>> 1   DBG_JTAG_MODE    1: Normal Boot-up
>> 0   TEST_MODE_1   : ???
>> 1   XTAL_FREQ_SEL    1: 40MHz SMD (3225)
>> 0   EXT_BG   0: BG clock from PMU
>> 0   TEST_MODE_0  0: SUTIF
>> 010 CHIP_MODE  010: Boot from XTAL (boot from SPI 3-Byte
>> ADR)
>> 0   DRAM_TYPE    0: DDR2
>>
>> which looks good to me; as said the only difference is
>> the 3-Byte SPI Addr vs. 4-Byte SPI Addr; is it relevant?
>> AFAIK my soldered SPI NOR:
>>
>> SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total
>>
>> has 3-Byte SPI Address. From data sheet:
>> The Read Data Bytes (READ) command is followed by a 3-byte address
>> (A23-A0), ...
>> What is on LinkIt?
>
> Its strapped to 4-byte. And on the GARDENA board as well.
>
>> Does that change anything in u-boot?
>
> I would not expect this to change anything, if its configured to 3-byte
> other that that you can't access anything above 16 MiB.
My SPI NOR is 16 MiB, so I cannot access anything beyond that ;)

> If you are really out of ideas and its possible for you, then please
> change
> the strapping to 4-byte "chapter 3.4 Bootstrapping Pins Description".
That wouldn't be easy as it's a SMD resistor soldered directly on the
Module.
Let's keep that as "last resort".
 
===8<--
>>
>>>> Note: I assumed u-boot-mtmips.bin is linked at 9c00, right?
>>>
>>> You don't need to know where it is linked to if you program it into
>>> SPI NOR. But yes, the first stage the SPL is linked to 0x9c00.
>> Can You elaborate, please?
>
> Each image generated to boot from SPI NOR needs to be linked to 9c00.
> This is what the ROM image (non-RAM) of mainline does and the SPL image
> of the dual image version (SPL plus main U-Boot proper) does.
>
>> I know for sure that if I flash at 3 a u-boot that has been compiled
>> with SYS_TEXT_BASE = 0x9c00 it will not start with "go 9c03"
>> I need to rebuild with SYS_TEXT_BASE = 0x9c03.
>
> But you flash at offset 0 in SPI NOR, right? That's where the SoC starts
> reading the bootloader binary after a reset or on power-up.
I was trying to say that, in my "secondary u-boot" attempts, where I
start from "paleolithic" and then do a "go " I need to put the
secondary at the same address specified in SYS_TEXT_BASE.
I mean:
if I want to boot directly from new then
    SYS_TEXT_BASE = 0x9c00
    flash at start of SPI NOR
    go 9c00
else if I want to start "secondary" then
    SYS_TEXT_BASE = 0x9c03
    flash at offset 3 in SPI NOR
    go 9c03
Any other combination does not work (i.e.: I cannot flash and run at
start an u-boot compiled with SYS_TEXT_BASE = 0x9c03 and
vice versa).

Note: I had to edit directly .config to change SYS_TEXT_BASE, apparently
it is visible in menuconfig only for ARM; am I missing something?
>  
===8<--

I do have a led I can use for crude signalling, but I'm not really familiar
with mips Assembly.
Can You share the code to turn it on? (it is connected to
GPIO44/WLED(pin144).
>
> Thanks,
> Stefan
>
TiA!
Mauro

Re: Debugging VoCore2 ROM Startup

[Mauro Condarelli]

On 1/15/20 4:04 PM, Stefan Roese wrote:
> Hi Mauro,
>
> On 15.01.20 13:50, Mauro Condarelli wrote:
>> Hi Stefan,
>>
>> On 1/15/20 11:48 AM, Stefan Roese wrote:
>>> Hi Mauro,
>>>
>>> On 15.01.20 11:23, Mauro Condarelli wrote:
>>>>>> I am surprised though as all I could find on differences between
>>>>>> MT7628 and MT7688 are is a reference on Mediatek site:
>>>>>> https://docs.labs.mediatek.com/resource/linkit-smart-7688/en/faq
>>>>>>
>>>>>> Q: What’s MT7628 and how is it different from MT7688AN?
>>>>>>
>>>>>> The MT7628 series are pin-to-pin compatible with the MT7688 series.
>>>>>> However, MT7628 comes with a 2T2R antenna, while MT7688 only
>>>>>> supports
>>>>>> 1T1R antenna.
>>>>>>
>>>>>> (Incomplete!) comparison of the two datasheets did not show
>>>>>> relevant differences.
>>>> I have started an analysis of current register status (and I
>>>> quickly hit
>>>> limitation of the documentation I have):
>>>>
>>>>   b008: 0001    
>>>> E-Fuse Configuration is not pristine, but I don't know what it my
>>>> mean.
>>>>
>>>>   b010: 0044    D...
>>>> System Configuration Register 0 ->  0001 0001 0001 0001 1000
>>>> 1000
>>>
>>> Not correct:
>>>
>>> System Configuration Register 0 ->  0001 0001 0001 0001 0100
>>> 0100
>> Right.
>> Shame on me.
>>
>>>>  TEST_CODE
>>>> 000          *
>>>> 100010001    BS_SHADOW
>>>> 000          *
>>>> 1            DBG_JTAG_MODE    1: Normal Boot-up
>>>> 1            TEST_MODE_1         ??
>>>> 0            XTAL_FREQ_SEL    0: 25MHz DIP ???
>>>> 0            EXT_BG           0: BG clock from PMU
>>>> 0            TEST_MODE_0      0: SUTIF
>>>> 100          CHIP_MODE      100: SCAN mode
>>>
>>> Not correct. You have here 010, so XTAL with 3-byte ADR
>>
>>>
>>>> 0            DRAM_TYPE        0: DDR2
>>>>
>>>> I am concerned by TEST_MODE_1,XTAL_FREQ_SEL and CHIP_MODE that might
>>>> signal a different up/down pulling of Bootstrapping Pins.
>>>> Could You cross check on LinkIt, please?
>>>
>>> => md b000
>>> b000: 3637544d 20203832 0010 00010102    MT7628  
>>> b010: 00156156 02605500      Va...U`.
>>> b020: 1024  0071 0020100c    ..$.q. .
>>> b030: ffc0 0400 c0030004 00fe00ff    
>>> b040:  0001      
>>> b050:    0810    
>>> b060: 50050404 05550551      ...PQ.U.
>> This is my register dump, for reference:
>> VoCore2 > md b000
>> b000: 3637544d 20203832 0001 00010102    MT7628  
>> b010: 00144144 02605500      DA...U`.
>> b020: 1024  0071 0020100c    ..$.q. .
>> b030: f9bfffc0 0640 c0030200 00fe01ff    ..@.
>> b040:  0001      
>> b050:    0810    
>> b060: 5505040c 05540555      ...UU.T.
>
> Okay, thanks. We can compare this now in depth.
On this machine (theoretically identical to the previous one; now
useless till
I reflash it) register dump is a bit different:

VoCore2 > md b000
b000: 3637544d 20203832 0001 00010102    MT7628  
b010: 00065144 02605500      DQ...U`.
b020: 1024  0071 0020100c    ..$.q. .
b030: f9bfffc0 0640 c0030200 00fe01ff    ..@.
b040:  0001      
b050:    0810    
b060: 5505040c 05540555      ...UU.T.

in particular:

b010: 00065144
System Configuration Register 0 ->   0110 0101 0001 0100 0100
    TEST_CODE : None
000 Reserved
0 0110 0101 BS_SHADOW : ???
000 Rseserved
1   DBG_JTAG_MODE1: Normal Boot-up
0   TEST_MODE_1   : ???
1   XTAL_FREQ_SEL1: 40MHz SMD (3225)
0   EXT_BG   0: BG clock from 

Re: Debugging VoCore2 ROM Startup

[Mauro Condarelli]

Hi Stefan,

On 1/15/20 11:48 AM, Stefan Roese wrote:
> Hi Mauro,
>
> On 15.01.20 11:23, Mauro Condarelli wrote:
>>>> I am surprised though as all I could find on differences between
>>>> MT7628 and MT7688 are is a reference on Mediatek site:
>>>> https://docs.labs.mediatek.com/resource/linkit-smart-7688/en/faq
>>>>
>>>> Q: What’s MT7628 and how is it different from MT7688AN?
>>>>
>>>> The MT7628 series are pin-to-pin compatible with the MT7688 series.
>>>> However, MT7628 comes with a 2T2R antenna, while MT7688 only supports
>>>> 1T1R antenna.
>>>>
>>>> (Incomplete!) comparison of the two datasheets did not show
>>>> relevant differences.
>> I have started an analysis of current register status (and I quickly hit
>> limitation of the documentation I have):
>>
>>  b008: 0001    
>> E-Fuse Configuration is not pristine, but I don't know what it my mean.
>>
>>  b010: 0044    D...
>> System Configuration Register 0 ->  0001 0001 0001 0001 1000
>> 1000
>
> Not correct:
>
> System Configuration Register 0 ->  0001 0001 0001 0001 0100 0100
Right.
Shame on me.

>>  TEST_CODE
>> 000          *
>> 100010001    BS_SHADOW
>> 000          *
>> 1            DBG_JTAG_MODE    1: Normal Boot-up
>> 1            TEST_MODE_1         ??
>> 0            XTAL_FREQ_SEL    0: 25MHz DIP ???
>> 0            EXT_BG           0: BG clock from PMU
>> 0            TEST_MODE_0      0: SUTIF
>> 100          CHIP_MODE      100: SCAN mode
>
> Not correct. You have here 010, so XTAL with 3-byte ADR

>
>> 0            DRAM_TYPE        0: DDR2
>>
>> I am concerned by TEST_MODE_1,XTAL_FREQ_SEL and CHIP_MODE that might
>> signal a different up/down pulling of Bootstrapping Pins.
>> Could You cross check on LinkIt, please?
>
> => md b000
> b000: 3637544d 20203832 0010 00010102    MT7628  
> b010: 00156156 02605500      Va...U`.
> b020: 1024  0071 0020100c    ..$.q. .
> b030: ffc0 0400 c0030004 00fe00ff    
> b040:  0001      
> b050:    0810    
> b060: 50050404 05550551      ...PQ.U.
This is my register dump, for reference:
VoCore2 > md b000
b000: 3637544d 20203832 0001 00010102    MT7628  
b010: 00144144 02605500      DA...U`.
b020: 1024  0071 0020100c    ..$.q. .
b030: f9bfffc0 0640 c0030200 00fe01ff    ..@.
b040:  0001      
b050:    0810    
b060: 5505040c 05540555      ...UU.T.

>
> SYSCFG0: 00156156
>
> CHIP_MODE: 011: XTAL with 4-byte ADR.
>
> Mainline U-Boot reports this:
>
> CPU:   MT7628 Rev 1.2 - Boot from XTAL (4-Byte SPI Addr)
My mainline (RAM) reports:
    CPU:   MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr)
>
> and the new code from Weijie reports this:
>
> CPU:   MediaTek MT7688A ver:1 eco:2
> Boot:  DDR2, SPI-NOR 4-Byte Addr, CPU clock from XTAL
> Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
>
> One important difference which might explain a lot, it XTAL_FREQ_SEL
> which is 0 in your case and 1 in my case.
>
> IIUTC, then the new code from Weijie takes this XTAL selection
> into account. Weijie might comment on this. I suggest that you give
> this "u-boot-mtmips.bin" binary a try. Good luck. :)
No good ;(

Here's transcript:

VoCore2 > usb reset; fatload usb 0 8001 u-boot-ram.bin; go 8001
(Re)start USB...
USB0:  Mediatek/Ralink USB EHCI
Register  NbrPorts 1
USB EHCI 1.00
scanning bus 0 for devices... 3 USB Device(s) found
   scanning bus for storage devices... 1 Storage Device(s) found
reading u-boot-ram.bin
...

387097 bytes read
## Starting application at 0x8001 ...
 board_debug_uart_init():
board_early_init_f():


U-Boot 2020.01-00370-g97a60844bd-dirty (Jan 13 2020 - 01:03:59 +0100)

CPU:   MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr)
Model: VoCore2
DRAM:  128 MiB
WDT:   Started with servicing (60s timeout)
board_early_init_r():
arch_early_init_r():
MMC:   pinctrl_select_state_full('mmc@1013', 'default'):
mmc@1013: 0
Loading Environment from FAT... *** Warning - bad CRC, using default
environment

In:    uart2@e00
Out:   uart2@e00
Err:   uart2@e00
Model: VoCore2
arch_misc_init():
=> usb start;

Re: Debugging VoCore2 ROM Startup

[Mauro Condarelli]

Hi Stefan,

On 1/15/20 10:31 AM, Stefan Roese wrote:
> Hi Mauro,
>
> On 15.01.20 10:04, Mauro Condarelli wrote:
>>> On 15.01.20 00:55, Mauro Condarelli wrote:
>>>> I found *one* of the bugs in startup:
>>>> To enable UART2 pinmux setting:
>>>>   void __iomem *gpio_mode;
>>>>   gpio_mode = ioremap_nocache(MT76XX_GPIO1_MODE, 0x100);
>>>>   clrbits_le32(gpio_mode, GENMASK(27, 26));
>>>> is not enough; you need also:
>>>>   setbits_le32(gpio_mode, GENMASK(3, 2));
>>>> I actually use the more explicit, but hopefully equivalent:
>>>>   #define MT76XX_GPIO1_MODE   0x1060
>>>>   #define MIPS_KSEG1_START    0xA000
>>>>
>>>>   uint32_t v, *a;
>>>>   a = (uint32_t *)(MIPS_KSEG1_START + MT76XX_GPIO1_MODE);
>>>>   v = *a;
>>>>   v &= 0xF3FF;
>>>>   v |= 0x000C;
>>>>   *a = v;
>>>>
>>>> It is unclear to me how Linkit port could work.
>>>
>>> I double checked on LiniIt and it works without this bit 2/3
>>> setting:
>>>
>>> => md b060 1
>>> b060: 50050404   ...P
>>>
>>> You can check this on your VoCore2 board by setting this value
>>> from the prompt. If this works, then its not strictly needed.
>>>
>> This seems to be strictly needed on my board:
>>  U-Boot 1.1.3 (Apr 23 2017 - 14:59:01)
>>  VoCore2 > md b060 1
>>  b060: 5505040c    ...U
>>  VoCore2 > mm b060
>>  b060: 5505040c ? 55050404
>>  
>> This is with the original "paleolithic" u-boot, of course, but it
>> should be a HW-related feature, should I try also with "current"
>> (RAM based)?
>
> In your version above, you do *not* have configured bits 27:26
> (UART2 GPIO mode) to 00b but to 01b (GPIO mode).
>
> I did this test on my LinkIt and wrote your original value:
>
> => mw b060 5505040c�
> 
>
> So this does not work for me.
>
> You might want to try my value "50050404" with your 1.1.3 version
> to see, if this works there. But I dount it.
As expected it does NOT work.

>  
>> I am surprised though as all I could find on differences between
>> MT7628 and MT7688 are is a reference on Mediatek site:
>> https://docs.labs.mediatek.com/resource/linkit-smart-7688/en/faq
>>
>> Q: What’s MT7628 and how is it different from MT7688AN?
>>
>> The MT7628 series are pin-to-pin compatible with the MT7688 series.
>> However, MT7628 comes with a 2T2R antenna, while MT7688 only supports
>> 1T1R antenna.
>>
>> (Incomplete!) comparison of the two datasheets did not show
>> relevant differences.
I have started an analysis of current register status (and I quickly hit
limitation of the documentation I have):

    b008: 0001    
E-Fuse Configuration is not pristine, but I don't know what it my mean.

    b010: 0044    D...
System Configuration Register 0 ->  0001 0001 0001 0001 1000 1000

 TEST_CODE
000          *
100010001    BS_SHADOW
000          *
1            DBG_JTAG_MODE    1: Normal Boot-up
1            TEST_MODE_1         ??
0            XTAL_FREQ_SEL    0: 25MHz DIP ???
0            EXT_BG           0: BG clock from PMU
0            TEST_MODE_0      0: SUTIF
100          CHIP_MODE      100: SCAN mode
0            DRAM_TYPE        0: DDR2

I am concerned by TEST_MODE_1,XTAL_FREQ_SEL and CHIP_MODE that might
signal a different up/down pulling of Bootstrapping Pins.
Could You cross check on LinkIt, please?

>>>> Anyways now my "secondary from ROM" approach now
>>>> works without the long delay described below.
>>>>
>>>> Unfortunately this does not seem to be the whole story because
>>>> flashing u-boot linked directly in the "right palace":
>>>>
>>>>   SYS_TEXT_BASE = 0x9c00
>>>>
>>>> still refuses to display anything on serial; I assume some other
>>>> initialization is missing, but that will be another fight.
>>>>
>>>> Any insight welcome.
>>>
>>> Did my new image from yesterday produce any output on your board?
>> No.
>> Your image was as silent as mine.
>> Not a single char in serial line.
>
> I see. If you really need a different UART2 mux setup in the GPIO1_MODE
> register, this might explain the difference. I can generate a new image
> (untested) with your GPIO1_MODE value of 5505040c for you to test. Just
> let me kn

Re: Debugging VoCore2 ROM Startup

[Mauro Condarelli]

HI Stefan,

On 1/15/20 8:25 AM, Stefan Roese wrote:
> Hi Mauro,
>
> On 15.01.20 00:55, Mauro Condarelli wrote:
>> I found *one* of the bugs in startup:
>> To enable UART2 pinmux setting:
>>  void __iomem *gpio_mode;
>>  gpio_mode = ioremap_nocache(MT76XX_GPIO1_MODE, 0x100);
>>  clrbits_le32(gpio_mode, GENMASK(27, 26));
>> is not enough; you need also:
>>  setbits_le32(gpio_mode, GENMASK(3, 2));
>> I actually use the more explicit, but hopefully equivalent:
>>  #define MT76XX_GPIO1_MODE   0x1060
>>  #define MIPS_KSEG1_START    0xA000
>>
>>  uint32_t v, *a;
>>  a = (uint32_t *)(MIPS_KSEG1_START + MT76XX_GPIO1_MODE);
>>  v = *a;
>>  v &= 0xF3FF;
>>  v |= 0x000C;
>>  *a = v;
>>
>> It is unclear to me how Linkit port could work.
>
> I double checked on LiniIt and it works without this bit 2/3
> setting:
>
> => md b060 1
> b060: 50050404   ...P
>
> You can check this on your VoCore2 board by setting this value
> from the prompt. If this works, then its not strictly needed.
>
This seems to be strictly needed on my board:
    U-Boot 1.1.3 (Apr 23 2017 - 14:59:01)
    VoCore2 > md b060 1
    b060: 5505040c    ...U
    VoCore2 > mm b060
    b060: 5505040c ? 55050404
    
This is with the original "paleolithic" u-boot, of course, but it
should be a HW-related feature, should I try also with "current"
(RAM based)?

I am surprised though as all I could find on differences between
MT7628 and MT7688 are is a reference on Mediatek site:
https://docs.labs.mediatek.com/resource/linkit-smart-7688/en/faq

Q: What’s MT7628 and how is it different from MT7688AN?

The MT7628 series are pin-to-pin compatible with the MT7688 series.
However, MT7628 comes with a 2T2R antenna, while MT7688 only supports
1T1R antenna.

(Incomplete!) comparison of the two datasheets did not show
relevant differences.
>> Anyways now my "secondary from ROM" approach now
>> works without the long delay described below.
>>
>> Unfortunately this does not seem to be the whole story because
>> flashing u-boot linked directly in the "right palace":
>>
>>  SYS_TEXT_BASE = 0x9c00
>>
>> still refuses to display anything on serial; I assume some other
>> initialization is missing, but that will be another fight.
>>
>> Any insight welcome.
>
> Did my new image from yesterday produce any output on your board?
No.
Your image was as silent as mine.
Not a single char in serial line.

> BTW: How do you flash the image into SPI NOR? From the new mainline
> U-Boot loaded into RAM or from the ancient 1.1.3 version? Perhaps
> something is going wrong in the flashing process?
I will try to read back after flashing, but I somewhat doubt that's the
problem.
I am using the new, RAM-based U-Boot to flash.
Actual sequence is:
    usb reset; fatload usb 0 8001 u-boot-ram.bin; go 8001
    usb start; sf probe;
    load usb 0:1 8500 u-boot-rom.bin; sf update ${fileaddr} u-boot
${filesize}
    reset
where:
=> mtd list
    List of MTD devices:
    * nor0
      - type: NOR flash
      - block size: 0x1000 bytes
      - min I/O: 0x1 bytes
      - 0x-0x0100 : "nor0"
          - 0x-0x0007e000 : "u-boot"
          - 0x0007e000-0x0007f000 : "env"
          - 0x0007f000-0x0008 : "factory"
          - 0x0008-0x0032 : "kernel"
          - 0x0032-0x0100 : "filesystem"
Equivalent sequences work correctly to flash kernel and (recovery)
filesystem.

> Thanks,
> Stefan
Many thanks for Your patience...
Mauro

Debugging VoCore2 ROM Startup (was: How to debug HW startup?)

[Mauro Condarelli]

I found *one* of the bugs in startup:
To enable UART2 pinmux setting:
    void __iomem *gpio_mode;
    gpio_mode = ioremap_nocache(MT76XX_GPIO1_MODE, 0x100);
    clrbits_le32(gpio_mode, GENMASK(27, 26));
is not enough; you need also:
    setbits_le32(gpio_mode, GENMASK(3, 2));
I actually use the more explicit, but hopefully equivalent:
    #define MT76XX_GPIO1_MODE   0x1060
    #define MIPS_KSEG1_START    0xA000

    uint32_t v, *a;
    a = (uint32_t *)(MIPS_KSEG1_START + MT76XX_GPIO1_MODE);
    v = *a;
    v &= 0xF3FF;
    v |= 0x000C;
    *a = v;

It is unclear to me how Linkit port could work.
Anyways now my "secondary from ROM" approach now
works without the long delay described below.

Unfortunately this does not seem to be the whole story because
flashing u-boot linked directly in the "right palace":

SYS_TEXT_BASE = 0x9c00

still refuses to display anything on serial; I assume some other
initialization is missing, but that will be another fight.

Any insight welcome.
Regards
Mauro

On 1/14/20 12:08 AM, Mauro Condarelli wrote:
> Next episode of this telenovela:
>
> I rebuilt u-boot for ROM at BC03 (my code, very similar to LinkIt).
> I flashed it at 3 in SPI NOR:
>
> => usb start; sf probe
> starting USB...
> Bus ehci@101c: pinctrl_select_state_full('ehci@101c', 'default'):
> USB EHCI 1.00
> scanning bus ehci@101c for devices... 3 USB Device(s) found
>    scanning usb for storage devices... 1 Storage Device(s) found
> SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total
> 16 MiB
> => load usb 0:1 8500 u-boot.secondary
> 390089 bytes read in 18 ms (20.7 MiB/s)
> => sf update ${fileaddr} 3 ${filesize}
> device 0 offset 0x3, size 0x5f3c9
> 390089 bytes written, 0 bytes skipped in 9.751s, speed 40952 B/s
> => reset
>
> Restarted old u-boot and jumped to new:
>
> U-Boot 1.1.3 (Apr 23 2017 - 14:59:01)
> VoCore2 > go bc03
> ## Starting application at 0xBC03 ...
> board_debug_uart_init():
> 
> System stopped here several minutes, enough for me to start writing
> this email, then it continued boot sequence:
>  board_debug_uart_init():
> board_early_init_f():
> pinctrl_select_state_full('palmbus@1000', 'default'):
> pinctrl_select_state_full('uart2@e00', 'default'):
> pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19
> pinctrl_select_state_full('clkctrl@0x2c', 'default'):
>
>
> U-Boot 2020.01-00370-g97a60844bd-dirty (Jan 13 2020 - 23:21:39 +0100)
>
> CPU:   MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr)
> Model: VoCore2
> DRAM:  128 MiB
> pinctrl_select_state_full('palmbus@1000', 'default'):
> pinctrl_select_state_full('pinctrl@60', 'default'):
> pinctrl_select_state_full('pin_state', 'default'):
> pinctrl_select_state_full('uart2@e00', 'default'):
> pinctrl_select_state_full('uart2_pins', 'default'):
> pinctrl_select_state_full('clkctrl@0x2c', 'default'):
> pinctrl_select_state_full('watchdog@100', 'default'):
> WDT:   Started with servicing (60s timeout)
> board_early_init_r():
> arch_early_init_r():
> MMC:   pinctrl_select_state_full('mmc@1013', 'default'):
> pinctrl_select_state_full('sd_iot_mode', 'default'):
> pinctrl_select_state_full('clk48m@0', 'default'):
> pinctrl_select_state_full('mmc@1013', 'default'):
> mmc@1013: 0
> Loading Environment from FAT... *** Warning - bad CRC, using default
> environment
>
> In:    uart2@e00
> Out:   uart2@e00
> Err:   uart2@e00
> Model: VoCore2
> arch_misc_init():
> =>
>
> Code, beside being targeted to ROM and with a different SYS_TEXT_BASE,
> is identical to what runs fine when started from RAM.
>
> I also tried copying flash to ram:
>
> => cp.b bc03 8001 5f3c9
> => go 8001
> ## Starting application at 0x8001 ...
> board_debug_uart_init():
>  [04010D08][04010D08]
> DDR Calibration DQS reg = 
> relocate_code Pointer at: 87f5c000
> ***
> Watchdog Reset Occurred
> ***
>
> ... but this is almost expected because I relocated at another address
> without changing SYS_TEXT_BASE.
>
> A further measurement shows booting u-boot from flash stops for
> almost 5 minutes (4m48s, using a manual stopwatch).
>
> I sincerely have no idea where to bang my head :(
>
> TiA
> Mauro
>
>
> On 1/13/20 3:14 PM, Mauro Condarelli wrote:
>> Hi Stefan,
>> unfortunately it does *not* work.
>>
>> Ram based is ok, but rom  is just as silent as mine:
>>
>> => usb start; sf probe;
>> starting USB...
>> Bus ehci@101c: pinctrl_select_state_full('ehci@101c', 'default'):
>> USB EHCI 1.00
>> scannin

Re: How to debug HW startup?

[Mauro Condarelli]

Hi Stefan,
update, see below.

On 1/14/20 12:08 AM, Mauro Condarelli wrote:
> Next episode of this telenovela:
>
> I rebuilt u-boot for ROM at BC03 (my code, very similar to LinkIt).
> I flashed it at 3 in SPI NOR:
>
> => usb start; sf probe
> starting USB...
> Bus ehci@101c: pinctrl_select_state_full('ehci@101c', 'default'):
> USB EHCI 1.00
> scanning bus ehci@101c for devices... 3 USB Device(s) found
>    scanning usb for storage devices... 1 Storage Device(s) found
> SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total
> 16 MiB
> => load usb 0:1 8500 u-boot.secondary
> 390089 bytes read in 18 ms (20.7 MiB/s)
> => sf update ${fileaddr} 3 ${filesize}
> device 0 offset 0x3, size 0x5f3c9
> 390089 bytes written, 0 bytes skipped in 9.751s, speed 40952 B/s
> => reset
>
> Restarted old u-boot and jumped to new:
>
> U-Boot 1.1.3 (Apr 23 2017 - 14:59:01)
> VoCore2 > go bc03
> ## Starting application at 0xBC03 ...
> board_debug_uart_init():
> 
> System stopped here several minutes, enough for me to start writing
> this email, then it continued boot sequence:
>  board_debug_uart_init():
> board_early_init_f():
Here is the first strange thing:
apparently `board_debug_uart_init()` is called twice.

I am not 100% sure as code is full of `#ifdef`s, but it seems
first time it's called in `arch/mips/cpu/start.S`, most likely
in line 257 as I couldn't find traces of CONFIG_MIPS_INIT_STACK_IN_SRAM
(besides `arch/mips/cpu/Kconfig:381` where is defined,
defaults to `n` and none seems to touch anymore;
second strange thing is I find no trace of it in `.config`)

This, again, does not add-up (third "strange thing") because
I see nothing between calls to `debug_uart_init` (start.S:257)
and `board_init_f` (start.S:264) that could trigger a ~5min delay
(but I'm really out of my depth, here!) unless there's something
in the `printascii()`itself (e.g.: loop at serial_mtk.c:449 blocks).

> pinctrl_select_state_full('palmbus@1000', 'default'):
> pinctrl_select_state_full('uart2@e00', 'default'):
> pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19
> pinctrl_select_state_full('clkctrl@0x2c', 'default'):
>
>
> U-Boot 2020.01-00370-g97a60844bd-dirty (Jan 13 2020 - 23:21:39 +0100)
>
> CPU:   MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr)
> Model: VoCore2
> DRAM:  128 MiB
> pinctrl_select_state_full('palmbus@1000', 'default'):
> pinctrl_select_state_full('pinctrl@60', 'default'):
> pinctrl_select_state_full('pin_state', 'default'):
> pinctrl_select_state_full('uart2@e00', 'default'):
> pinctrl_select_state_full('uart2_pins', 'default'):
> pinctrl_select_state_full('clkctrl@0x2c', 'default'):
> pinctrl_select_state_full('watchdog@100', 'default'):
> WDT:   Started with servicing (60s timeout)
> board_early_init_r():
> arch_early_init_r():
> MMC:   pinctrl_select_state_full('mmc@1013', 'default'):
> pinctrl_select_state_full('sd_iot_mode', 'default'):
> pinctrl_select_state_full('clk48m@0', 'default'):
> pinctrl_select_state_full('mmc@1013', 'default'):
> mmc@1013: 0
> Loading Environment from FAT... *** Warning - bad CRC, using default
> environment
>
> In:    uart2@e00
> Out:   uart2@e00
> Err:   uart2@e00
> Model: VoCore2
> arch_misc_init():
> =>
>
> Code, beside being targeted to ROM and with a different SYS_TEXT_BASE,
> is identical to what runs fine when started from RAM.
>
> I also tried copying flash to ram:
>
> => cp.b bc03 8001 5f3c9
> => go 8001
> ## Starting application at 0x8001 ...
> board_debug_uart_init():
>  [04010D08][04010D08]
> DDR Calibration DQS reg = 
> relocate_code Pointer at: 87f5c000
> ***
> Watchdog Reset Occurred
> ***
>
> ... but this is almost expected because I relocated at another address
> without changing SYS_TEXT_BASE.
>
> A further measurement shows booting u-boot from flash stops for
> almost 5 minutes (4m48s, using a manual stopwatch).
>
> I sincerely have no idea where to bang my head :(
>
> TiA
> Mauro
>
>
> On 1/13/20 3:14 PM, Mauro Condarelli wrote:
>> Hi Stefan,
>> unfortunately it does *not* work.
>>
>> Ram based is ok, but rom  is just as silent as mine:
>>
>> => usb start; sf probe;
>> starting USB...
>> Bus ehci@101c: pinctrl_select_state_full('ehci@101c', 'default'):
>> USB EHCI 1.00
>> scanning bus ehci@101c for devices... 3 USB Device(s) found
>>    scanning usb for storage devices... 1 Storage Device(s) found
>> pinctrl_select_state_full('spi@b00', 'default'):
>> SF: Detected gd25q128 with page siz

Re: How to debug HW startup?

[Mauro Condarelli]

Next episode of this telenovela:

I rebuilt u-boot for ROM at BC03 (my code, very similar to LinkIt).
I flashed it at 3 in SPI NOR:

=> usb start; sf probe
starting USB...
Bus ehci@101c: pinctrl_select_state_full('ehci@101c', 'default'):
USB EHCI 1.00
scanning bus ehci@101c for devices... 3 USB Device(s) found
   scanning usb for storage devices... 1 Storage Device(s) found
SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total
16 MiB
=> load usb 0:1 8500 u-boot.secondary
390089 bytes read in 18 ms (20.7 MiB/s)
=> sf update ${fileaddr} 3 ${filesize}
device 0 offset 0x3, size 0x5f3c9
390089 bytes written, 0 bytes skipped in 9.751s, speed 40952 B/s
=> reset

Restarted old u-boot and jumped to new:

U-Boot 1.1.3 (Apr 23 2017 - 14:59:01)
VoCore2 > go bc03
## Starting application at 0xBC03 ...
board_debug_uart_init():

System stopped here several minutes, enough for me to start writing
this email, then it continued boot sequence:
 board_debug_uart_init():
board_early_init_f():
pinctrl_select_state_full('palmbus@1000', 'default'):
pinctrl_select_state_full('uart2@e00', 'default'):
pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19
pinctrl_select_state_full('clkctrl@0x2c', 'default'):


U-Boot 2020.01-00370-g97a60844bd-dirty (Jan 13 2020 - 23:21:39 +0100)

CPU:   MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr)
Model: VoCore2
DRAM:  128 MiB
pinctrl_select_state_full('palmbus@1000', 'default'):
pinctrl_select_state_full('pinctrl@60', 'default'):
pinctrl_select_state_full('pin_state', 'default'):
pinctrl_select_state_full('uart2@e00', 'default'):
pinctrl_select_state_full('uart2_pins', 'default'):
pinctrl_select_state_full('clkctrl@0x2c', 'default'):
pinctrl_select_state_full('watchdog@100', 'default'):
WDT:   Started with servicing (60s timeout)
board_early_init_r():
arch_early_init_r():
MMC:   pinctrl_select_state_full('mmc@1013', 'default'):
pinctrl_select_state_full('sd_iot_mode', 'default'):
pinctrl_select_state_full('clk48m@0', 'default'):
pinctrl_select_state_full('mmc@1013', 'default'):
mmc@1013: 0
Loading Environment from FAT... *** Warning - bad CRC, using default
environment

In:    uart2@e00
Out:   uart2@e00
Err:   uart2@e00
Model: VoCore2
arch_misc_init():
=>

Code, beside being targeted to ROM and with a different SYS_TEXT_BASE,
is identical to what runs fine when started from RAM.

I also tried copying flash to ram:

=> cp.b bc03 8001 5f3c9
=> go 8001
## Starting application at 0x8001 ...
board_debug_uart_init():
 [04010D08][04010D08]
DDR Calibration DQS reg = 
relocate_code Pointer at: 87f5c000
***
Watchdog Reset Occurred
***

... but this is almost expected because I relocated at another address
without changing SYS_TEXT_BASE.

A further measurement shows booting u-boot from flash stops for
almost 5 minutes (4m48s, using a manual stopwatch).

I sincerely have no idea where to bang my head :(

TiA
Mauro


On 1/13/20 3:14 PM, Mauro Condarelli wrote:
> Hi Stefan,
> unfortunately it does *not* work.
>
> Ram based is ok, but rom  is just as silent as mine:
>
> => usb start; sf probe;
> starting USB...
> Bus ehci@101c: pinctrl_select_state_full('ehci@101c', 'default'):
> USB EHCI 1.00
> scanning bus ehci@101c for devices... 3 USB Device(s) found
>    scanning usb for storage devices... 1 Storage Device(s) found
> pinctrl_select_state_full('spi@b00', 'default'):
> SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total
> 16 MiB
> => load usb 0:1 8500 u-boot_linkit.bin-rom
> 455708 bytes read in 22 ms (19.8 MiB/s)
> => sf update ${fileaddr} 0 ${filesize}
> device 0 offset 0x0, size 0x6f41c
> 455708 bytes written, 0 bytes skipped in 12.288s, speed 37966 B/s
> => reset
> resetting ...
> pinctrl_select_state_full('syscon-reboot', 'default'):
> pinctrl_select_state_full('system-controller@0', 'default'):
>
> I might have done something stupid; Now I need do stop, but I'll
> test again this evening.
>
> Many thanks
> Mauro
>
>
> On 1/13/20 1:45 PM, Stefan Roese wrote:
>> On 13.01.20 13:24, Mauro Condarelli wrote:
>>>
>>> On 1/13/20 12:39 PM, Stefan Roese wrote:
>>>> Hi Mauro,
>>>>
>>>> On 13.01.20 11:24, Mauro Condarelli wrote:
>>>>> On 1/13/20 7:53 AM, Stefan Roese wrote:
>>>>>> Hi Mauro,
>>>>>>
>>>>>> On 11.01.20 20:00, Mauro Condarelli wrote:
>>>>>>> I managed to find ONE of the reasons why my ROM build didn't run:
>>>>>>> I forgot to enable `CONFIG_BOARD_EARLY_INIT_F=y`.
>>>>>> I see. This explains of course, why your board does not boot without
>>>>>> any "pre

Re: How to debug HW startup?

[Mauro Condarelli]

Hi Stefan,
unfortunately it does *not* work.

Ram based is ok, but rom  is just as silent as mine:

=> usb start; sf probe;
starting USB...
Bus ehci@101c: pinctrl_select_state_full('ehci@101c', 'default'):
USB EHCI 1.00
scanning bus ehci@101c for devices... 3 USB Device(s) found
   scanning usb for storage devices... 1 Storage Device(s) found
pinctrl_select_state_full('spi@b00', 'default'):
SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total
16 MiB
=> load usb 0:1 8500 u-boot_linkit.bin-rom
455708 bytes read in 22 ms (19.8 MiB/s)
=> sf update ${fileaddr} 0 ${filesize}
device 0 offset 0x0, size 0x6f41c
455708 bytes written, 0 bytes skipped in 12.288s, speed 37966 B/s
=> reset
resetting ...
pinctrl_select_state_full('syscon-reboot', 'default'):
pinctrl_select_state_full('system-controller@0', 'default'):

I might have done something stupid; Now I need do stop, but I'll
test again this evening.

Many thanks
Mauro


On 1/13/20 1:45 PM, Stefan Roese wrote:
> On 13.01.20 13:24, Mauro Condarelli wrote:
>>
>>
>> On 1/13/20 12:39 PM, Stefan Roese wrote:
>>> Hi Mauro,
>>>
>>> On 13.01.20 11:24, Mauro Condarelli wrote:
>>>> On 1/13/20 7:53 AM, Stefan Roese wrote:
>>>>> Hi Mauro,
>>>>>
>>>>> On 11.01.20 20:00, Mauro Condarelli wrote:
>>>>>> I managed to find ONE of the reasons why my ROM build didn't run:
>>>>>> I forgot to enable `CONFIG_BOARD_EARLY_INIT_F=y`.
>>>>>
>>>>> I see. This explains of course, why your board does not boot without
>>>>> any "preloader".
>>>>>
>>>>>> I wanted, nonetheless, be prepared for further mishaps, but
>>>>>> I have some other problems (see below).
>>>>>
>>>>> Are these issues now fixed? I scanned the discussion about the DEBUG
>>>>> UART on the list. Is this working for you now or do you have any
>>>>> other
>>>>> issues still? Did you successfully boot your new U-Boot from SPI NOR?
>>>> Yes and no :(
>>>>
>>>> I fixed my RAM-based problems, but booting from SPI NOR still
>>>> refuses to
>>>> utter a single byte.
>>>> I do attach  my defconfigs and my board.c for your reading pleasure
>>>> (in
>>>> case you have troubles getting asleep they should provide a good
>>>> cure).
>>>
>>> Before looking into this in more depth (I actually do have problems
>>> sleeping
>>> though, so I might take a look at it later ;)), why don't you re-start
>>> with
>>> your defconfig by using the linkit defconfig file. If you are lucky,
>>> the
>>> LinkIt binary might even work for the VoCore2. Or what are the
>>> differences
>>> except the SoC type and WLAN? Its the same DDR2 config and the same
>>> UART.
>>> So it might get you pretty far - also with ROM based booting.
>> I will try it.
>> Just to be on the safe side, could You attach a binary (or two: ROM and
>> RAM) to
>> the mail? If it works it would really give me a start base.
>
> See below.
>   
>>>> I also added a couple of printouts in drivers/pinctrl/pinctrl-uclass.c
>>>> and it
>>>> turns out system tries to setup pins for uart2, but fails (maybe
>>>> because
>>>> pinctrl@60 is not yet setup correctly?).
>>>> This is the output I get from RAM-based u-boot:
>>>>
>>>>  board_debug_uart_init():
>>>> board_early_init_f():
>>>> pinctrl_select_state_full('palmbus@1000', 'default'):
>>>> pinctrl_select_state_full('uart2@e00', 'default'):
>>>> pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19
>>>> pinctrl_select_state_full('clkctrl@0x2c', 'default'):
>>>>
>>>> U-Boot 2020.01-00370-g97a60844bd-dirty (Jan 13 2020 - 01:03:59 +0100)
>>>>
>>>> CPU:   MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr)
>>>> Model: VoCore2
>>>> DRAM:  128 MiB
>>>> pinctrl_select_state_full('palmbus@1000', 'default'):
>>>> pinctrl_select_state_full('pinctrl@60', 'default'):
>>>> pinctrl_select_state_full('pin_state', 'default'):
>>>> pinctrl_select_state_full('uart2@e00', 'default'):
>>>> pinctrl_select_state_full('uart2_pins', 'default'):
>>>> pinctrl_select_state_full('clkctrl@0x2c', 'default'):
>>>> pinctrl_select_state_full('watchdog@100', 'default'):
>>>> WDT:   Started with servicing (60s timeout)
>>>> 

Re: How to debug HW startup?

[Mauro Condarelli]

On 1/13/20 12:39 PM, Stefan Roese wrote:
> Hi Mauro,
>
> On 13.01.20 11:24, Mauro Condarelli wrote:
>> On 1/13/20 7:53 AM, Stefan Roese wrote:
>>> Hi Mauro,
>>>
>>> On 11.01.20 20:00, Mauro Condarelli wrote:
>>>> I managed to find ONE of the reasons why my ROM build didn't run:
>>>> I forgot to enable `CONFIG_BOARD_EARLY_INIT_F=y`.
>>>
>>> I see. This explains of course, why your board does not boot without
>>> any "preloader".
>>>
>>>> I wanted, nonetheless, be prepared for further mishaps, but
>>>> I have some other problems (see below).
>>>
>>> Are these issues now fixed? I scanned the discussion about the DEBUG
>>> UART on the list. Is this working for you now or do you have any other
>>> issues still? Did you successfully boot your new U-Boot from SPI NOR?
>> Yes and no :(
>>
>> I fixed my RAM-based problems, but booting from SPI NOR still refuses to
>> utter a single byte.
>> I do attach  my defconfigs and my board.c for your reading pleasure (in
>> case you have troubles getting asleep they should provide a good cure).
>
> Before looking into this in more depth (I actually do have problems
> sleeping
> though, so I might take a look at it later ;)), why don't you re-start
> with
> your defconfig by using the linkit defconfig file. If you are lucky, the
> LinkIt binary might even work for the VoCore2. Or what are the
> differences
> except the SoC type and WLAN? Its the same DDR2 config and the same UART.
> So it might get you pretty far - also with ROM based booting.
I will try it.
Just to be on the safe side, could You attach a binary (or two: ROM and
RAM) to
the mail? If it works it would really give me a start base.
 
>> I also added a couple of printouts in drivers/pinctrl/pinctrl-uclass.c
>> and it
>> turns out system tries to setup pins for uart2, but fails (maybe because
>> pinctrl@60 is not yet setup correctly?).
>> This is the output I get from RAM-based u-boot:
>>
>>  board_debug_uart_init():
>> board_early_init_f():
>> pinctrl_select_state_full('palmbus@1000', 'default'):
>> pinctrl_select_state_full('uart2@e00', 'default'):
>> pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19
>> pinctrl_select_state_full('clkctrl@0x2c', 'default'):
>>
>> U-Boot 2020.01-00370-g97a60844bd-dirty (Jan 13 2020 - 01:03:59 +0100)
>>
>> CPU:   MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr)
>> Model: VoCore2
>> DRAM:  128 MiB
>> pinctrl_select_state_full('palmbus@1000', 'default'):
>> pinctrl_select_state_full('pinctrl@60', 'default'):
>> pinctrl_select_state_full('pin_state', 'default'):
>> pinctrl_select_state_full('uart2@e00', 'default'):
>> pinctrl_select_state_full('uart2_pins', 'default'):
>> pinctrl_select_state_full('clkctrl@0x2c', 'default'):
>> pinctrl_select_state_full('watchdog@100', 'default'):
>> WDT:   Started with servicing (60s timeout)
>> board_early_init_r():
>> arch_early_init_r():
>> MMC:   pinctrl_select_state_full('mmc@1013', 'default'):
>> pinctrl_select_state_full('sd_iot_mode', 'default'):
>> pinctrl_select_state_full('clk48m@0', 'default'):
>> pinctrl_select_state_full('mmc@1013', 'default'):
>> mmc@1013: 0
>> Loading Environment from FAT... *** Warning - bad CRC, using default
>> environment
>>
>> In:    uart2@e00
>> Out:   uart2@e00
>> Err:   uart2@e00
>> Model: VoCore2
>> arch_misc_init():
>> =>
>
> I don't have all these pinctrl issues on LinkIt. I suspect a config
> issue and / or dts issue. Please compare.
I will, but I was trying to say something different:
Apparently the stock software tries to initialize uart2 pinctrl and it
*seems* to succeed later in initialization.
This *seems* to indicate explicit pin setup in board_early_init_f() is
not strictly needed (we would lose only the first few lines even if
we don't fix the error).
I had a look to pinctrl-mt7628.c and it seems to do the right thing
upon call to ('uart2_pins', 'default'), so anything after that *should*
work even without low-level setup.

>>
>> ROM-based u-boot, as said, does not print *anything*, not even garbage.
>> I'm beginning to suspect I have some mishap with start address or
>> similar.
>> I have absolutely no idea how to debug this without a JTAG probe (which
>> I don't have and would be non-trivial to get working; soldering
>> required).
>
> Yes. JTAG requires soldering IIRC.
>  
>> The only idea I currently have is to modify my "old" u-boot to do
>> initialization
>> and then ju

Re: How to debug HW startup?

[Mauro Condarelli]

Hi Stefan,

On 1/13/20 7:53 AM, Stefan Roese wrote:
> Hi Mauro,
>
> On 11.01.20 20:00, Mauro Condarelli wrote:
>> I managed to find ONE of the reasons why my ROM build didn't run:
>> I forgot to enable `CONFIG_BOARD_EARLY_INIT_F=y`.
>
> I see. This explains of course, why your board does not boot without
> any "preloader".
>
>> I wanted, nonetheless, be prepared for further mishaps, but
>> I have some other problems (see below).
>
> Are these issues now fixed? I scanned the discussion about the DEBUG
> UART on the list. Is this working for you now or do you have any other
> issues still? Did you successfully boot your new U-Boot from SPI NOR?
Yes and no :(

I fixed my RAM-based problems, but booting from SPI NOR still refuses to
utter a single byte.
I do attach  my defconfigs and my board.c for your reading pleasure (in
case you have troubles getting asleep they should provide a good cure).

I also added a couple of printouts in drivers/pinctrl/pinctrl-uclass.c
and it
turns out system tries to setup pins for uart2, but fails (maybe because
pinctrl@60 is not yet setup correctly?).
This is the output I get from RAM-based u-boot:

 board_debug_uart_init():
board_early_init_f():
pinctrl_select_state_full('palmbus@1000', 'default'):
pinctrl_select_state_full('uart2@e00', 'default'):
pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19
pinctrl_select_state_full('clkctrl@0x2c', 'default'):


U-Boot 2020.01-00370-g97a60844bd-dirty (Jan 13 2020 - 01:03:59 +0100)

CPU:   MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr)
Model: VoCore2
DRAM:  128 MiB
pinctrl_select_state_full('palmbus@1000', 'default'):
pinctrl_select_state_full('pinctrl@60', 'default'):
pinctrl_select_state_full('pin_state', 'default'):
pinctrl_select_state_full('uart2@e00', 'default'):
pinctrl_select_state_full('uart2_pins', 'default'):
pinctrl_select_state_full('clkctrl@0x2c', 'default'):
pinctrl_select_state_full('watchdog@100', 'default'):
WDT:   Started with servicing (60s timeout)
board_early_init_r():
arch_early_init_r():
MMC:   pinctrl_select_state_full('mmc@1013', 'default'):
pinctrl_select_state_full('sd_iot_mode', 'default'):
pinctrl_select_state_full('clk48m@0', 'default'):
pinctrl_select_state_full('mmc@1013', 'default'):
mmc@1013: 0
Loading Environment from FAT... *** Warning - bad CRC, using default
environment

In:    uart2@e00
Out:   uart2@e00
Err:   uart2@e00
Model: VoCore2
arch_misc_init():
=>

ROM-based u-boot, as said, does not print *anything*, not even garbage.
I'm beginning to suspect I have some mishap with start address or similar.
I have absolutely no idea how to debug this without a JTAG probe (which
I don't have and would be non-trivial to get working; soldering required).

The only idea I currently have is to modify my "old" u-boot to do
initialization
and then jump to beginning of "new" u-boot.
If I can make it work in an automatic way I can try removing
initialization steps
till I find the "culprit".
Any better idea would be welcome, of course!

If I have to resort to that clumsy method, would be enough to put  "new"
in  SPI NOR (of course at an higher address, e.g.: 3 as "old" is only
183272 bytes long) and jump to the first location?
I assume I will have to relocate CONFIG_SYS_TEXT_BASE=0xbc03
Did I forget something?

> 
>
>>> You might also want to give the new version / patches from Weijie
>>> a try. He added SPL support and a "cleaner" init code for this SoC.
>> I'm interested in giving it a spin (and help debugging on another HW,
>> if needed), but I would like to have a solid base from where to move,
>> changing too many things at once is rarely a good strategy ;)
>
> I fully agree.
I need to be able to start from SPI NOR, before I can commit to some
other task
 
> Thanks,
> Stefan
Many thanks
Mauro
CONFIG_MIPS=y
CONFIG_SYS_TEXT_BASE=0x9c00
CONFIG_ENV_SIZE=0x1000
CONFIG_NR_DRAM_BANKS=1
CONFIG_DEBUG_UART_BOARD_INIT=y
CONFIG_DEBUG_UART_BASE=0x1e00
CONFIG_DEBUG_UART_CLOCK=4000
CONFIG_ARCH_MTMIPS=y
CONFIG_BOARD_VOCORE2=y
CONFIG_BOOT_ROM=y
CONFIG_ONBOARD_DDR2_SIZE_1024MBIT=y
CONFIG_ONBOARD_DDR2_CHIP_WIDTH_16BIT=y
CONFIG_MIPS_BOOT_FDT=y
CONFIG_DEBUG_UART=y
CONFIG_ENV_VARS_UBOOT_CONFIG=y
CONFIG_SYS_BOOT_GET_CMDLINE=y
CONFIG_SYS_BOOT_GET_KBD=y
# CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
CONFIG_USE_BOOTARGS=y
CONFIG_LOGLEVEL=8
CONFIG_VERSION_VARIABLE=y
CONFIG_DISPLAY_BOARDINFO_LATE=y
CONFIG_ARCH_EARLY_INIT_R=y
CONFIG_ARCH_MISC_INIT=y
CONFIG_BOARD_EARLY_INIT_F=y
CONFIG_BOARD_EARLY_INIT_R=y
CONFIG_HUSH_PARSER=y
# CONFIG_AUTOBOOT is not set
# CONFIG_BOOTM_NETBSD is not set
# CONFIG_BOOTM_PLAN9 is not set
# CONFIG_BOOTM_RTEMS is not set
# CONFIG_BOOTM_VXWORKS is not set
# CONFIG_CMD_XIMG is not set
CONFIG_CMD_MEMINFO=y
CONFIG_CMD_GPIO=y
CONFIG_RANDOM_UUID=y
# CONFIG_CMD_LOADB 

Re: How to debug HW startup?

[Mauro Condarelli]

Many thanks.
It appears I had completely misinterpreted the meaning of 
CONFIG_DEBUG_UART_CLOCK.

I see now a correct output and a new warning message:

pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19

right after "" notification.
Tomorrow I'll try to understand what it means.

I don't think I would have found it without You pointing in  the right
direction.

MANY Thanks!
Best regards
Mauro Condarelli

On 1/12/20 12:58 AM, Sean Anderson wrote:
> On 1/11/20 4:38 PM, Mauro Condarelli wrote:
>> Thanks Joel,
>> unfortunately I already have that defined, even if I forgot to copy it.
>> I attach my full .config for reference as I have no idea what I'm
>> still missing.
>>
>> On 1/11/20 9:42 PM, Sean Anderson wrote:
>>>> Could You share a Linkit  _defconfig with early serial debug enabled?
>>>> I'm decidedly missing something as, even enabling
>>>>
>>>> CONFIG_DEBUG_UART=y
>>>> CONFIG_DEBUG_UART_BASE=0x1e00
>>>> CONFIG_DEBUG_UART_CLOCK=20
>>>> CONFIG_DEBUG_UART_SHIFT=2
>>>> CONFIG_DEBUG_UART_ANNOUNCE=y
> So it looks like your clock is way too low. The unit for the clock is
> Hz. From the device tree you sent, this board is based off
> arch/mips/dts/mt7628a.dtsi, using uart2. The clock controller for this
> board is compatible with "mediatek,mt7628-clk", and the driver is
> located in "drivers/clk/mtmips/clk-mt7628.c". From that file, the uart2
> clock gets its frequency from CLK_SRC_PERI. Under mt7628_clk_get_rate,
> the peripheral clock source depends on the value of
> PERI_CLK_FROM_XTAL_SEL, which is initialized to 0 (as documented in the
> data sheet). Therefore, the else clause is taken (unless configured
> otherwise), so you should use 4000 for your clock.
>
>>> You need to pick a debug uart driver, e.g. CONFIG_DEBUG_UART_NS16550.
>> As said I have it, but I'm not sure about the other parameters.
>> Maybe a better choice would be CONFIG_DEBUG_UART_MTK.
>> Having a "known good" configuration would help a lot.
>>
>> Regards
>> Mauro
>>
>

Re: How to debug HW startup?

[Mauro Condarelli]

Thanks Joel,
unfortunately I already have that defined, even if I forgot to copy it.
I attach my full .config for reference as I have no idea what I'm
still missing.

On 1/11/20 9:42 PM, Sean Anderson wrote:
>> Could You share a Linkit  _defconfig with early serial debug enabled?
>> I'm decidedly missing something as, even enabling
>>
>> CONFIG_DEBUG_UART=y
>> CONFIG_DEBUG_UART_BASE=0x1e00
>> CONFIG_DEBUG_UART_CLOCK=20
>> CONFIG_DEBUG_UART_SHIFT=2
>> CONFIG_DEBUG_UART_ANNOUNCE=y
>>
>> I still have plenty of errors:
>>
>> /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd:
>> arch/mips/cpu/start.o: in function `wr_done':
>> (.text+0x650): undefined reference to `debug_uart_init'
>> /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd:
>> (.text+0x654): undefined reference to `debug_uart_init'
>> /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd:
>> board/vocore/vocore2/built-in.o: in function `board_early_init_f':
>> (.text.board_early_init_f+0x10): undefined reference to `printhex8'
>> /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd:
>> common/built-in.o: in function `putc':
>> (.text.putc+0x18): undefined reference to `printch'
>> /home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd:
>> common/built-in.o: in function `puts':
>> (.text.puts+0x2c): undefined reference to `printch'
>>
> You need to pick a debug uart driver, e.g. CONFIG_DEBUG_UART_NS16550.
As said I have it, but I'm not sure about the other parameters.
Maybe a better choice would be CONFIG_DEBUG_UART_MTK.
Having a "known good" configuration would help a lot.

Regards
Mauro
#
# Automatically generated file; DO NOT EDIT.
# U-Boot 2020.01 Configuration
#
CONFIG_HAVE_ARCH_IOREMAP=y
# CONFIG_ARC is not set
# CONFIG_ARM is not set
# CONFIG_M68K is not set
# CONFIG_MICROBLAZE is not set
CONFIG_MIPS=y
# CONFIG_NDS32 is not set
# CONFIG_NIOS2 is not set
# CONFIG_PPC is not set
# CONFIG_RISCV is not set
# CONFIG_SANDBOX is not set
# CONFIG_SH is not set
# CONFIG_X86 is not set
# CONFIG_XTENSA is not set
CONFIG_SYS_ARCH="mips"
CONFIG_SYS_CPU="mips32"
CONFIG_SYS_SOC="mt7628"
CONFIG_SYS_VENDOR="vocore"
CONFIG_SYS_BOARD="vocore2"
CONFIG_SYS_CONFIG_NAME="vocore2"
CONFIG_SYS_TEXT_BASE=0x8001
CONFIG_SYS_MALLOC_F_LEN=0x1000
CONFIG_ENV_SIZE=0x1000
CONFIG_DM_GPIO=y
CONFIG_ERR_PTR_OFFSET=0x0
CONFIG_NR_DRAM_BANKS=1
CONFIG_BOOTSTAGE_STASH_ADDR=0
# CONFIG_DEBUG_UART_BOARD_INIT is not set
CONFIG_DEBUG_UART_BASE=0x1e00
CONFIG_DEBUG_UART_CLOCK=20
CONFIG_IDENT_STRING=""

#
# MIPS architecture
#
# CONFIG_TARGET_QEMU_MIPS is not set
# CONFIG_TARGET_MALTA is not set
# CONFIG_TARGET_VCT is not set
# CONFIG_ARCH_ATH79 is not set
# CONFIG_ARCH_MSCC is not set
# CONFIG_ARCH_BMIPS is not set
CONFIG_ARCH_MTMIPS=y
# CONFIG_ARCH_JZ47XX is not set
# CONFIG_MACH_PIC32 is not set
# CONFIG_TARGET_BOSTON is not set
# CONFIG_TARGET_XILFPGA is not set
CONFIG_SYS_DCACHE_SIZE=0
CONFIG_SYS_DCACHE_LINE_SIZE=0
CONFIG_SYS_ICACHE_SIZE=0
CONFIG_SYS_ICACHE_LINE_SIZE=0

#
# MediaTek MIPS platforms
#
CONFIG_SOC_MT7628=y
# CONFIG_BOARD_GARDENA_SMART_GATEWAY_MT7688 is not set
# CONFIG_BOARD_LINKIT_SMART_7688 is not set
CONFIG_BOARD_VOCORE2=y
CONFIG_BOOT_RAM=y
# CONFIG_BOOT_ROM is not set
CONFIG_SUPPORTS_BOOT_RAM=y
CONFIG_SYS_LITTLE_ENDIAN=y
# CONFIG_CPU_MIPS32_R1 is not set
CONFIG_CPU_MIPS32_R2=y

#
# General setup
#
CONFIG_ROM_EXCEPTION_VECTORS=y
CONFIG_MIPS_CACHE_INDEX_BASE=0x8000
CONFIG_MIPS_RELOCATION_TABLE_SIZE=0x8000

#
# OS boot interface
#
CONFIG_MIPS_BOOT_CMDLINE_LEGACY=y
CONFIG_MIPS_BOOT_ENV_LEGACY=y
CONFIG_MIPS_BOOT_FDT=y
CONFIG_SUPPORTS_LITTLE_ENDIAN=y
CONFIG_SUPPORTS_CPU_MIPS32_R1=y
CONFIG_SUPPORTS_CPU_MIPS32_R2=y
CONFIG_CPU_MIPS32=y
CONFIG_MIPS_TUNE_24KC=y
CONFIG_32BIT=y
CONFIG_SYS_SCACHE_LINE_SIZE=0
CONFIG_SYS_CACHE_SIZE_AUTO=y
CONFIG_MIPS_L1_CACHE_SHIFT_5=y
CONFIG_MIPS_L1_CACHE_SHIFT=5
CONFIG_DEBUG_UART=y
# CONFIG_AHCI is not set

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
# CONFIG_DISTRO_DEFAULTS is not set
CONFIG_ENV_VARS_UBOOT_CONFIG=y
CONFIG_SYS_BOOT_GET_CMDLINE=y
CONFIG_SYS_BOOT_GET_KBD=y
CONFIG_SYS_MALLOC_F=y
CONFIG_EXPERT=y
CONFIG_SYS_MALLOC_CLEAR_ON_INIT=y
# CONFIG_TOOLS_DEBUG is not set
# CONFIG_PHYS_64BIT is not set
CONFIG_BUILD_TARGET=""
# CONFIG_SYS_CUSTOM_LDSCRIPT is not set

#
# Boot images
#
# CONFIG_ANDROID_BOOT_IMAGE is not set
# CONFIG_FIT is not set
CONFIG_LEGACY_IMAGE_FORMAT=y
# CONFIG_OF_BOARD_SETUP is not set
# CONFIG_OF_SYSTEM_SETUP is not set
# CONFIG_OF_STDOUT_VIA_ALIAS is not set
CONFIG_SYS_EXTRA_OPTIONS=""
CONFIG_HAVE_SYS_TEXT_BASE=y
# CONFIG_ARCH_FIXUP_FDT_MEMORY is not set

#
# API
#
# CONFIG_API is not set

#
# Boot timing
#
# CONFIG_BOOTSTAGE is not set
CONFIG_BOOTSTAGE_RECORD_COUNT=30
CONFIG_SPL_BOOTSTAGE_RECORD_COUNT=5
CONFIG_TPL_BOOTSTAGE_RECORD_COUNT=5
CONFIG_BOOTSTAGE_STASH_SIZE=0x1000
# CONFIG_SHOW_BOOT_PROGRESS is not set

#
# Boot media
#
# CONFIG_NAND_BOOT is not set
# 

Re: How to debug HW startup?

[Mauro Condarelli]

Hi Stefan,
I managed to find ONE of the reasons why my ROM build didn't run:
I forgot to enable `CONFIG_BOARD_EARLY_INIT_F=y`.
I wanted, nonetheless, be prepared for further mishaps, but
I have some other problems (see below).


On 1/10/20 2:33 PM, Stefan Roese wrote:
> Hi Mauro,
>
> (added Weijie to Cc)
>
> On 10.01.20 10:06, Mauro Condarelli wrote:
>>
>>
>> On 1/10/20 7:31 AM, Stefan Roese wrote:
>>> Hi Mauro,
>>>
>>> On 09.01.20 18:28, Mauro Condarelli wrote:
>>>> I managed to brick my target.
>>>>
>>>> Situation:
>>>> I have a board with a paleolithic (1.1.3) version of u-boot.
>>>> I had been testing by loading in ram from USB:
>>>>   usb reset; fatload usb 0 8001 u-boot.bin; go 8001
>>>> and everything was ok.
>>>> I changed a few settings (both defconfigs are attached below)
>>>> and tried "the real thing"
>>>> Unfortunately reflashing the actual boot produced a brick.
>>>> It does not utter a single byte.
>>>
>>> Ugh. Too bad.
>> I know... :(
>>  
>>>> I will have to reflash the original using an external apparatus
>>>> (which I don't have here, so I'll have to take target to another
>>>> location, probably tomorrow morning), but question is:
>>>> how do I debug such a situation?
>>>
>>> To debug very early problems, I suggest to use the DEBUG_UART interface
>>> in U-Boot. I also used it quite a lot before - also on this platform.
>>>
>>> Please see:
>>>
>>> include/debug_uart.h:
>>>
>>>  debug_uart_init();
>>>  printhex8(0x01);
>>>  ...
Could You share a Linkit  _defconfig with early serial debug enabled?
I'm decidedly missing something as, even enabling

CONFIG_DEBUG_UART=y
CONFIG_DEBUG_UART_BASE=0x1e00
CONFIG_DEBUG_UART_CLOCK=20
CONFIG_DEBUG_UART_SHIFT=2
CONFIG_DEBUG_UART_ANNOUNCE=y

I still have plenty of errors:

/home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd:
arch/mips/cpu/start.o: in function `wr_done':
(.text+0x650): undefined reference to `debug_uart_init'
/home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd:
(.text+0x654): undefined reference to `debug_uart_init'
/home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd:
board/vocore/vocore2/built-in.o: in function `board_early_init_f':
(.text.board_early_init_f+0x10): undefined reference to `printhex8'
/home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd:
common/built-in.o: in function `putc':
(.text.putc+0x18): undefined reference to `printch'
/home/mcon/vocore/__V2__/Buildroot/recov/host/bin/mipsel-linux-ld.bfd:
common/built-in.o: in function `puts':
(.text.puts+0x2c): undefined reference to `printch'


>>>
>>> When using UART2 on the MT7628 please make sure to configure the pin
>>> mux before using the debug uart. Otherwise nothing will get printed.
>> I do *not* do anything explicitly in my code, but I have stanzas in .dts
>> Is that supposed to be enough? (I attach my current .dts as I'm sorry to
>> say I don't really fully grok .dts and I'm merely copying stanzas
>> around).
>>
>> I have Your code in board/vocore/vocore2/board.c (attached), shouldn't
>> that be enough?
>
> Yes, this should be enough when using UART2 IIRC.
>
> BTW: I just noticed that the VoCore uses the MT7628 and the LinkIt and
> the GARDENA boards both use the MT7688. I don't remember the differences
> but I don't think this should be a problem.
AFAIK differences between MT7628 and MT7688 are restricted to WiFi
radio section (MT7628 is 2r2t while MT7688 is 1r1t); any addendum to
this I would like to know.
 
>>> BTW: This might also be a problem on your board, if you use UART2 and
>>> the muxing is not done no output will occur.
>> I understand (see above).
>>
>>>> What could I have done so wrong?
>>>>
>>>> As You can see I changed only a few settings:
>>>>
>>>> --- configs/vocore_vocore2-ram_defconfig    2020-01-09
>>>> 16:11:12.568096050 +0100
>>>> +++ configs/vocore_vocore2_defconfig    2020-01-09 16:07:10.528267378
>>>> +0100
>>>> @@ -1,9 +1,12 @@
>>>>    CONFIG_MIPS=y
>>>> -CONFIG_SYS_TEXT_BASE=0x8001
>>>> +CONFIG_SYS_TEXT_BASE=0x9c00
>>>>    CONFIG_ENV_SIZE=0x1000
>>>>    CONFIG_NR_DRAM_BANKS=1
>>>>    CONFIG_ARCH_MTMIPS=y
>>>>    CONFIG_BOARD_VOCORE2=y
>>>> +CONFIG_BOOT_ROM=y
>>>> +CONFIG_ONBOARD_DDR2_SIZE_1024MBIT=y
>>>> +CONFIG_ONBOAR

Re: How to debug HW startup?

[Mauro Condarelli]

On 1/10/20 7:31 AM, Stefan Roese wrote:
> Hi Mauro,
>
> On 09.01.20 18:28, Mauro Condarelli wrote:
>> I managed to brick my target.
>>
>> Situation:
>> I have a board with a paleolithic (1.1.3) version of u-boot.
>> I had been testing by loading in ram from USB:
>>  usb reset; fatload usb 0 8001 u-boot.bin; go 8001
>> and everything was ok.
>> I changed a few settings (both defconfigs are attached below)
>> and tried "the real thing"
>> Unfortunately reflashing the actual boot produced a brick.
>> It does not utter a single byte.
>
> Ugh. Too bad.
I know... :(
 
>> I will have to reflash the original using an external apparatus
>> (which I don't have here, so I'll have to take target to another
>> location, probably tomorrow morning), but question is:
>> how do I debug such a situation?
>
> To debug very early problems, I suggest to use the DEBUG_UART interface
> in U-Boot. I also used it quite a lot before - also on this platform.
>
> Please see:
>
> include/debug_uart.h:
>
> debug_uart_init();
> printhex8(0x01);
> ...
>
> When using UART2 on the MT7628 please make sure to configure the pin
> mux before using the debug uart. Otherwise nothing will get printed.
I do *not* do anything explicitly in my code, but I have stanzas in .dts
Is that supposed to be enough? (I attach my current .dts as I'm sorry to
say I don't really fully grok .dts and I'm merely copying stanzas around).

I have Your code in board/vocore/vocore2/board.c (attached), shouldn't
that be enough?
 
> BTW: This might also be a problem on your board, if you use UART2 and
> the muxing is not done no output will occur.
I understand (see above).

>> What could I have done so wrong?
>>
>> As You can see I changed only a few settings:
>>
>> --- configs/vocore_vocore2-ram_defconfig    2020-01-09
>> 16:11:12.568096050 +0100
>> +++ configs/vocore_vocore2_defconfig    2020-01-09 16:07:10.528267378
>> +0100
>> @@ -1,9 +1,12 @@
>>   CONFIG_MIPS=y
>> -CONFIG_SYS_TEXT_BASE=0x8001
>> +CONFIG_SYS_TEXT_BASE=0x9c00
>>   CONFIG_ENV_SIZE=0x1000
>>   CONFIG_NR_DRAM_BANKS=1
>>   CONFIG_ARCH_MTMIPS=y
>>   CONFIG_BOARD_VOCORE2=y
>> +CONFIG_BOOT_ROM=y
>> +CONFIG_ONBOARD_DDR2_SIZE_1024MBIT=y
>> +CONFIG_ONBOARD_DDR2_CHIP_WIDTH_16BIT=y
>>   CONFIG_MIPS_BOOT_FDT=y
>>   CONFIG_ENV_VARS_UBOOT_CONFIG=y
>>   CONFIG_SYS_BOOT_GET_CMDLINE=y
>> ... in a way that's very similar to boards based on the same SoC
>> (linkit-smart-7688 and gardena-smart-gateway-mt7688).
>>
>> In the ancient u-boot I had to remove a header from the RAM
>> version, but this was not needed with current u-boot.
>>
>> Did I forget some step?
>
> Did you never program U-Boot into SPI NOR before on your VoCore2? 
Yes.
Up to now I've been using the RAM-version and loaded it from my old
(paleolithic 1.1.3) vendor-provided u-boot.
Note: I have modified and reflashed *that* u-boot several times, so I
was kind of confident I could do without much problem.
Of course it's fully possible some initialization done by old code is
missing in the new one.

> Which binary did you program? 
I flashed "u-boot.bin" which looks like a copy of "u-boot-dtb.bin";
this is exactly the same file I used for my RAM-based tests
(after switching _defconfig and recompiling, of course).

> How do the fist line look like? Here my output:
>
> $ hexdump -n 256 u-boot.bin
> 000 013f 1000 4800 4080    
> 010        
> *
> 100
Mine is quite similar:
$ hexdump -n 256 u-boot.bin
000 013f 1000 4800 4080    
010        
*
100

I'm about to go where there's a nailbed to reflash SPI NOR
"from outside"; I plan to read back what's on flash before
putting back the "old" u-boot to see if something went wrong
while flashing (but I doubt it).

Problem is how to proceed.
Old code did a lot of hard-coded initialization (non-DT-based)
which I don't (explicitly) do here (including a long RAM calibration
I didn't even try to understand).
I will bring back a certain number of working modules, so I will
have a certain number of "tries" before I need to go back for
hard reflashing; I should try to minimize commuting ;)

> Thanks,
> Stefan
Many Thanks
Mauro
// SPDX-License-Identifier: GPL-2.0
#include 
#include 

/ {
#address-cells = <1>;
#size-cells = <1>;
compatible = "ralink,mt7628a-soc";

cpus {
#address-cells = <1>;
#size-cells = <0>;

cpu@0 {
compat

How to debug HW startup?

[Mauro Condarelli]

I managed to brick my target.

Situation:
I have a board with a paleolithic (1.1.3) version of u-boot.
I had been testing by loading in ram from USB:
    usb reset; fatload usb 0 8001 u-boot.bin; go 8001
and everything was ok.
I changed a few settings (both defconfigs are attached below)
and tried "the real thing"
Unfortunately reflashing the actual boot produced a brick.
It does not utter a single byte.

I will have to reflash the original using an external apparatus
(which I don't have here, so I'll have to take target to another
location, probably tomorrow morning), but question is:
how do I debug such a situation?
What could I have done so wrong?

As You can see I changed only a few settings:

--- configs/vocore_vocore2-ram_defconfig    2020-01-09
16:11:12.568096050 +0100
+++ configs/vocore_vocore2_defconfig    2020-01-09 16:07:10.528267378 +0100
@@ -1,9 +1,12 @@
 CONFIG_MIPS=y
-CONFIG_SYS_TEXT_BASE=0x8001
+CONFIG_SYS_TEXT_BASE=0x9c00
 CONFIG_ENV_SIZE=0x1000
 CONFIG_NR_DRAM_BANKS=1
 CONFIG_ARCH_MTMIPS=y
 CONFIG_BOARD_VOCORE2=y
+CONFIG_BOOT_ROM=y
+CONFIG_ONBOARD_DDR2_SIZE_1024MBIT=y
+CONFIG_ONBOARD_DDR2_CHIP_WIDTH_16BIT=y
 CONFIG_MIPS_BOOT_FDT=y
 CONFIG_ENV_VARS_UBOOT_CONFIG=y
 CONFIG_SYS_BOOT_GET_CMDLINE=y
... in a way that's very similar to boards based on the same SoC
(linkit-smart-7688 and gardena-smart-gateway-mt7688).

In the ancient u-boot I had to remove a header from the RAM
version, but this was not needed with current u-boot.

Did I forget some step?

Any hint welcome
Thanks in advance
Mauro

CONFIG_MIPS=y
CONFIG_SYS_TEXT_BASE=0x9c00
CONFIG_ENV_SIZE=0x1000
CONFIG_NR_DRAM_BANKS=1
CONFIG_ARCH_MTMIPS=y
CONFIG_BOARD_VOCORE2=y
CONFIG_BOOT_ROM=y
CONFIG_ONBOARD_DDR2_SIZE_1024MBIT=y
CONFIG_ONBOARD_DDR2_CHIP_WIDTH_16BIT=y
CONFIG_MIPS_BOOT_FDT=y
CONFIG_ENV_VARS_UBOOT_CONFIG=y
CONFIG_SYS_BOOT_GET_CMDLINE=y
CONFIG_SYS_BOOT_GET_KBD=y
# CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
CONFIG_USE_BOOTARGS=y
CONFIG_LOGLEVEL=8
CONFIG_VERSION_VARIABLE=y
CONFIG_DISPLAY_BOARDINFO_LATE=y
# CONFIG_AUTOBOOT is not set
# CONFIG_BOOTM_NETBSD is not set
# CONFIG_BOOTM_PLAN9 is not set
# CONFIG_BOOTM_RTEMS is not set
# CONFIG_BOOTM_VXWORKS is not set
# CONFIG_CMD_XIMG is not set
CONFIG_CMD_MEMINFO=y
CONFIG_CMD_GPIO=y
CONFIG_RANDOM_UUID=y
# CONFIG_CMD_LOADB is not set
# CONFIG_CMD_LOADS is not set
CONFIG_CMD_MMC=y
CONFIG_CMD_MTD=y
CONFIG_CMD_PART=y
CONFIG_CMD_SPI=y
CONFIG_CMD_USB=y
CONFIG_CMD_WDT=y
CONFIG_CMD_FAT=y
CONFIG_CMD_FS_GENERIC=y
CONFIG_CMD_MTDPARTS=y
CONFIG_MTDIDS_DEFAULT="nor0=spi0.0"
CONFIG_MTDPARTS_DEFAULT="spi0.0:320k(u-boot),2752k(kernel),13304k(filesystem),4k(env),-(factory)"
# CONFIG_ISO_PARTITION is not set
CONFIG_DEFAULT_DEVICE_TREE="vocore_vocore2"
CONFIG_ENV_IS_IN_FAT=y
CONFIG_ENV_FAT_INTERFACE="mmc"
CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
# CONFIG_NET is not set
# CONFIG_DM_DEVICE_REMOVE is not set
# CONFIG_INPUT is not set
CONFIG_LED=y
CONFIG_LED_BLINK=y
CONFIG_LED_GPIO=y
CONFIG_MMC=y
CONFIG_DM_MMC=y
# CONFIG_MMC_HW_PARTITIONING is not set
CONFIG_MMC_MTK=y
CONFIG_MTD=y
CONFIG_SPI_FLASH_SFDP_SUPPORT=y
CONFIG_SPI_FLASH_GIGADEVICE=y
CONFIG_SPI_FLASH_MTD=y
# CONFIG_DM_ETH is not set
# CONFIG_RAM_ROCKCHIP_DEBUG is not set
CONFIG_SPECIFY_CONSOLE_INDEX=y
CONFIG_CONS_INDEX=3
CONFIG_SPI=y
CONFIG_MT7621_SPI=y
CONFIG_SYSRESET_SYSCON=y
CONFIG_USB=y
CONFIG_DM_USB=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_GENERIC=y
CONFIG_USB_STORAGE=y
CONFIG_WDT=y
CONFIG_WDT_MT7621=y
CONFIG_LZMA=y
CONFIG_LZO=y
CONFIG_MIPS=y
CONFIG_SYS_TEXT_BASE=0x8001
CONFIG_ENV_SIZE=0x1000
CONFIG_NR_DRAM_BANKS=1
CONFIG_ARCH_MTMIPS=y
CONFIG_BOARD_VOCORE2=y
CONFIG_MIPS_BOOT_FDT=y
CONFIG_ENV_VARS_UBOOT_CONFIG=y
CONFIG_SYS_BOOT_GET_CMDLINE=y
CONFIG_SYS_BOOT_GET_KBD=y
# CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
CONFIG_USE_BOOTARGS=y
CONFIG_LOGLEVEL=8
CONFIG_VERSION_VARIABLE=y
CONFIG_DISPLAY_BOARDINFO_LATE=y
# CONFIG_AUTOBOOT is not set
# CONFIG_BOOTM_NETBSD is not set
# CONFIG_BOOTM_PLAN9 is not set
# CONFIG_BOOTM_RTEMS is not set
# CONFIG_BOOTM_VXWORKS is not set
# CONFIG_CMD_XIMG is not set
CONFIG_CMD_MEMINFO=y
CONFIG_CMD_GPIO=y
CONFIG_RANDOM_UUID=y
# CONFIG_CMD_LOADB is not set
# CONFIG_CMD_LOADS is not set
CONFIG_CMD_MMC=y
CONFIG_CMD_MTD=y
CONFIG_CMD_PART=y
CONFIG_CMD_SPI=y
CONFIG_CMD_USB=y
CONFIG_CMD_WDT=y
CONFIG_CMD_FAT=y
CONFIG_CMD_FS_GENERIC=y
CONFIG_CMD_MTDPARTS=y
CONFIG_MTDIDS_DEFAULT="nor0=spi0.0"
CONFIG_MTDPARTS_DEFAULT="spi0.0:320k(u-boot),2752k(kernel),13304k(filesystem),4k(env),-(factory)"
# CONFIG_ISO_PARTITION is not set
CONFIG_DEFAULT_DEVICE_TREE="vocore_vocore2"
CONFIG_ENV_IS_IN_FAT=y
CONFIG_ENV_FAT_INTERFACE="mmc"
CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
# CONFIG_NET is not set
# CONFIG_DM_DEVICE_REMOVE is not set
# CONFIG_INPUT is not set
CONFIG_LED=y
CONFIG_LED_BLINK=y
CONFIG_LED_GPIO=y
CONFIG_MMC=y
CONFIG_DM_MMC=y
# CONFIG_MMC_HW_PARTITIONING is not set
CONFIG_MMC_MTK=y
CONFIG_MTD=y
CONFIG_SPI_FLASH_SFDP_SUPPORT=y
CONFIG_SPI_FLASH_GIGADEVICE=y
CONFIG_SPI_FLASH_MTD=y
# CONFIG_DM_ETH is not set
# 

Re: [PATCH v2 2/2] Port to new board "VoCore2"

[Mauro Condarelli]

Thanks Daniel.

On 1/7/20 4:58 PM, Daniel Schwierzeck wrote:
> On Tue, Jan 7, 2020 at 3:30 PM Mauro Condarelli  wrote:
> ...
>> I also have problems with entropy pool in Linux, do you happen to know
>> if (and how) MT7628 supports HWRNG?
> what problems exactly?
Currently it takes a LOT of time to fill-up the entropy pool
(over half an hour) and on first startup, when it has to
generate ssh keys and other stuff system is virtually dead
for that long.
>
> On a embedded device you usually can only add randomness from
> interrupts sources to the entropy pool
> due to lack of disk or input devices. On a router the most interrupts
> are typically generated by drivers
> for ethernet and SPI/NAND/MMC controllers. You could use user-space
> daemons like haveged [1]
> to add more randomness from hardware events.
I tried that and it helps.
I also found *traces* pointing in the direction of hardware
support for RNG in my SoC; I have ca opy of the (badly
incomplete) "MT7628 PROGRAMMING GUIDE" and it
reports in "PWM1 Control register" an "interesting" field:
RESV1 Select Random Generator mode.
This males a lot of sense because this SoC is meant to implement
Wireless routers, so crypto and random acceleration would
be very useful.
Unfortunately I don't have more precise information, hence
the question.

> Also have a look at the documentation in Linux's drivers/char/random.c
> for more information, especially
> the paragraph "Ensuring unpredictability at system startup".
>
> PS: In my day job (embedded router devices) I use a hash like SHA256
> over the U-Boot MTD partition
> where also some device specific information like MAC addresses and
> serial numbers are stored to generate
> the initial seed for the entropy pool on first boot. Afterwards I
> manage the random seed over reboots as
> described in drivers/char/random.c.
>
> [1] https://linux.die.net/man/8/haveged
>

Re: [PATCH v2 2/2] Port to new board "VoCore2"

[Mauro Condarelli]

On 1/7/20 2:21 PM, Stefan Roese wrote:
> Hi Mauro,
>
> On 27.12.19 14:25, Mauro Condarelli wrote:
>> Small patch series to add support for VoCore/VoCore2 board.
>>
>> VoCore is open hardware and runs OpenWrt/LEDE.
>> It has WIFI, USB, UART, 20+ GPIOs but is only one inch square.
>> It will help you to make a smart house, study embedded system
>> or even make the tiniest router in the world.
>>
>> Details about this SoM can be found at "https://vocore.io/v2.html;.
>>
>> Signed-off-by: Mauro Condarelli 
>> ---
>>
>> Changes in v2:
>> - Removed some dead code
>> - Changed Author to my full name (no nick)
>> - Removed unwanted fixup to .dts generation (not my call).
>> - Fixed commit message
>> - Fixed various variables/filenames to include Vendor name
>> - Changed Vendor name (Vonger -> Vocore)
>>
>>   MAINTAINERS  |  1 +
>>   arch/mips/dts/Makefile   |  1 +
>>   arch/mips/dts/vocore_vocore2.dts | 62 
>>   arch/mips/mach-mtmips/Kconfig    |  9 +
>>   board/vocore/vocore2/Kconfig | 11 ++
>>   board/vocore/vocore2/Makefile    |  2 ++
>>   board/vocore/vocore2/board.c | 35 ++
>>   configs/vocore2_defconfig    | 62 
>>   include/configs/vocore2.h    | 50 ++
>>   9 files changed, 233 insertions(+)
>>   create mode 100644 arch/mips/dts/vocore_vocore2.dts
>>   create mode 100644 board/vocore/vocore2/Kconfig
>>   create mode 100644 board/vocore/vocore2/Makefile
>>   create mode 100644 board/vocore/vocore2/board.c
>>   create mode 100644 configs/vocore2_defconfig
>>   create mode 100644 include/configs/vocore2.h
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 8d588b7d64..8c15deaafe 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -1,3 +1,4 @@
>> +source /home/mcon/.basheditor/remote-debugging-v1.sh localhost 3
>> #BASHEDITOR-TMP-REMOTE-DEBUGGING-END|Origin line:
>>   Descriptions of section entries:
>>     P: Person (obsolete)
>> diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
>> index c9d75596f2..5ece224511 100644
>> --- a/arch/mips/dts/Makefile
>> +++ b/arch/mips/dts/Makefile
>> @@ -22,6 +22,7 @@ dtb-$(CONFIG_BOARD_NETGEAR_DGND3700V2) +=
>> netgear,dgnd3700v2.dtb
>>   dtb-$(CONFIG_BOARD_SAGEM_FAST1704) += sagem,f...@st1704.dtb
>>   dtb-$(CONFIG_BOARD_SFR_NB4_SER) += sfr,nb4-ser.dtb
>>   dtb-$(CONFIG_BOARD_TPLINK_WDR4300) += tplink_wdr4300.dtb
>> +dtb-$(CONFIG_BOARD_VOCORE2) += vocore_vocore2.dtb
>>   dtb-$(CONFIG_TARGET_JZ4780_CI20) += ci20.dtb
>>   dtb-$(CONFIG_SOC_LUTON) += luton_pcb090.dtb luton_pcb091.dtb
>>   dtb-$(CONFIG_SOC_OCELOT) += ocelot_pcb120.dtb ocelot_pcb123.dtb
>> diff --git a/arch/mips/dts/vocore_vocore2.dts
>> b/arch/mips/dts/vocore_vocore2.dts
>> new file mode 100644
>> index 00..cdcd9b4e1d
>> --- /dev/null
>> +++ b/arch/mips/dts/vocore_vocore2.dts
>> @@ -0,0 +1,62 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * Copyright (C) 2019 Mauro Condarelli 
>> + */
>> +
>> +/dts-v1/;
>> +#include "mt7628a.dtsi"
>> +
>> +/ {
>> +    compatible = "vocore,vocore2", "ralink,mt7628a-soc";
>> +    model = "VoCore2";
>> +
>> +    aliases {
>> +    serial0 = 
>> +    spi0 = 
>> +    };
>> +
>> +    memory@0 {
>> +    device_type = "memory";
>> +    reg = <0x0 0x0800>;
>> +    };
>> +
>> +    chosen {
>> +    bootargs = "console=ttyS2,115200";
>> +    stdout-path = 
>> +    };
>> +};
>> +
>> + {
>> +    state_default: pin_state {
>> +    p0led {
>> +    groups = "p0led_a";
>> +    function = "led";
>> +    };
>> +    };
>> +};
>> +
>> + {
>> +    status = "okay";
>> +};
>> +
>> + {
>> +    status = "okay";
>> +    nor0: m25p80@0 {
>> +    #address-cells = <1>;
>> +    #size-cells = <1>;
>> +    compatible = "m25p80";
>> +    spi-max-frequency = <1000>;
>> +    reg = <0x0>;
>> +    m25p,chunked-io = <32>;
>
> Do you need these m25p properties? Does not the generic version
> work for you like in the linkit:
>
>     spi-flash@0 {
>     #address-cells = &

Re: SPI NOR stops working if I put Env in MMC

[Mauro Condarelli]

Answering my own question (with some help from IRC):
It turns out it will be needed to issue "sf probe" to initialize
SPI Flash subsystem.
This is not a problem... if you know you need it.

Is there a reason (that I cannot, at moment, see) or would be
better to call `spi_flash_probe_bus_cs(CONFIG_SF_DEFAULT_BUS,
CONFIG_SF_DEFAULT_CS, CONFIG_SF_DEFAULT_SPEED,
CONFIG_SF_DEFAULT_MODE, );` behind the scenes if
user tries to access MTD?

Should I submit a patch for this?

TiA
Mauro

On 1/4/20 2:19 AM, Mauro Condarelli wrote:
> Hi,
> I'm facing a strange problem that took quite a while to analyze.
>
> I'm porting U-Boot to a new board and thus some problem is expected.
> I am also trying to configure U-Boot in a useful (for my purposes) way.
>
> I decided to switch Environment storage from SPI NOR to SD card (in a
> file in FAT partition.
>
> Before switch I had both SPI NOR (MTD) and MMC working.
>
>> U-Boot 2020.01-rc5-00074-g57fe7de5a3-dirty (Jan 04 2020 - 01:38:21 +0100)
>>
>> CPU:   MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr)
>> Model: VoCore2
>> DRAM:  128 MiB
>> MMC:   mmc@1013: 0
>> Loading Environment from SPI Flash... SF: Detected gd25q128 with page
>> size 256 Bytes, erase size 4 KiB, total 16 MiB
>> OK
>> In:    uart2@e00
>> Out:   uart2@e00
>> Err:   uart2@e00
>> Model: VoCore2
>> => mtd list
>> List of MTD devices:
>> * nor0
>>   - type: NOR flash
>>   - block size: 0x1000 bytes
>>   - min I/O: 0x1 bytes
>>   - 0x-0x0100 : "nor0"
>>       - 0x-0x0005 : "u-boot"
>>       - 0x0005-0x0030 : "kernel"
>>       - 0x0030-0x00ffe000 : "squash"
>>       - 0x00ffe000-0x00fff000 : "env"
>>       - 0x00fff000-0x0100 : "factory"
>> => mmc part
>>
>> Partition Map for MMC device 0  --   Partition Type: DOS
>>
>> Part    Start Sector    Num Sectors    UUID        Type
>>   1    2048      262144        f31c8249-01    0c
>>   2    264192        4194304       f31c8249-02    83
>>   3    4458496       327680        f31c8249-03    83
>>   4    4786176       10737664      f31c8249-04    05 Extd
>>   5    4788224       2097152       f31c8249-05    83
>>   6    6887424       2097152       f31c8249-06    83
>> =>
> I made a minimal change in configuration:
>
>> mcon@cinderella:/tmp/u-boot$ git diff
>> diff --git a/configs/vocore_vocore2_defconfig
>> b/configs/vocore_vocore2_defconfig
>> index ad1b580431..ece98beea0 100644
>> --- a/configs/vocore_vocore2_defconfig
>> +++ b/configs/vocore_vocore2_defconfig
>> @@ -1,8 +1,6 @@
>>  CONFIG_MIPS=y
>>  CONFIG_SYS_TEXT_BASE=0x8001
>>  CONFIG_ENV_SIZE=0x1000
>> -CONFIG_ENV_OFFSET=0x00FFE000
>> -CONFIG_ENV_SECT_SIZE=0x1000
>>  CONFIG_ARCH_MTMIPS=y
>>  CONFIG_BOARD_VOCORE2=y
>>  CONFIG_MIPS_BOOT_FDT=y
>> @@ -37,8 +35,9 @@ CONFIG_MTDIDS_DEFAULT="nor0=spi0.0"
>>  
>> CONFIG_MTDPARTS_DEFAULT="spi0.0:320k(u-boot),2752k(kernel),13304k(filesystem),4k(env),-(factory)"
>>  # CONFIG_ISO_PARTITION is not set
>>  CONFIG_DEFAULT_DEVICE_TREE="vocore_vocore2"
>> -CONFIG_ENV_IS_IN_SPI_FLASH=y
>> -CONFIG_ENV_ADDR=0x00FFE000
>> +CONFIG_ENV_IS_IN_FAT=y
>> +CONFIG_ENV_FAT_INTERFACE="mmc"
>> +CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
>>  # CONFIG_NET is not set
>>  # CONFIG_DM_DEVICE_REMOVE is not set
>>  CONFIG_BLK=y
>> mcon@cinderella:/tmp/u-boot$
> ... but it seems very destructive for spi:
>> U-Boot 2020.01-rc5-00074-g0cac9383d7-dirty (Jan 04 2020 - 01:55:34 +0100)
>>
>> CPU:   MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr)
>> Model: VoCore2
>> DRAM:  128 MiB
>> MMC:   mmc@1013: 0
>> Loading Environment from FAT... OK
>> In:    uart2@e00
>> Out:   uart2@e00
>> Err:   uart2@e00
>> Model: VoCore2
>> => mmc part
>>
>> Partition Map for MMC device 0  --   Partition Type: DOS
>>
>> Part    Start Sector    Num Sectors    UUID        Type
>>   1    2048      262144        f31c8249-01    0c
>>   2    264192        4194304       f31c8249-02    83
>>   3    4458496       327680        f31c8249-03    83
>>   4    4786176       10737664      f31c8249-04    05 Extd
>>   5    4788224       2097152       f31c8249-05    83
>>   6    6887424       2097152       f31c8249-06    83
>> => mtd list
>> Could not find a valid device for spi0.0
>> List of MTD devices:
>> No MTD device found
>> =>
> I assume some initialization is not done, but I would like some help to
> debug this as I did *not* change anything in SPI (aside from setting it
> in .dts).
> OTOH I had to change a bit MMC handling, but that shouldn't be relevant,
> or is it?
> I attach my complete patch against a fairly recent commit (it was "master"
> a few hours ago). The patch is to the working ENV_IS_IN_SPI_FLASH version.
> Changes for "not working" with ENV_IS_IN_FAT are above.
>
> Please advise.
> Thanks in Advance
> Mauro
>
>
>

Re: [U-Boot] [PATCH 11/26] dts: mtmips: update reset controller node for mt7628

[Mauro Condarelli]

On 1/2/20 1:30 PM, Stefan Roese wrote:
> Hi Mauro,
>
> On 30.12.19 13:14, Mauro Condarelli wrote:
>>
>>
>> On 12/30/19 11:22 AM, Daniel Schwierzeck wrote:
>>>
>>> Am 30.12.19 um 10:19 schrieb Mauro Condarelli:
>>>> I am having problems with this patch.
>>>>
>>>> Problem is "reset"command fails (for my board) with:
>>>>> => reset
>>>>> resetting ...
>>>>> ### ERROR ### Please RESET the board ###
>>>> I traced down problem to "drivers/sysreset/sysreset-uclass.c"
>>>> requesting
>>>> "uclass_first_device(UCLASS_SYSRESET, )", while
>>>> "drivers/reset/reset-mips.c"
>>>> defines:
>>>>> static const struct udevice_id mtmips_reset_ids[] = {
>>>>>      { .compatible = "mediatek,mtmips-reset" },
>>>>>      { }
>>>>> };
>>>>>
>>>>> U_BOOT_DRIVER(mtmips_reset) = {
>>>>>      .name = "mtmips-reset",
>>>>>      .id = UCLASS_RESET,
>>>> ... so UCLASS_SYSRESET list is empty.
>>>>
>>>> What am I doing wrong?
>>>> TiA!
>>>> Mauro
>>>>
>>> do you have the according node with compatible string
>>> "mediatek,mtmips-reset" in your device-tree?
>> Yes, I do, but problem is elsewhere:
>> "reset" command looks for a UCLASS_SYSRESET while
>> drivers/reset/reset-mips.c
>> (implementing "mediatek,mtmips-reset") provides a UCLASS_RESET.
>>
>> I know too little about u-boot internals to understand which one I
>> should "fix" (if any).
>
> I just tested current mainline U-Boot (top-of-tree) on the GARDENA
> board and the reset works just fine:
>
> => reset
> resetting ...
>
>
> U-Boot 2020.01-rc5-00042-g6cb87cbb14 (Jan 02 2020 - 13:27:15 +0100)
>
> CPU:   MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr)
> Model: GARDENA smart Gateway (MT7688)
> DRAM:  128 MiB
> WDT:   Started with servicing (60s timeout)
> Loading Environment from SPI Flash... SF: Detected XM25QH64A with page
> size 256 Bytes, erase size 4 KiB, total 8 MiB
> OK
> F-Data:factory-data version 1 detected
> Net:   eth0: eth@1011
> Hit any key to stop autoboot:  0
>
> I didn't check the details of this mail thread, so I can't really
> comment on this. Your board is so similar to the GARDENA one (LinkIt)
> that it should work there as well. Do you gave some differences in
> your defconfig?
My defconfig looks very different, mainly due to not having (currently)
any network in u-boot, but I have USB strorage.
I attach the whole vocore2_defconfig.
To me it seems the only difference that *might* be relevant is I don't
have CONFIG_SYSRESET_SYSCON=y.
... enable... compile... load... test...
SUCCESS!!
That was it.
I was thinking reset should have been handled by "reset-mtmips.c"  but
apparently "mfd syscon reboot driver" is needed.
THANKS.
I'll send another iteration of my patches soon after a bit of testing.
> Thanks,
> Stefan
>
Regards
Mauro

CONFIG_MIPS=y
CONFIG_SYS_TEXT_BASE=0x8001
CONFIG_ENV_SIZE=0x1000
CONFIG_ENV_OFFSET=0x00FFE000
CONFIG_ENV_SECT_SIZE=0x1000
CONFIG_ARCH_MTMIPS=y
CONFIG_BOARD_VOCORE2=y
CONFIG_MIPS_BOOT_FDT=y
CONFIG_ENV_VARS_UBOOT_CONFIG=y
CONFIG_SYS_BOOT_GET_CMDLINE=y
CONFIG_SYS_BOOT_GET_KBD=y
# CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
CONFIG_USE_BOOTARGS=y
CONFIG_LOGLEVEL=8
CONFIG_VERSION_VARIABLE=y
CONFIG_DISPLAY_BOARDINFO_LATE=y
# CONFIG_AUTOBOOT is not set
# CONFIG_BOOTM_NETBSD is not set
# CONFIG_BOOTM_PLAN9 is not set
# CONFIG_BOOTM_RTEMS is not set
# CONFIG_BOOTM_VXWORKS is not set
# CONFIG_CMD_XIMG is not set
CONFIG_RANDOM_UUID=y
# CONFIG_CMD_LOADB is not set
# CONFIG_CMD_LOADS is not set
CONFIG_CMD_MMC=y
CONFIG_CMD_MTD=y
CONFIG_CMD_PART=y
CONFIG_CMD_SPI=y
CONFIG_CMD_USB=y
CONFIG_CMD_FAT=y
CONFIG_CMD_FS_GENERIC=y
CONFIG_CMD_MTDPARTS=y
CONFIG_MTDIDS_DEFAULT="nor0=spi0.0"
CONFIG_MTDPARTS_DEFAULT="spi0.0:320k(u-boot),2752k(kernel),13304k(filesystem),4k(env),-(factory)"
# CONFIG_ISO_PARTITION is not set
CONFIG_DEFAULT_DEVICE_TREE="vocore_vocore2"
CONFIG_ENV_IS_IN_SPI_FLASH=y
CONFIG_ENV_ADDR=0x00FFE000
# CONFIG_NET is not set
# CONFIG_DM_DEVICE_REMOVE is not set
# CONFIG_INPUT is not set
CONFIG_LED=y
CONFIG_LED_BLINK=y
CONFIG_LED_GPIO=y
CONFIG_MMC=y
CONFIG_DM_MMC=y
# CONFIG_MMC_HW_PARTITIONING is not set
CONFIG_MMC_MTK=y
CONFIG_MTD=y
CONFIG_SPI_FLASH_SFDP_SUPPORT=y
CONFIG_SPI_FLASH_GIGADEVICE=y
CONFIG_SPI_FLASH_MTD=y
# CONFIG_DM_ETH is not set
# CONFIG_RAM_ROCKCHIP_DEBUG is not set
CONFIG_SPECIFY_CONSOLE_INDEX=y
CONFIG_CONS_INDEX=3
CONFIG_SPI=y
CONFIG_MT7621_SPI=y
CONFIG_USB=y
CONFIG_DM_USB=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_GENERIC=y
CONFIG_USB_STORAGE=y
CONFIG_LZMA=y
CONFIG_LZO=y

SPI NOR stops working if I put Env in MMC

[Mauro Condarelli]

Hi,
I'm facing a strange problem that took quite a while to analyze.

I'm porting U-Boot to a new board and thus some problem is expected.
I am also trying to configure U-Boot in a useful (for my purposes) way.

I decided to switch Environment storage from SPI NOR to SD card (in a
file in FAT partition.

Before switch I had both SPI NOR (MTD) and MMC working.

> U-Boot 2020.01-rc5-00074-g57fe7de5a3-dirty (Jan 04 2020 - 01:38:21 +0100)
>
> CPU:   MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr)
> Model: VoCore2
> DRAM:  128 MiB
> MMC:   mmc@1013: 0
> Loading Environment from SPI Flash... SF: Detected gd25q128 with page
> size 256 Bytes, erase size 4 KiB, total 16 MiB
> OK
> In:    uart2@e00
> Out:   uart2@e00
> Err:   uart2@e00
> Model: VoCore2
> => mtd list
> List of MTD devices:
> * nor0
>   - type: NOR flash
>   - block size: 0x1000 bytes
>   - min I/O: 0x1 bytes
>   - 0x-0x0100 : "nor0"
>       - 0x-0x0005 : "u-boot"
>       - 0x0005-0x0030 : "kernel"
>       - 0x0030-0x00ffe000 : "squash"
>       - 0x00ffe000-0x00fff000 : "env"
>       - 0x00fff000-0x0100 : "factory"
> => mmc part
>
> Partition Map for MMC device 0  --   Partition Type: DOS
>
> Part    Start Sector    Num Sectors    UUID        Type
>   1    2048      262144        f31c8249-01    0c
>   2    264192        4194304       f31c8249-02    83
>   3    4458496       327680        f31c8249-03    83
>   4    4786176       10737664      f31c8249-04    05 Extd
>   5    4788224       2097152       f31c8249-05    83
>   6    6887424       2097152       f31c8249-06    83
> =>

I made a minimal change in configuration:

> mcon@cinderella:/tmp/u-boot$ git diff
> diff --git a/configs/vocore_vocore2_defconfig
> b/configs/vocore_vocore2_defconfig
> index ad1b580431..ece98beea0 100644
> --- a/configs/vocore_vocore2_defconfig
> +++ b/configs/vocore_vocore2_defconfig
> @@ -1,8 +1,6 @@
>  CONFIG_MIPS=y
>  CONFIG_SYS_TEXT_BASE=0x8001
>  CONFIG_ENV_SIZE=0x1000
> -CONFIG_ENV_OFFSET=0x00FFE000
> -CONFIG_ENV_SECT_SIZE=0x1000
>  CONFIG_ARCH_MTMIPS=y
>  CONFIG_BOARD_VOCORE2=y
>  CONFIG_MIPS_BOOT_FDT=y
> @@ -37,8 +35,9 @@ CONFIG_MTDIDS_DEFAULT="nor0=spi0.0"
>  
> CONFIG_MTDPARTS_DEFAULT="spi0.0:320k(u-boot),2752k(kernel),13304k(filesystem),4k(env),-(factory)"
>  # CONFIG_ISO_PARTITION is not set
>  CONFIG_DEFAULT_DEVICE_TREE="vocore_vocore2"
> -CONFIG_ENV_IS_IN_SPI_FLASH=y
> -CONFIG_ENV_ADDR=0x00FFE000
> +CONFIG_ENV_IS_IN_FAT=y
> +CONFIG_ENV_FAT_INTERFACE="mmc"
> +CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
>  # CONFIG_NET is not set
>  # CONFIG_DM_DEVICE_REMOVE is not set
>  CONFIG_BLK=y
> mcon@cinderella:/tmp/u-boot$

... but it seems very destructive for spi:
> U-Boot 2020.01-rc5-00074-g0cac9383d7-dirty (Jan 04 2020 - 01:55:34 +0100)
>
> CPU:   MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr)
> Model: VoCore2
> DRAM:  128 MiB
> MMC:   mmc@1013: 0
> Loading Environment from FAT... OK
> In:    uart2@e00
> Out:   uart2@e00
> Err:   uart2@e00
> Model: VoCore2
> => mmc part
>
> Partition Map for MMC device 0  --   Partition Type: DOS
>
> Part    Start Sector    Num Sectors    UUID        Type
>   1    2048      262144        f31c8249-01    0c
>   2    264192        4194304       f31c8249-02    83
>   3    4458496       327680        f31c8249-03    83
>   4    4786176       10737664      f31c8249-04    05 Extd
>   5    4788224       2097152       f31c8249-05    83
>   6    6887424       2097152       f31c8249-06    83
> => mtd list
> Could not find a valid device for spi0.0
> List of MTD devices:
> No MTD device found
> =>
I assume some initialization is not done, but I would like some help to
debug this as I did *not* change anything in SPI (aside from setting it
in .dts).
OTOH I had to change a bit MMC handling, but that shouldn't be relevant,
or is it?
I attach my complete patch against a fairly recent commit (it was "master"
a few hours ago). The patch is to the working ENV_IS_IN_SPI_FLASH version.
Changes for "not working" with ENV_IS_IN_FAT are above.

Please advise.
Thanks in Advance
Mauro



>From 43e2aa1dd77221e10479a4352a50332942beeb38 Mon Sep 17 00:00:00 2001
From: Mauro Condarelli 
Date: Sat, 4 Jan 2020 00:31:54 +0100
Subject: [PATCH] Port to VoCore2 board.

Signed-off-by: Mauro Condarelli 
---
 arch/mips/dts/Makefile   |  1 +
 arch/mips/dts/mt7628a.dtsi   | 18 +-
 arch/mips/dts/vocore_vocore2.dts | 83 
 arch/mips/mach-mtmips/Kconfig|  9 +++
 board/vocore/

Facilities for successful boot detection

[Mauro Condarelli]

I would like to implement an update system (most likely using SWUpdate)
"Double copy with fall-back" and, possibly a "last resort" recovery.

I have pretty clear what should be the program flow, but I don't know
how to implement it in U-Boot.

In particular:

  * How can I determine, in U-Boot, if previous boot was successful?
  * Is there a established "best practice" for this?
  * I would like to avoid rewriting Environment at each reboot (it can
happen /many/ times/day and that would kill SPI NOR).
  * In U-Boot there's a BootCounter, but Ive been unable to understand
if/how it works and I strongly doubt it will be useful because it
stores the counter itself in a uController register that is cleared
on hard reset (and, of course, at power-up). Since my only way to
"recover" from a failed boot may well be power-cycle I suspect this
method is scarcely usable (but I might have missed something).
  * OTOH, as said, rewriting Environment (currently in SPI NOR) at each
boot doesn't seem advisable.

What I am aiming at (but I'm ready to change, if there's a better way) is:

  * my board (VoCore2 SoM) has:
  o 128MiB RAM
  o 16MiB SPI NOR (MTD)
  o 8GiB SD card (MMC)
  * On SD I should have:
  o One FAT-formatted partition containing two kernel images.
  o Two ext4 partitions containing RootFS (one for each kernel image).
  o Two ext4 partitions for Application (to be mounted on
/usr/local, if it matters).
  * On MTD1 I should have U-Boot.
  * MTD2 and MTD3 should contain a "recovery copy" of kernel and RootFS
(no Application).
  * U-Boot should have a notion of "current" and "known good" system and
should try booting "current" a few times; if it fails it should try
"known good"; if it still fails (e.g.: SD is completely broken) it
should boot from "recovery" on SPI NOR.

I've seen some `configs` (most notably theadorable-x86) seem to
implement something like this, but, sincerely, I've been unable to
divine what they're actually doing.

If someone could be so kind to point me in the right direction... ;)

Thanks in Advance

Mauro

Re: [U-Boot] [PATCH 11/26] dts: mtmips: update reset controller node for mt7628

[Mauro Condarelli]

On 12/30/19 11:22 AM, Daniel Schwierzeck wrote:
>
> Am 30.12.19 um 10:19 schrieb Mauro Condarelli:
>> I am having problems with this patch.
>>
>> Problem is "reset"command fails (for my board) with:
>>> => reset
>>> resetting ...
>>> ### ERROR ### Please RESET the board ###
>> I traced down problem to "drivers/sysreset/sysreset-uclass.c" requesting
>> "uclass_first_device(UCLASS_SYSRESET, )", while
>> "drivers/reset/reset-mips.c"
>> defines:
>>> static const struct udevice_id mtmips_reset_ids[] = {
>>>     { .compatible = "mediatek,mtmips-reset" },
>>>     { }
>>> };
>>>
>>> U_BOOT_DRIVER(mtmips_reset) = {
>>>     .name = "mtmips-reset",
>>>     .id = UCLASS_RESET,
>> ... so UCLASS_SYSRESET list is empty.
>>
>> What am I doing wrong?
>> TiA!
>> Mauro
>>
> do you have the according node with compatible string
> "mediatek,mtmips-reset" in your device-tree?
Yes, I do, but problem is elsewhere:
"reset" command looks for a UCLASS_SYSRESET while
drivers/reset/reset-mips.c
(implementing "mediatek,mtmips-reset") provides a UCLASS_RESET.

I know too little about u-boot internals to understand which one I
should "fix" (if any).

Thanks
Mauro

Re: [U-Boot] [PATCH 11/26] dts: mtmips: update reset controller node for mt7628

[Mauro Condarelli]

On 12/30/19 11:22 AM, Daniel Schwierzeck wrote:
>
> Am 30.12.19 um 10:19 schrieb Mauro Condarelli:
>> I am having problems with this patch.
>>
>> Problem is "reset"command fails (for my board) with:
>>> => reset
>>> resetting ...
>>> ### ERROR ### Please RESET the board ###
>> I traced down problem to "drivers/sysreset/sysreset-uclass.c" requesting
>> "uclass_first_device(UCLASS_SYSRESET, )", while
>> "drivers/reset/reset-mips.c"
>> defines:
>>> static const struct udevice_id mtmips_reset_ids[] = {
>>>     { .compatible = "mediatek,mtmips-reset" },
>>>     { }
>>> };
>>>
>>> U_BOOT_DRIVER(mtmips_reset) = {
>>>     .name = "mtmips-reset",
>>>     .id = UCLASS_RESET,
>> ... so UCLASS_SYSRESET list is empty.
>>
>> What am I doing wrong?
>> TiA!
>> Mauro
>>
> do you have the according node with compatible string
> "mediatek,mtmips-reset" in your device-tree?
I have the standard mt7628a.dtsi contents:

...
    palmbus@1000 {
        compatible = "palmbus", "simple-bus";
        reg = <0x1000 0x20>;
        ranges = <0x0 0x1000 0x1F>;
        ...
        rstctrl: rstctrl@0x34 {
            reg = <0x34 0x4>;
            compatible = "mediatek,mtmips-reset";
            #reset-cells = <1>;
        };
        ...

I tried adding the "old-style":
    ...
    resetc: reset-controller {
        compatible = "ralink,rt2880-reset";
        #reset-cells = <1>;
    };
    ...
but, apparently, it makes no difference.

Shouldn't that be enough?

TiA
MAuro

[U-Boot] [PATCH 11/26] dts: mtmips: update reset controller node for mt7628

[Mauro Condarelli]

I am having problems with this patch.

Problem is "reset"command fails (for my board) with:
> => reset
> resetting ...
> ### ERROR ### Please RESET the board ###
I traced down problem to "drivers/sysreset/sysreset-uclass.c" requesting
"uclass_first_device(UCLASS_SYSRESET, )", while
"drivers/reset/reset-mips.c"
defines:
> static const struct udevice_id mtmips_reset_ids[] = {
>     { .compatible = "mediatek,mtmips-reset" },
>     { }
> };
>
> U_BOOT_DRIVER(mtmips_reset) = {
>     .name = "mtmips-reset",
>     .id = UCLASS_RESET,
... so UCLASS_SYSRESET list is empty.

What am I doing wrong?
TiA!
Mauro

[PATCH v2 2/2] Port to new board "VoCore2"

[Mauro Condarelli]

Small patch series to add support for VoCore/VoCore2 board.

VoCore is open hardware and runs OpenWrt/LEDE.
It has WIFI, USB, UART, 20+ GPIOs but is only one inch square.
It will help you to make a smart house, study embedded system
or even make the tiniest router in the world.

Details about this SoM can be found at "https://vocore.io/v2.html;.

Signed-off-by: Mauro Condarelli 
---

Changes in v2:
- Removed some dead code
- Changed Author to my full name (no nick)
- Removed unwanted fixup to .dts generation (not my call).
- Fixed commit message
- Fixed various variables/filenames to include Vendor name
- Changed Vendor name (Vonger -> Vocore)

 MAINTAINERS  |  1 +
 arch/mips/dts/Makefile   |  1 +
 arch/mips/dts/vocore_vocore2.dts | 62 
 arch/mips/mach-mtmips/Kconfig|  9 +
 board/vocore/vocore2/Kconfig | 11 ++
 board/vocore/vocore2/Makefile|  2 ++
 board/vocore/vocore2/board.c | 35 ++
 configs/vocore2_defconfig| 62 
 include/configs/vocore2.h| 50 ++
 9 files changed, 233 insertions(+)
 create mode 100644 arch/mips/dts/vocore_vocore2.dts
 create mode 100644 board/vocore/vocore2/Kconfig
 create mode 100644 board/vocore/vocore2/Makefile
 create mode 100644 board/vocore/vocore2/board.c
 create mode 100644 configs/vocore2_defconfig
 create mode 100644 include/configs/vocore2.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 8d588b7d64..8c15deaafe 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1,3 +1,4 @@
+source /home/mcon/.basheditor/remote-debugging-v1.sh localhost 3 
#BASHEDITOR-TMP-REMOTE-DEBUGGING-END|Origin line:
 Descriptions of section entries:
 
P: Person (obsolete)
diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
index c9d75596f2..5ece224511 100644
--- a/arch/mips/dts/Makefile
+++ b/arch/mips/dts/Makefile
@@ -22,6 +22,7 @@ dtb-$(CONFIG_BOARD_NETGEAR_DGND3700V2) += 
netgear,dgnd3700v2.dtb
 dtb-$(CONFIG_BOARD_SAGEM_FAST1704) += sagem,f...@st1704.dtb
 dtb-$(CONFIG_BOARD_SFR_NB4_SER) += sfr,nb4-ser.dtb
 dtb-$(CONFIG_BOARD_TPLINK_WDR4300) += tplink_wdr4300.dtb
+dtb-$(CONFIG_BOARD_VOCORE2) += vocore_vocore2.dtb
 dtb-$(CONFIG_TARGET_JZ4780_CI20) += ci20.dtb
 dtb-$(CONFIG_SOC_LUTON) += luton_pcb090.dtb luton_pcb091.dtb
 dtb-$(CONFIG_SOC_OCELOT) += ocelot_pcb120.dtb ocelot_pcb123.dtb
diff --git a/arch/mips/dts/vocore_vocore2.dts b/arch/mips/dts/vocore_vocore2.dts
new file mode 100644
index 00..cdcd9b4e1d
--- /dev/null
+++ b/arch/mips/dts/vocore_vocore2.dts
@@ -0,0 +1,62 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Mauro Condarelli 
+ */
+
+/dts-v1/;
+#include "mt7628a.dtsi"
+
+/ {
+   compatible = "vocore,vocore2", "ralink,mt7628a-soc";
+   model = "VoCore2";
+
+   aliases {
+   serial0 = 
+   spi0 = 
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x0800>;
+   };
+
+   chosen {
+   bootargs = "console=ttyS2,115200";
+   stdout-path = 
+   };
+};
+
+ {
+   state_default: pin_state {
+   p0led {
+   groups = "p0led_a";
+   function = "led";
+   };
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+   nor0: m25p80@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "m25p80";
+   spi-max-frequency = <1000>;
+   reg = <0x0>;
+   m25p,chunked-io = <32>;
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_iot_mode>;
+   mediatek,poll-link-phy = <0>;
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/mips/mach-mtmips/Kconfig b/arch/mips/mach-mtmips/Kconfig
index c8dcf19c0d..57dfaebaec 100644
--- a/arch/mips/mach-mtmips/Kconfig
+++ b/arch/mips/mach-mtmips/Kconfig
@@ -43,6 +43,14 @@ config BOARD_LINKIT_SMART_7688
  ethernet ports, 1 USB port, 1 UART, GPIO buttons and LEDs, and
  a MT7688 (PCIe).
 
+config BOARD_VOCORE2
+   bool "VoCore2"
+   depends on SOC_MT7628
+   select SUPPORTS_BOOT_RAM
+   help
+ VoCore VoCore2 board has a MT7628 SoC with 128 MiB of RAM
+ and 16 MiB of flash (SPI).
+
 endchoice
 
 choice
@@ -134,5 +142,6 @@ config SUPPORTS_BOOT_RAM
 
 source "board/gardena/smart-gateway-mt7688/Kconfig"
 source "board/seeed/linkit-smart-7688/Kconfig"
+source "board/vocore/vocore2/Kconfig"
 
 endmenu
diff --git a/board/vocore/vocore2/Kconfig b/board/vocore/vocore2/Kconfig
new file mode 100644
index 00..9178c3ab32
--- /dev/null
+++ b/board/vocore/vocore2/Kconfig
@@

[PATCH v2 1/2] Add GigaDevice gd25q128 128Mbit chip to spi-nor id table.

[Mauro Condarelli]

From: MCon 

Tested on VoCore2

Signed-off-by: MCon 
Signed-off-by: Mauro Condarelli 
---

Changes in v2: None

 drivers/mtd/spi/spi-nor-ids.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index d3b84574ac..973b6f86c9 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -107,6 +107,11 @@ const struct flash_info spi_nor_ids[] = {
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
},
+   {
+   INFO("gd25q128", 0xc84018, 0, 64 * 1024, 256,
+   SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
+   SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
+   },
{
INFO("gd25lq128", 0xc86018, 0, 64 * 1024, 256,
SECT_4K | SPI_NOR_DUAL_READ |
-- 
2.24.1

Re: [PATCH 1/1] Port to new board "VoCore2"

[Mauro Condarelli]

On 12/20/19 4:35 AM, Daniel Schwierzeck wrote:
>
> Am 19.12.19 um 16:08 schrieb Stefan Roese:
>> Hi Mauro,
>>
>> On 19.12.19 12:40, MCon wrote:
>>> modified:   arch/mips/dts/Makefile
>>> Add support for creation of vocore2.dtb
>>> move creation of gardena-smart-gateway-mt7688.dtb and
>>>     linkit-smart-7688.dtb to more specific setting.
>>>
>>> new file:   arch/mips/dts/vocore2.dts
>>> modified:   arch/mips/mach-mtmips/Kconfig
>>> new file:   board/vonger/vocore2/Kconfig
>>> KConfig support for board VoCore2.
>>>
>>> new file:   board/vonger/vocore2/Makefile
>>> new file:   board/vonger/vocore2/board.c
>>> Board initialization (largely copied from existing).
>>>
>>> new file:   configs/vocore2_defconfig
>>> new file:   include/configs/vocore2.h
>>> Board settings (WIP).
>> This is a pretty uncommon commit text for a new board port. Please
>> don't add just a summary of which files are changed or added. Better
>> describe the newly added board with its supported (and perhaps not
>> yet supported) features. As an example, here the commit text for the
>> GARDENA board:
>>
>>     The Gardena Smart-Gateway boards have a MT7688 SoC with 128 MiB of RAM
>>     and 8 MiB of flash (SPI NOR) and additional 128MiB SPI NAND storage.
>>         This patch also includes 2 targets. One is the target that can be
>>     programmed into the SPI NOR flash and a 2nd target "xxx-ram" is
>>     added to support loading and booting via an already running U-Boot
>>     version. This allows easy development and testing without the
>>     need to flash the image each time.
>>
>> Just an example of course.
>>
>> Please find some further review comments below inline.
>>
>>> Signed-off-by: MCon 
>> Please use your name with the email address:
>>
>> Signed-off-by: Mauro Condarelli 
> yes, please also fix your Git config accordingly (git config [--global]
> user.email "Mauro Condarelli ").
Will do ASAP (probably right after Christmas).
Last thing is strange, though, because git should already be setup right.
I'll check.

>>> ---
>>>
>>>   arch/mips/dts/Makefile    |  6 ++--
>>>   arch/mips/dts/vocore2.dts | 62 +++
>>>   arch/mips/mach-mtmips/Kconfig |  9 +
>>>   board/vonger/vocore2/Kconfig  | 11 +++
>>>   board/vonger/vocore2/Makefile |  2 ++
>>>   board/vonger/vocore2/board.c  | 35 
>>>   configs/vocore2_defconfig | 61 ++
>>>   include/configs/vocore2.h | 57 
>>>   8 files changed, 240 insertions(+), 3 deletions(-)
>>>   create mode 100644 arch/mips/dts/vocore2.dts
>>>   create mode 100644 board/vonger/vocore2/Kconfig
>>>   create mode 100644 board/vonger/vocore2/Makefile
>>>   create mode 100644 board/vonger/vocore2/board.c
>>>   create mode 100644 configs/vocore2_defconfig
>>>   create mode 100644 include/configs/vocore2.h
>>>
>>> diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
>>> index c9d75596f2..664505ee00 100644
>>> --- a/arch/mips/dts/Makefile
>>> +++ b/arch/mips/dts/Makefile
>>> @@ -1,8 +1,5 @@
>>>   # SPDX-License-Identifier: GPL-2.0+
>>>   -dtb-$(CONFIG_ARCH_MTMIPS) += \
>>> -    gardena-smart-gateway-mt7688.dtb \
>>> -    linkit-smart-7688.dtb
>>>   dtb-$(CONFIG_TARGET_AP121) += ap121.dtb
>>>   dtb-$(CONFIG_TARGET_AP143) += ap143.dtb
>>>   dtb-$(CONFIG_TARGET_AP152) += ap152.dtb
>>> @@ -16,12 +13,15 @@ dtb-$(CONFIG_BOARD_COMTREND_AR5387UN) +=
>>> comtrend,ar-5387un.dtb
>>>   dtb-$(CONFIG_BOARD_COMTREND_CT5361) += comtrend,ct-5361.dtb
>>>   dtb-$(CONFIG_BOARD_COMTREND_VR3032U) += comtrend,vr-3032u.dtb
>>>   dtb-$(CONFIG_BOARD_COMTREND_WAP5813N) += comtrend,wap-5813n.dtb
>>> +dtb-$(CONFIG_BOARD_GARDENA_SMART_GATEWAY_MT7688) +=
>>> gardena-smart-gateway-mt7688.dtb
>>>   dtb-$(CONFIG_BOARD_HUAWEI_HG556A) += huawei,hg556a.dtb
>>> +dtb-$(CONFIG_BOARD_LINKIT._SMART_7688) += linkit-smart-7688.dtb
> this is an unrelated change and should be removed. I guess this was
> intentional by Stefan. If not, please submit a separate patch for that.
Right.
@Stefan: please, could You explain the rationale behind building
all DTBs? I failed to understand.

>>>   dtb-$(CONFIG_BOARD_NETGEAR_CG3100D) += netgear,cg3100d.dtb
>>>   dtb-$(CONFIG_BOARD_NETGEAR_DGND3700V2) +

mtk_sd on Vocore2 board

[Mauro Condarelli]

I am having trouble understanding how to handle SD driver on my Vocore2
board.

I already managed to make it work under Linux (5.3.0).
Root problem is VoCore2 has no support for power switching on the SD/MMC
slot;
a direct wire goes directly to the 3.3V supply.

Similar issue for the clock (here I needed a very ugly patch (below)).

Questions are twofold:
1) Is this really needed (on mainstream kernel) or did I miss some DT
setting that would have achieved the same effect?
2) How to achieve equivalent effect on U-Boot .../mtk_sd.c which looks
very different from the above?

If I do a "naive" porting SD will NOT work; any commands (e.g.: "mmc
info") results in error: "mmc_init: -95, time 6201"
(curiously always with the same "time") which I *think* I traced to
inability to handle voltage changes.

Any hint would be very welcome.

Regards and
Merry Christmas and very Happy New Year!
Mauro

=
>From 3d239054fd01fbeb03863eee7eefd2a76b82dc02 Mon Sep 17 00:00:00 2001
From: Mauro Condarelli 
Date: Wed, 18 Sep 2019 14:07:22 +0200
Subject: [PATCH 8/8] MIPS, MMC, VoCore2: Preliminary fix for mtk-sd

---
 arch/mips/boot/dts/ralink/mt7628a.dtsi | 37 ++
 arch/mips/boot/dts/ralink/vocore2.dts  |  4 +++
 arch/mips/ralink/clk.c |  2 +-
 drivers/mmc/host/mtk-sd.c  |  8 ++
 4 files changed, 50 insertions(+), 1 deletion(-)

diff --git a/arch/mips/boot/dts/ralink/mt7628a.dtsi
b/arch/mips/boot/dts/ralink/mt7628a.dtsi
index 376536489415..9636709edc5d 100644
--- a/arch/mips/boot/dts/ralink/mt7628a.dtsi
+++ b/arch/mips/boot/dts/ralink/mt7628a.dtsi
@@ -259,6 +259,43 @@
     reset-names = "host", "device";
 };
 
+    clk48m: clk48m@0 {
+        compatible = "fixed-clock";
+        clock-frequency = <4800>;
+        #clock-cells = <0>;
+    };
+
+    vmmcsd_fixed: fixedregulator@0 {
+        compatible = "regulator-fixed";
+        regulator-name = "vmmcsd_fixed";
+        regulator-min-microvolt = <330>;
+        regulator-max-microvolt = <330>;
+    };
+
+    mmc: mmc@1013 {
+        compatible = "mediatek,mt7620-mmc";
+        reg = <0x1013 0x4000>;
+        builtin-cd = <1>;
+        r_smpl = <1>;
+
+        interrupt-parent = <>;
+        interrupts = <14>;
+
+        clocks = <>, <>;
+        clock-names = "source", "hclk";
+
+        pinctrl-names = "default", "state_uhs";
+        pinctrl-0 = <_sdmode_sdxc>;
+        pinctrl-1 = <_sdmode_sdxc>;
+
+        vmmc-supply = <_fixed>;
+        vqmmc-supply = <_fixed>;
+
+        resets = < 30>;
+
+        status = "disabled";
+    };
+
 ehci@101c {
     compatible = "generic-ehci";
     reg = <0x101c 0x1000>;
diff --git a/arch/mips/boot/dts/ralink/vocore2.dts
b/arch/mips/boot/dts/ralink/vocore2.dts
index 559c4256d48a..19e8ece4aa2a 100644
--- a/arch/mips/boot/dts/ralink/vocore2.dts
+++ b/arch/mips/boot/dts/ralink/vocore2.dts
@@ -62,3 +62,7 @@
 status = "okay";
 mediatek,mtd-eeprom = < 0x>;
 };
+
+ {
+    status = "okay";
+};
diff --git a/arch/mips/ralink/clk.c b/arch/mips/ralink/clk.c
index 0e57845d7f9a..930c2776f6fd 100644
--- a/arch/mips/ralink/clk.c
+++ b/arch/mips/ralink/clk.c
@@ -90,4 +90,4 @@ struct clk *clk_get_parent(struct clk *clk)
 {
 return NULL;
 }
-EXPORT_SYMBOL(clk_get_parent);
+EXPORT_SYMBOL_GPL(clk_get_parent);
diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 33f4b6387ef7..13464161521c 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -721,18 +721,22 @@ static void msdc_set_timeout(struct msdc_host
*host, u32 ns, u32 clks)
 
 static void msdc_gate_clock(struct msdc_host *host)
 {
+#ifdef handle_clocks
 clk_disable_unprepare(host->src_clk_cg);
 clk_disable_unprepare(host->src_clk);
 clk_disable_unprepare(host->bus_clk);
 clk_disable_unprepare(host->h_clk);
+#endif//handle_clocks
 }
 
 static void msdc_ungate_clock(struct msdc_host *host)
 {
+#ifdef handle_clocks
 clk_prepare_enable(host->h_clk);
 clk_prepare_enable(host->bus_clk);
 clk_prepare_enable(host->src_clk);
 clk_prepare_enable(host->src_clk_cg);
+#endif//handle_clocks
 while (!(readl(host->base + MSDC_CFG) & MSDC_CFG_CKSTB))
     cpu_relax();
 }
@@ -2199,6 +2203,9 @@ static int msdc_drv_probe(struct platform_device
*pdev)
 if (ret)
     goto host_free;
 
+
+#ifdef handle_clocks
+#error "should NOT compile!"
 host->src_clk = devm_clk_get(>dev, "source");
 if (IS_ERR(host->src_clk)) {
     ret = PTR_ERR(host->src_clk);
@@ -2218,6 +2225,7 @@ static int msdc_drv_probe(struct platform_device
*pdev)
 host->src_clk_cg = devm_clk_get(>dev, "source_cg");
 if (IS_ERR(host->src_clk_cg))
     host->src_clk_cg = NULL;
+#endif //handle_clocks
 
 host->irq = platform_get_irq(pdev, 0);
 if (host->irq < 0) {
-- 
2.23.0

Re: [RFC] new board VoCore2

[Mauro Condarelli]

On 12/16/19 8:20 AM, Stefan Roese wrote:
> Hi Mauro,
>
> On 15.12.19 11:20, Mauro Condarelli wrote:
>> I am trying to extend support to a new board "VoCore2" whose specs can
>> be found here: https://vocore.io/v2.html
>
> Nice. Thanks for working on this.
>
>> Port is concerning the "ultimate" board which has all connectors in
>> place for SD, USB and Ethernet.
>> This board comes with a paleolithic (1.3.0) version of u-boot and I'm
>> trying to upgrade to a recent one
>> also because I need to implement "automatic upgrade" (possibly using
>> RAUC, but that is another story).
>>
>> Port is working and able to boot Linuz, but it is not ready for
>> inclusion for several reasons
>> and I would like to have expert advice on how to tackle shortcomings, as
>> advised by stefanro on IRC:
>>> 6:49:14 AM - stefanro: mcon: Please submit the patches directly to the
>>> list, with me (and other MIPS / MT7628/88 experts - Daniel etc) on Cc.
>>> If you feel the patches are not ready for integration, then you can
>>> mark them as "RFC" in the subject.
>>
>> Problematic areas I see (side from possible code style issues) are:
>> 1) I added support for a new SPI NOR Flash and that should, probably, be
>> a separate patch.
>
> Yes, please.
Done.

>> 2) I added support for SPI NOR partitioning and I'm unsure if that
>> should be in the "board definition".
>> 3) SPI NOR partitioning is actually duplicated in ENV var (mtdparts) and
>> in Device Tree; I didn't find how to read it directly from DT.
>
> When you pass the MTD partitioning via kernel cmdline "mtdparts=...",
> which can be generated by U-Boot, then there is no need for the DT
> partitioning.
If I understand You correctly this means to completely remove DT
partitioning
information and purely rely on "mtdparts" information.
I was unaware of this possibility.
I'll cross check.
Thanks.

>> 4) Board also has SD, handled via MTK_SD driver, but I've been unable to
>> make it work.
> Then I suggest to exclude it for now.
I strongly suspect the failure is due to complete inability of VoCore2
to handle
MMC/SD power (SD-VCC is hardwired to +3.3V, no way to hard reset SD card
other than complete power-down) and clock.
I had to patch kernel (5.3.0) mtk_sd.c to disable clock gating
(msdc_gate_clock(),
msdc_ungate_clock() and msdc_drv_probe(); a rather ugly patch I won't try to
send upstream; unfortunately u-boot mtk_sd.c looks very different I think
I'll need some help there...) and to add a "regulator-fixed" to DT, but
I'm unsure
if and how it is supported by u-boot.

I will exclude all this from current patch-set (but it is vital for my
project as I
will need to save Environment to MMC to enable boot-counters without
burning
the SPI NOR).

>> 5) Current binary is rather big and I would like to shrink it a bit, if
>> possible.
>>
>> Any hint/criticism/advice would be VERY welcome.
>
> The most important comment I have is, please post the patch inline, so
> that
> we can easily comment on it. Please also take a look at this page for
> hints
> about patch submission:
>
> http://www.denx.de/wiki/view/U-Boot/Patches
Reading it now.
I will reformat patches using a different branch and condensing them
into logically coherent lumps.
It will take some time.

> Thanks,
> Stefan
>
Regards
Mauro

[Patch] Add support for GD25Q128C SPI NOR chip

[Mauro Condarelli]

Trivial patch to add Support for GigaDevice GD25Q128C:

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index d3b84574ac..fbb7dca30c 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -107,6 +107,11 @@ const struct flash_info spi_nor_ids[] = {
    SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
    SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
    },
+   {
+   INFO("gd25q128", 0xc84018, 0, 64 * 1024, 256,
+   SECT_4K | SPI_NOR_DUAL_READ |
+   SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
+   },
    {
    INFO("gd25lq128", 0xc86018, 0, 64 * 1024, 256,
    SECT_4K | SPI_NOR_DUAL_READ |


Regards
Mauro Condarelli

[RFC] new board VoCore2

[Mauro Condarelli]

I am trying to extend support to a new board "VoCore2" whose specs can
be found here: https://vocore.io/v2.html
Port is concerning the "ultimate" board which has all connectors in
place for SD, USB and Ethernet.
This board comes with a paleolithic (1.3.0) version of u-boot and I'm
trying to upgrade to a recent one
also because I need to implement "automatic upgrade" (possibly using
RAUC, but that is another story).

Port is working and able to boot Linuz, but it is not ready for
inclusion for several reasons
and I would like to have expert advice on how to tackle shortcomings, as
advised by stefanro on IRC:
> 6:49:14 AM - stefanro: mcon: Please submit the patches directly to the
> list, with me (and other MIPS / MT7628/88 experts - Daniel etc) on Cc.
> If you feel the patches are not ready for integration, then you can
> mark them as "RFC" in the subject.

Problematic areas I see (side from possible code style issues) are:
1) I added support for a new SPI NOR Flash and that should, probably, be
a separate patch.
2) I added support for SPI NOR partitioning and I'm unsure if that
should be in the "board definition".
3) SPI NOR partitioning is actually duplicated in ENV var (mtdparts) and
in Device Tree; I didn't find how to read it directly from DT.
4) Board also has SD, handled via MTK_SD driver, but I've been unable to
make it work.
5) Current binary is rather big and I would like to shrink it a bit, if
possible.

Any hint/criticism/advice would be VERY welcome.
Thanks in Advance
Mauro Condarelli
diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
index c9d75596f2..234bdfbaa9 100644
--- a/arch/mips/dts/Makefile
+++ b/arch/mips/dts/Makefile
@@ -22,6 +22,7 @@ dtb-$(CONFIG_BOARD_NETGEAR_DGND3700V2) += netgear,dgnd3700v2.dtb
 dtb-$(CONFIG_BOARD_SAGEM_FAST1704) += sagem,f...@st1704.dtb
 dtb-$(CONFIG_BOARD_SFR_NB4_SER) += sfr,nb4-ser.dtb
 dtb-$(CONFIG_BOARD_TPLINK_WDR4300) += tplink_wdr4300.dtb
+dtb-$(CONFIG_BOARD_VOCORE2) += vocore2.dtb
 dtb-$(CONFIG_TARGET_JZ4780_CI20) += ci20.dtb
 dtb-$(CONFIG_SOC_LUTON) += luton_pcb090.dtb luton_pcb091.dtb
 dtb-$(CONFIG_SOC_OCELOT) += ocelot_pcb120.dtb ocelot_pcb123.dtb
diff --git a/arch/mips/dts/vocore2.dts b/arch/mips/dts/vocore2.dts
new file mode 100644
index 00..826309965d
--- /dev/null
+++ b/arch/mips/dts/vocore2.dts
@@ -0,0 +1,84 @@
+/dts-v1/;
+
+#include "mt7628a.dtsi"
+
+/ {
+	compatible = "vocore,vocore2", "ralink,mt7628a-soc";
+	model = "VoCore2";
+
+	aliases {
+		serial0 = 
+		spi0 = 
+	};
+
+	memory@0 {
+		device_type = "memory";
+		reg = <0x0 0x0800>;
+	};
+
+	chosen {
+		bootargs = "console=ttyS2,115200 root=/dev/mtdblock4 rootfstype=squashfs USE=SD";
+		stdout-path = 
+	};
+};
+
+ {
+	state_default: pin_state {
+		p0led {
+			groups = "p0led_a";
+			function = "led";
+		};
+	};
+};
+
+ {
+	status = "okay";
+};
+
+ {
+	status = "okay";
+	nor0: m25p80@0 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "m25p80";
+		spi-max-frequency = <1000>;
+		reg = <0x0>;
+		m25p,chunked-io = <32>;
+
+		partition@0 {
+			label = "u-boot";
+			reg = <0x0 0x5>;
+		};
+		partition@5 {
+			label = "kernel";
+			reg = <0x5 0x2b>;
+		};
+		partition@30 {
+			label = "filesystem";
+			reg = <0x30 0xcfe000>;
+		};
+		partition@ffe000 {
+			label = "env";
+			reg = <0xffe000 0x001000>;
+		};
+		eeprom: partition@fff000 {
+			label = "factory";
+			reg = <0xfff000 0x001000>;
+		};
+	};
+};
+
+ {
+	pinctrl-names = "default";
+	pinctrl-0 = <_iot_mode>;
+	mediatek,poll-link-phy = <0>;
+};
+/*
+ {
+	status = "okay";
+	mediatek,mtd-eeprom = < 0x>;
+};
+*/
+ {
+	status = "okay";
+};
diff --git a/arch/mips/mach-mtmips/Kconfig b/arch/mips/mach-mtmips/Kconfig
index c8dcf19c0d..5ea260232f 100644
--- a/arch/mips/mach-mtmips/Kconfig
+++ b/arch/mips/mach-mtmips/Kconfig
@@ -43,6 +43,14 @@ config BOARD_LINKIT_SMART_7688
 	  ethernet ports, 1 USB port, 1 UART, GPIO buttons and LEDs, and
 	  a MT7688 (PCIe).
 
+config BOARD_VOCORE2
+	bool "VoCore2"
+	depends on SOC_MT7628
+	select SUPPORTS_BOOT_RAM
+	help
+	  Vonger VoCore2 board has a MT7628 SoC with 128 MiB of RAM
+	  and 16 MiB of flash (SPI).
+
 endchoice
 
 choice
@@ -134,5 +142,6 @@ config SUPPORTS_BOOT_RAM
 
 source "board/gardena/smart-gateway-mt7688/Kconfig"
 source "board/seeed/linkit-smart-7688/Kconfig"
+source "board/vonger/vocore2/Kconfig"
 
 endmenu
diff --git a/board/vonger/vocore2/Kconfig b/board/vonger/vocore2/Kconfig
new file mode 100644
index 00..4067973e70
--- /dev/null
+++ b/board/vonger/vocore2/Kconfig
@@ -0,0 +1,11 @@
+if BOARD_VOCORE2
+config SYS_BOARD
+	default "vocore2"
+