On Wed, Dec 23, 2020 at 5:57 AM André Przywara wrote:
>
> On 19/12/2020 14:51, Amit Singh Tomar wrote:
> > From: Amit Singh Tomar
> >
> > This commit adds support for MMC controllers found on Actions OWL
> > S700 SoC platform.
> >
> > Signed-off-by: Amit Singh Tomar
> > ---
> > Changes since pre
Hi,
> Have you checked if this setting can be reused for S900? IMO we should use
> this helper for all Owl SoCs. Using CONFIG_SYS_SDRAM_SIZE won't scale.
Looks like S900 uses different registers to find out the size, but
can't really test
this as I don't have the Hardware based on S900.
Thanks
-
Hi Mani,
>
> This doesn't work on Bubblegum96. But poking into the vendor tree, I'm able
> to come up with below working code:
>
> val = (readl(DMM_INTERLEAVE_PER_CH_CFG) >> 8) & 0xf;
> cap = 64 * (1 << val);
>
> So, you can use this and remove other stuffs. Also this function shou
Hi,
On Tue, May 12, 2020 at 7:49 PM André Przywara wrote:
>
> On 09/05/2020 15:25, Amit Singh Tomar wrote:
> > This patch adds node for ethernet controller found on Action Semi OWL
> > S700 SoC.
> >
> > Since, there is no upstream Linux binding exist for S700 ethernet
> > controller, Changes are
Hi,
> The general way to move forward here is that bindings should be getting
> proposed to Linux and accepted there, and U-Boot can take a WIP of them,
> that gets updated later on to match, but we shouldn't get it here first.
I do have a plan to propose this binding to Linux but this is kind of
> So, we're at -rc2 for v2020.07. The DDR calculation stuff I can see
> getting pulled in. Is the ethernet driver for this SoC so far from done
> that it's not ready for linux-next? Things don't have to be in mainline
> proper, but the expectation is that it's making reasonable progress
> there
Hi Mani,
> Just tested v8 on bubblegum96 and it doesn't boot. I can't see any debug
> print on the console, so I'm guessing something basic going wrong. Will
> try to find the regression if I find some time and keep you posted.
Thanks for trying it. Looks like issue is with clock driver (not
read
Hi,
> Mostly is looks very good now. I just had few nit picks which you can
> address in v10.
Thanks for providing review comments, just sent the v10 addressing
the comments.
> This series won't make it for v2020.04 but that's not critical IMO.
No issues, It would be good if it gets merge in ne
Hi,
On Mon, Jul 6, 2020 at 6:12 AM Andre Przywara wrote:
>
> Hi,
>
> while looking at several U-Boot network drivers in the past year, I
> typically compared them to the sun8i-emac driver, as a kind of personal
> reference. While doing so, I figured that there are quite some things
> broken in he
Hi Mani,
>
> Sorry for the late reply. Got swamped with lot of stuffs :(
>
> Thanks a lot for the series! I will review it soon and test it on my S900
> based Bubblegum 96 board.
No worries, Thanks for the update!
Thanks
-Amit
Hi,
On Tue, Feb 4, 2020 at 1:12 AM Stefan Bosch wrote:
>
>
> This patch adds support for SAMSUNG's/NEXELL's ARM Cortex-A9 based
> S5P4418 SoC, especially FriendlyARM's NanoPi2 and NanoPC-T2 boards.
> It is based on the following FriendlyARM's U-Boot version:
> https://github.com/friendlyarm/u-boo
Hi,
Thanks for having a look.
> Either use `priv->soc` or the guard throughout the driver. Please don't mix
> both.
But have used #ifdef guard only where it is really necessary and to
keep implementation
clean used priv->soc.
> > +
> > +static const struct udevice_id owl_clk_ids[] = {
> > +#if
Hi,
> So either you send this patch to the kernel first, or, probably better, you
> drop this change here, and unify the name at the point where it's used
> (#ifndef CLK_ETHERNET )
But this is something mentioned in cover letter:
"Patch(9/21) uses same name for ethernet clock binding and i
Hi,
> Indeed, but it's here to not give false impressions: Despite the joint code,
> the clock driver only works for one SoC at a time. Having only that one
> respective compatible string in here makes this obvious.
>
> The main reason for this approach is that the register offsets are quite
>
Hi,
> Both those include files do not exist yet. This breaks bisectability for
> bubblegum_96.
> So I would suggest you remove the s700 lines for now, and change the
> s900 filename to match the existing one.
> Then change CLK_UART to CLOCK_UART below to make it compile.
>
> Please check that bubb
Hi Tom
On Sat, May 9, 2020 at 1:45 PM Amit Singh Tomar wrote:
>
> Mani pointed out that changes in previous version were not good enough
> for S900 and he provide snippet that seems to work on S900.
>
> This series v4 fixes the S900 Support by taking in changes suggested
> by Mani.
>
> --
Hi,
Thanks for having a look.
> Yeah, I had some success with 5.5-rc, at least till it goes into userland,
> which is good enough for this purpose.
> And indeed I could reproduce the early crash with genet compiled in vs.
> mainline U-Boot.
Could not reproduce it with raspbian image but after
Hi,
> The kernel panic just after with "OF: reserved mem: failed to allocate memory
> for node 'linux,cma'" but that's another story.
But this comes even without having Ethernet patches and when one use
booti instead of bootefi, right ?
Thanks
-Amit
Hi Adam,
> I am attempting to boot the Pine64-lts with a Trusted OS. In the ARM-TF
> documentation it states "make sure the loader (SPL) loads the Trusted OS
> binary to the beginning of DRAM (0x4000)." I have yet to find a
> mechanism by which U-Boot's SPL for this platform can be configure
Hi Sascha,
> Are any other cases i could test ? don't worry, one of three boards i
> could damage ! (but it's better if not ... ;-))
Just curious to know what data transfer rate, you see while tftp?
Thanks
-Amit
Hi Pragnesh,
Minor comments regarding coding style, see below.
> + // Probably don't need to do this, since
> + // all the other stuff has been happening.
> + // But it is on the wave form.
U-boot is mostly implemented in C, we should *not* use C++ style comments(//).
is this s
Hi,
Thanks for having the detailed look and providing comments:
> According to the datasheet the clock source could also be NAND_PLL,
> depending on bit 9.
> Both PLLs use the same rate calculation, so it's just matter of the PLL
> address offset to use for covering both.
Ok, should I change the
Hi,
On Mon, Dec 14, 2020 at 6:45 AM André Przywara wrote:
>
> On 13/12/2020 09:43, Amit Singh Tomar wrote:
> > This commit introduces get/set_rate callbacks, these are dummy at
> > the moment, and can be used to get/set clock for various devices
> > based on the clk id.
> >
> > Signed-off-by: Ami
> Ah, good catch, I agree on the -u-boot.dtsi approach.
Thanks for talking about it( I was expecting this comment)
> Amit, please don't claim it's "sync with Linux" if it isn't. At least
> document this change.
Yeah, I was aware of this situation but rightly so, I should have documented
it in co
Hello!
> +
> +#define CONFIG_TX_DESCR_NUM8
> +#define CONFIG_RX_DESCR_NUM8
> +#define CONFIG_ETH_BUFSIZE 2048
Isn't it too BIG size for normal ethernet frame, unless we need Jumbo Frame ?
Thanks,
Amit.
___
U-Boot mailing list
U-Boot@lists.
On Sun, May 15, 2016 at 2:51 AM, Bhupesh Sharma wrote:
> Note that UEFI firmware support is already available on LS2080A-RDB and allows
> Booting distributions like CentOS on the same.
>
Sorry to intervene here but it's about having the EFI support inside
u-boot itself that
may *not* required to
Hello,
Thanks for your comments, Sorry for the delayed response.
> 1 is too high
Ok, I will fix it but as per data sheet its 64k region(0x1).
> Space after dot. Try also to keep a minimum of alphabetical order of config.
Ok, I will fix it.
> Sort also headers
Sorry, didn't get your p
Hello,
Trying to add support for H3 EMAC driver.
http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/261544
It was working well until commit "
b733c278d7adc48c71bd06faf359db3d9e385185" was introduced.
net: phy: Handle phy_startup() error codes properly
- genphy_update_link(phydev);
Hello!
>
> Since the driver is dm-driven this config not need.
I tried not to use this config but then driver don't get compiled.
You're talking about CONFIG_USB_EHCI and CONFIG_USB_EHCI_SUNXI, right ?
Thanks
Amit.
___
U-Boot mailing list
U-Boot@lis
Hello,
> index 7c088c3..877859c 100644
> --- a/drivers/net/sun8i_emac.c
> +++ b/drivers/net/sun8i_emac.c
> @@ -32,7 +32,8 @@
>
> #define CONFIG_TX_DESCR_NUM32
> #define CONFIG_RX_DESCR_NUM32
> -#define CONFIG_ETH_BUFSIZE 2024
> +#define CONFIG_ETH_BUFSIZE 2048
> +#define CONFIG_E
> I'm assuming this was supposed to be devfdt_get_addr.
Or, you could try dev_read_addr_ptr.
Thanks
-Amit
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Hi,
> + val = readl(&gpios->reg->gpfsel[BCM2835_GPIO_FSEL_BANK(gpio)]);
> + val &= ~(BCM2835_GPIO_FSEL_MASK << BCM2835_GPIO_FSEL_SHIFT(gpio));
> + val |= (func << BCM2835_GPIO_FSEL_SHIFT(gpio));
> + writel(val, &gpios->reg->gpfsel[BCM2835_GPIO_FSEL_BANK(gpio)]);
Can clrset
Hello Sascha,
> > Am 07.12.19 um 07:23 schrieb Sascha Dewald:
> > > Hello,
> > >
> > > is there any progress yet ?
Sorry for being late on this.
We have made some progress, ping from RPI to host is working now.
Also, managed to received short files(< 63KB) via TFTP.
but haven't managed to get pr
Hi,
Thanks for having the look.
>
> I am afraid that needs to be more elaborate. You could mention Broadcom, also
> that it's only for v5 of it. And that it's based on reverse engineering the
> Linux driver.
> Text in the cover letter will not make it into the repo, so you should
> mention thi
Hi
On Tue, May 19, 2020 at 8:21 PM Tom Rini wrote:
>
> When building U-Boot we select the architecture via Kconfig and not ARCH
> being passed in via the environment or make cmdline.
>
> Cc: Adam Ford
> Cc: Vanessa Maegima
> Cc: Otavio Salvador
> Cc: Igor Opaniuk
> Cc: Amit Singh Tomar
> Cc:
Hi,
On Wed, May 27, 2020 at 12:07 AM Tom Rini wrote:
>
> When building U-Boot we select the architecture via Kconfig and not ARCH
> being passed in via the environment or make cmdline.
>
> While in here, add the doc file to the MAINTAINERS entry.
>
> Cc: Amit Singh Tomar
> Cc: Manivannan Sadhasi
36 matches
Mail list logo