Date: Sat, 26 Dec 2015 12:27:06 +0100 From: Willem Jan Withagen <wjw@digiware.nl> To: Stanislav Galabov <sgalabov@gmail.com>, "Rodney W. Grimes" <freebsd@pdx.rh.CN85.chatusa.com> Cc: "freebsd-mips@freebsd.org" <freebsd-mips@freebsd.org> Subject: Re: mt7620 works! Message-ID: <567E798A.3040808@digiware.nl> In-Reply-To: <10F858B5-2F48-4E23-996A-E6D9663FEB46@gmail.com> References: <201512260057.tBQ0vcVO005566@pdx.rh.CN85.chatusa.com> <10F858B5-2F48-4E23-996A-E6D9663FEB46@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 26-12-2015 06:15, Stanislav Galabov wrote: > >> On 26.12.2015 г., 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 >> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?567E798A.3040808>