All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Condarelli <mc5686@mclink.it>
To: u-boot@lists.denx.de
Subject: [PATCH v3 00/20] Refactor the architecture parts of mt7628
Date: Tue, 11 Feb 2020 17:11:45 +0100	[thread overview]
Message-ID: <b73256d8-e974-0198-7a4c-8e3cd3fc2319@mclink.it> (raw)
In-Reply-To: <CACUy__WYFVZKTbn03Pc1O-vDzVo8wNRcAuRFFqaNjJ77GOfG_w@mail.gmail.com>

Sorry Daniel,
I seem unable to pass the message through.

I have, in front of me two, very similar directories:

u-boot.master:
built from master + Weijie.v3 patches + my vocore2 patch.

u-boot-mips:
built from u-boot-mips/testing + my vocore2 patch.

I was very careful not to change anything after patching.

In both directories I do:

make ARCH=mips CROSS_COMPILE=mipsel-linux- distclean
make ARCH=mips CROSS_COMPILE=mipsel-linux- vocore2_defconfig
make ARCH=mips CROSS_COMPILE=mipsel-linux-

Both produce similarly-sized u-boot-mtmips.bin (Flash version)
and u-boot.bin (RAM version).

On my target I do:

setenv autoload no; dhcp; tftpboot 80200000 192.168.7.101:u-boot.bin; go
${fileaddr}

In the case of the "master dir I get:

=> setenv autoload no; dhcp; tftpboot 80200000 192.168.7.101:u-boot.bin;
go ${fileaddr}
BOOTP broadcast 1
DHCP client bound to address 192.168.7.135 (115 ms)
Using eth at 10110000 device
TFTP from server 192.168.7.101; our IP address is 192.168.7.135
Filename 'u-boot.bin'.
Load address: 0x80200000
Loading: ####################################
     1.1 MiB/s
done
Bytes transferred = 527090 (80af2 hex)
## Starting application at 0x80200000 ...


U-Boot 2020.01-00648-gc46834052a-dirty (Feb 11 2020 - 09:30:52 +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 at 10130000: 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 at 10110000 (eth0) using random MAC address - 26:9f:0f:24:ae:39
eth0: eth at 10110000
Hit any key to stop autoboot:  0
=>

If I do the same with product of "mips" dir I get:

=> setenv autoload no; dhcp; tftpboot 80200000 192.168.7.101:u-boot.bin;
go ${fileaddr}
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
DHCP client bound to address 192.168.7.112 (3136 ms)
Using eth at 10110000 device
TFTP from server 192.168.7.101; our IP address is 192.168.7.112
Filename 'u-boot.bin'.
Load address: 0x80200000
Loading: ####################################
     1 MiB/s
done
Bytes transferred = 527390 (80c1e hex)
## Starting application at 0x80200000 ...
<*DEAD*>

I am trying to understand where difference lies... and failing, to date :(

I already sent "my vocore2 patch" (Note: that is a "git rebase -i"
squashing the three commits in one, no change) earlier today;
if You think it might be useful I can send also the complete
"git format-patch" from a known u-boot master commit from
where I branched off
(currently 8b9cc858e0239823b051a9324431d511baf2b998)

My "git log --oneline" on "master" is:
c46834052a (HEAD -> weijie.v3.vocore.net, syno0/weijie.v3.vocore.net)
Move back environment to SPI NOR. Changes to environment default settings.
7dbd7fc8bc Added network setup.
375435c35e (syno0/weijie.v3.vocore, weijie.v3.vocore) Add support for
SoM "VoCore2".
f4fa7f499e (syno0/weijie.v3, weijie.v3) mips: mtmips: add support for
mt7628-rfb
724463aa9e mips: mtmips: enable SPL for all boards
1fe4eda6c3 mips: mtmips: add SPL support
5ea8181206 spl: nor: add lzma decompression support for legacy image
173aa9cb6c tools: binman: add etype file for u-boot-lzma-img
789a9085d3 Makefile: add support to generate LZMA compressed u-boot image
e4721a8b98 lib: enable lzma decompression support for SPL build
b769d64488 mips: add an option to enable u_boot_list section for SPL
loaders in u-boot-spl.lds
c704313c7e mips: enable support for appending dtb to spl binary
8801d2b226 dts: mtmips: add alternative pinmux node for uart2
4cda40c3ea mips: mtmips: rewrite lowlevel codes of mt7628
13299d7651 mips: add a option to support not reserving malloc space on
initial stack
eb8a3689b0 mips: add a mtmips-specific field to architecture-specific
global data
f5fda08bed configs: enable CONFIG_RESTORE_EXCEPTION_VECTOR_BASE for all
mtmips boards
e95f8beabe mips: mtmips: make use of sysreset-resetctrl for mt7628 soc
58246e0175 sysreset: add reset controller based reboot driver
b6a20ebced mips: start.S: avoid overwriting outside gd when clearing
global data in stack
c2359e8947 mips: add an option to support initialize SRAM for initial stack
a6eecdd28e mips: mtmips: add predefined i-cache/d-cache size and linesize
b096b2e05f mips: add support to restore exception vector base before
booting linux
2e5b1c00fd MIPS: allow override of get_tbclk()
8b9cc858e0 mx7ulp: Move SoC base address to a common file
...

while in the "mips" directory I have:
cd23ee2179 (HEAD -> VoCore2) Move back environment to SPI NOR. Changes
to environment default settings.
ddc07fb968 Added network setup.
9eabc0c0bb Add support for SoM "VoCore2".
b3d1d5d05b (origin/testing, testing, master) mips: mtmips: add support
for mt7628-rfb

As said: there must be 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 <mc5686@mclink.it> 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.
>

  parent reply	other threads:[~2020-02-11 16:11 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-21  8:17 [PATCH v3 00/20] Refactor the architecture parts of mt7628 Weijie Gao
2020-01-21  8:30 ` Weijie Gao
2020-02-10 17:20 ` Daniel Schwierzeck
2020-02-10 20:20   ` Mauro Condarelli
2020-02-10 21:28     ` Daniel Schwierzeck
2020-02-11 10:58       ` Mauro Condarelli
2020-02-11 11:16         ` Stefan
2020-02-11 12:34           ` Mauro Condarelli
2020-02-11 12:41             ` Stefan
2020-02-11 13:54         ` Daniel Schwierzeck
2020-02-11 14:27           ` Stefan
2020-02-11 16:11           ` Mauro Condarelli [this message]
2020-02-11 16:49             ` Daniel Schwierzeck
2020-02-11 18:05               ` Mauro Condarelli
2020-02-12  6:39                 ` Stefan
2020-02-12  9:23                   ` Mauro Condarelli
2020-02-12 12:25                     ` Stefan
2020-02-12 12:48                     ` Daniel Schwierzeck
2020-02-12 13:46                       ` Stefan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b73256d8-e974-0198-7a4c-8e3cd3fc2319@mclink.it \
    --to=mc5686@mclink.it \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.