Date: Sat, 26 Dec 2015 16:12:08 +0200 From: Stanislav Galabov <sgalabov@gmail.com> To: Willem Jan Withagen <wjw@digiware.nl> Cc: "Rodney W. Grimes" <freebsd@pdx.rh.cn85.chatusa.com>, "freebsd-mips@freebsd.org" <freebsd-mips@freebsd.org> Subject: Re: mt7620 works! Message-ID: <CANiSyhSX9GBR7rTnHTJvSit_FGKQ21mySpE1g94mc68Rp7JH-Q@mail.gmail.com> In-Reply-To: <567E798A.3040808@digiware.nl> References: <201512260057.tBQ0vcVO005566@pdx.rh.CN85.chatusa.com> <10F858B5-2F48-4E23-996A-E6D9663FEB46@gmail.com> <567E798A.3040808@digiware.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Dec 26, 2015 at 1:27 PM, Willem Jan Withagen <wjw@digiware.nl> wrote: > On 26-12-2015 06:15, Stanislav Galabov wrote: > > > >> On 26.12.2015 =D0=B3., at 2:57, Rodney W. Grimes > >> <freebsd@pdx.rh.CN85.chatusa.com> wrote: > >> > >> ... > >>>> But if you're trying to build a kernel for the WiTi board > >>>> (MT7621) you won't be able to as the MT7621 bits are still not > >>>> in -head. > >>>> > >>>> The last commits by Adrian only support RT305x and introduce > >>>> support for RT5350 (basic support) and MT7620. The MT7620 is > >>>> substantially different than the MT7621, so it's not a > >>>> straightforward thing to make it work (UART is different for > >>>> one). > >>>> > >>>> I'll continue working on Mediatek/Ralink support in the new > >>>> year, so hopefully things are going to get easier then. > >>> > >>> Sort of informative, but the page refers to 'oldlzma'. Which I > >>> suspect is needed otherwise Uboot starts complaining about during > >>> decompressing and aborts. > >> > > Stanislav, > > I indeed started used none as compression, which appeased the loader. > But getting it to boot is another issue. > > Just loading it by letting uboot figure it out, does nog show/boot > anything. > Which I now understand could be because the uart is differntly defined, > and as such does not work > > As I mentioned already, MT7620 and MT7621 are quite different, so you won't be able to boot a MT7620 kernel on the WiTi board, which is based on MT7621. I'll work on adding MT7621 support in the beginning of the new year, so this should make things easier :-) > >> Also I see in the page where some of the magic 0x80xxxxxx addresses > >> come from, but where did the magic number come from for these two > >> commands: > >> > >> tftpboot 0x80800000 DIR-620/kernel.oldlzma.uboot bootm 0x80800000 > >> > > 0x80800000 is u-boot's default value for the loadaddr environment > > variable on some Ralink/Mediatek boards. This is the address which is > > used for loading stuff via tftp for example. In any case, it could be > > any valid memory address, which wouldn't cause overwriting u-boot > > itself while loading a file (kernel image in this case) via tftp. > > U-boot will then properly relocate the loaded file to the address > > inside the image header before booting the kernel as part of > > executing the bootm command. I guess the page author didn't think it > > was necessary to add this information... > > That was the other thing I was wondering about. But I would expect that > all information in the header added by mkimage would do the trick and > make uboot do the "right" thing. > I works for the early version for MT7621 that you build. > > --WjW > > The header file in the image instructs U-Boot about what needs to be done once the image is loaded to the board's memory (e.g., to RAM via TFTP in your particular case). But you need to tell U-Boot where to load the image itself, hence the loadaddr variable or manually specified load address as part of the tftp and bootm comands. If you do not specify the address on the command line then U-Boot will try to use loadaddr from environment or a default hard-coded value. This should work just fine in most cases, so normally you can just skip specifying the load address. I hope I am making things clearer :-) Best wishes, Stanislav
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANiSyhSX9GBR7rTnHTJvSit_FGKQ21mySpE1g94mc68Rp7JH-Q>