Page MenuHomeFreeBSD

mmel (Michal Meloun)
User

Projects

User Details

User Since
Feb 3 2015, 4:54 AM (284 w, 1 d)

Recent Activity

Sun, Jul 12

mmel updated the diff for D25371: Add NetBSD compatible bus_space_peek_N() and bus_space_poke_N() functions and implement it on arm64..

finish implementation

  • added manpage
  • added default implementation for other architectures
  • kcsan functions was implemented
  • fault detection fault for arm64. was rewritten
Sun, Jul 12, 8:56 AM
mmel committed rS363123: Reverse the processing order of assigned clocks property..
Reverse the processing order of assigned clocks property.
Sun, Jul 12, 7:59 AM
mmel committed rS363122: Assigned clocks: fix off-by-one bug, don't leak allocated memory..
Assigned clocks: fix off-by-one bug, don't leak allocated memory.
Sun, Jul 12, 7:42 AM
mmel committed rS363121: Fix the module name for some arm drivers..
Fix the module name for some arm drivers.
Sun, Jul 12, 7:27 AM

Tue, Jun 23

mmel updated the diff for D13864: Add workaround for broken PSCI implementation..
Tue, Jun 23, 3:22 AM

Sat, Jun 20

mmel added a comment to D25371: Add NetBSD compatible bus_space_peek_N() and bus_space_poke_N() functions and implement it on arm64..
In D25371#559724, @kib wrote:

Do you need them in asm ?

See below, but what's wrong on assembly code? I'm asking as the one who starts his programmers career on 6502 assembly :)
But I really think, in this case, that asm code is more appropriate (in terms of the stability of the generated code) that hacked C - I just hate all ideas like 'read_once ()' or something.

As I understand the idea, the code is approximately

uint32_t
bus_space_poke_4(...)
{
    curthread->td_pcb->pcb_onfault = <peek_handler>;
    res = bus_space_read_4(...);
    dmb(sy);
    curthread->td_pcb->pcb_onfault = NULL;
}

Right.

And this structure immediately illustrates another question. You currently use fsu_fault for handler, which suppresses all kinds of exceptions. But bus_space_read() needs to dereference some pointers, which might fault due to programmer' errors, not because of the hardware state. It would be nice to distinguish the mistake/hardware error situations and react differently.

Well, in ideal world we should use specialized fault handler fired only by small subset of aborts ( I think that reality is that only synchronous external abort[1] is appropriate) and covering only single register to memory load/store (+ necessary synchronization instruction). In real-world implementation I select to not make trap.c more complicated and i think that handling all aborts over single load/store (that is reason, why is executive code implemented in asm) is acceptable compromise.
What do you think?

Sat, Jun 20, 4:20 PM
mmel added a comment to D25371: Add NetBSD compatible bus_space_peek_N() and bus_space_poke_N() functions and implement it on arm64..

The kcsan implementation for peek will be something like the following (untested):

Sat, Jun 20, 10:33 AM
mmel requested review of D25371: Add NetBSD compatible bus_space_peek_N() and bus_space_poke_N() functions and implement it on arm64..
Sat, Jun 20, 9:49 AM

Fri, Jun 19

mmel committed rS362415: Improve if_dwc:.
Improve if_dwc:
Fri, Jun 19, 7:27 PM
mmel committed rS362405: Finish renaming in if_dwc..
Finish renaming in if_dwc.
Fri, Jun 19, 6:34 PM
mmel committed rS362399: Use naming nomenclature used in DesignWare TRM..
Use naming nomenclature used in DesignWare TRM.
Fri, Jun 19, 6:04 PM
mmel committed rS362392: Adapt ARMADA8k PCIe driver to newly imported 5.7 DT..
Adapt ARMADA8k PCIe driver to newly imported 5.7 DT.
Fri, Jun 19, 5:34 PM
mmel committed rS362391: Revert r362389, it was committed with <patch>.diff instead of <patch>.txt as.
Revert r362389, it was committed with <patch>.diff instead of <patch>.txt as
Fri, Jun 19, 5:33 PM
mmel committed rS362389: diff --git a/sys/dev/pci/pci_dw_mv.c b/sys/dev/pci/pci_dw_mv.c.
diff --git a/sys/dev/pci/pci_dw_mv.c b/sys/dev/pci/pci_dw_mv.c
Fri, Jun 19, 5:26 PM
mmel committed rS362388: Use native-sized accesses when accessing memory from kdb..
Use native-sized accesses when accessing memory from kdb.
Fri, Jun 19, 4:27 PM
mmel committed rS362387: Improve DesignWare PCIe driver:.
Improve DesignWare PCIe driver:
Fri, Jun 19, 4:15 PM
mmel committed rS362386: Add specific stub for ARMADA 8k SoC to Marvell RTC driver..
Add specific stub for ARMADA 8k SoC to Marvell RTC driver.
Fri, Jun 19, 3:33 PM
mmel committed rS362385: Add specialized gpio driver for ARMADA 8k SoC..
Add specialized gpio driver for ARMADA 8k SoC.
Fri, Jun 19, 3:21 PM
mmel committed rS362384: Add DTB files for ARMADA 8040 based boards..
Add DTB files for ARMADA 8040 based boards.
Fri, Jun 19, 2:29 PM

Thu, Jun 18

mmel added a comment to D13863: Simplify and cleanup startup code for secondary cores..

Yes, it changes CPU IDs. (For FDT case only. I assume that ACPI must always start on CPU0, even if I didn't find it in standard).
Please take in account that"

Thu, Jun 18, 1:46 PM
mmel accepted D25118: Ti AM335x move to dev/extres/clk framework.

It also looks OK for me. I have a few small items that we should rethink or fix, but we can do all of these (including pandaboard support) as follow-up fixes. I can commit this as is over the weekend and then we can start discussing improvements (and I also hope to have a little more free time from next week).
Oscar, manu do you agree?
Problematic (for me) items are:

  • The ti_dpll_clk_set_freq routine should respect rounding (dpll) and DRY_RUN.
  • I’m not a big friend of bulk clock enable in ti_sysc_clock_enable().
  • probably , it will be easier to convert scm_clocks and prcm_clocks instances from FDT data driven to compiled-in table driven clocks implementation.

But all these are minor and should be discussed firstly...

Thu, Jun 18, 12:48 PM · ARM

Jun 14 2020

mmel updated the diff for D13863: Simplify and cleanup startup code for secondary cores..

Update to the final version. r359280 removed the need to access the cpu_mpidr table from the assembler. So eliminate it and insert the mpidr field into the pcpu structure as originally requested.

Jun 14 2020, 9:25 AM

Jun 11 2020

mmel committed rS362053: Fix grabbing of tegra uart..
Fix grabbing of tegra uart.
Jun 11 2020, 12:53 PM

Jun 10 2020

mmel added a comment to D25175: Add functions to sys/dev/extres/clk.

Oskar,
Firstly, it seems to have forgotten to thank you for your efforts. I apologize for my discourtesy.
Also allow me to continue here..

Jun 10 2020, 1:57 PM · ARM
mmel requested changes to D25175: Add functions to sys/dev/extres/clk.
Jun 10 2020, 9:16 AM · ARM
mmel added inline comments to D25175: Add functions to sys/dev/extres/clk.
Jun 10 2020, 9:14 AM · ARM

Jun 4 2020

mmel updated the diff for D13863: Simplify and cleanup startup code for secondary cores..

Rebased to head. Fixed cpuid assignment

Jun 4 2020, 11:56 AM
mmel added inline comments to D24423: arm/pmu: add ACPI attachment, more FDT names.
Jun 4 2020, 10:19 AM · arm64
mmel added a comment to D22606: Switch to an empty ttbr0 pagetable when the MMU is enabled.

Ping. Andrew, please, do you want to finish (and commit) by yourself? Alternatively, I can manage it if you prefer.

Jun 4 2020, 8:22 AM

Jun 3 2020

mmel added a comment to D24423: arm/pmu: add ACPI attachment, more FDT names.

Sorry for late response, i'm busy by real life these days and you forced me to dig into problem much deeper than I wanted :).

Jun 3 2020, 1:16 PM · arm64
mmel added a comment to D25068: Add driver for bcm2838 PCI express controller.

Why you choose to use pci_host_generic as base class? By my best knowledge pci_host_generic is driver for ACPI/ECAM compatible PCI root port and it have nothing with Broadcom iProc PCIe controller. I think that it should be derived from ofw_pci_driver. Please see pci_dw.c for template...
(Don't kill me immediately, this change is not that horrible as it looks on first view).

Jun 3 2020, 12:37 PM

May 22 2020

mmel accepted D24351: Add QorIQ platform clockgen driver..

Thanks!

May 22 2020, 7:56 PM
mmel added a comment to D24352: Add LS1046A clockgen driver..

from IRC:
There is at least 11 variants of QoriQ arm64 based SoCs. This is too much for per-SOC options.
We can always add a SOC_NXP_LS_BLAH and !it if one soc differs

May 22 2020, 3:54 PM
mmel accepted D24352: Add LS1046A clockgen driver..

The LS family has too many members and can share 99% of the code. It seems unnecessary for me to have the option for each individual variant. How about 'SOC_NXP_LS' ?

May 22 2020, 12:46 PM
mmel accepted D24351: Add QorIQ platform clockgen driver..

LGTM.
I looking forward when my HoneyComb LX2K arrives, order was placed . I got offer (paid by this card :) ) to port FreeBSD to CEx7 LX2160A module. And because customer wants maximum control of clocks, clocks gating, inactive phys and so, only fully featured FDT base port is possible. So, please, be prepared to do some testing of new code on your board :)

May 22 2020, 12:24 PM

May 19 2020

mmel requested changes to D24423: arm/pmu: add ACPI attachment, more FDT names.
May 19 2020, 3:44 PM · arm64
mmel accepted D24876: Create MSI/MSI-X isrcs as needed in the GICv3 ITS driver.

Tested on RK3399 in FDT based environment, no problems detected.
LGTM

May 19 2020, 1:10 PM

May 14 2020

mmel added a comment to D24352: Add LS1046A clockgen driver..

Imho, It will be better to wait with this until we find consensus with D24351, right ?

May 14 2020, 10:46 AM
mmel requested changes to D24351: Add QorIQ platform clockgen driver..

This is much better implementation, thanks.
I see only one majoe issue (for me), fortunately it’s easy to fix.
Please, never use synthetic (generated) names for clock mapping, instead use a clock ID for this job. Names must be unique per system and you cannot guarantee this. As opposite, clock ID is property of given clock domain - so you can guarantee that these are unique within single clock domain.
Please combine type cell value and index cell value into unique number and the use clknode_find_by_name() inside qoriq_clkgen_ofw_mapper(). See [1]

May 14 2020, 10:40 AM
mmel accepted D24363: Add TCA6416 GPIO expander support..

LGTM

May 14 2020, 8:05 AM

Apr 29 2020

mmel committed rS360469: Move ARM specific flags to arm/Makefile.inc.
Move ARM specific flags to arm/Makefile.inc
Apr 29 2020, 4:06 PM
mmel committed rS360467: Fix style(9). Strip write only variables..
Fix style(9). Strip write only variables.
Apr 29 2020, 2:37 PM
mmel committed rS360466: Export tracing facility of GIC500 ITS block..
Export tracing facility of GIC500 ITS block.
Apr 29 2020, 2:31 PM
mmel committed rS360464: Don't try to set frequendcy for enumerated but newer started CPUs..
Don't try to set frequendcy for enumerated but newer started CPUs.
Apr 29 2020, 2:14 PM
mmel committed rS360463: Don't allow to use FPU inside of rtld library..
Don't allow to use FPU inside of rtld library.
Apr 29 2020, 2:06 PM
mmel committed rS360462: Don't try to re-initialize already preseted regulator..
Don't try to re-initialize already preseted regulator.
Apr 29 2020, 1:45 PM
mmel committed rS360461: Multiple fixes for rockchip iodomain driver:.
Multiple fixes for rockchip iodomain driver:
Apr 29 2020, 1:43 PM

Apr 25 2020

mmel committed rS360293: Reorder initialization steps for given pin..
Reorder initialization steps for given pin.
Apr 25 2020, 9:18 AM

Apr 14 2020

mmel requested changes to D24351: Add QorIQ platform clockgen driver..

With full respect, this is nothing that fake driver.
Faking chip clock structure with set of fixed clock nodes with statically computed frequency is not useful at all.
Please try again, this time so that the driver reflects the real clock tree structure.
And because I'm responsible for not having the documentation for clock framework , I offering maximum possible help.

Apr 14 2020, 6:52 PM
mmel requested changes to D24363: Add TCA6416 GPIO expander support..
Apr 14 2020, 4:20 PM

Mar 9 2020

mmel committed rS358807: Add the missing brackets to the logical expression..
Add the missing brackets to the logical expression.
Mar 9 2020, 1:36 PM

Mar 7 2020

mmel added a comment to D22692: Add support for the RK805/RK808 RTC.

Most boards don't have a battery connected. What happens in this case? I don't see any validity detection in this code

Mar 7 2020, 9:34 AM

Jan 30 2020

mmel added inline comments to D23349: arm64 N1SDP PCI root complex driver.
Jan 30 2020, 3:40 PM

Jan 17 2020

mmel accepted D23216: rk805: Add a regnode_init method.

lgtm

Jan 17 2020, 6:40 AM

Jan 8 2020

mmel added a comment to D23085: DRM: Add DRM core files and DRMKPI.

common/include/xxx.h

#if defined(LINUXKPI_BASEDRM)
Do it this way
#else
Do it that way
#endif

basedrm/include/xxx put the DRM header files here which you need.

Static inline functions is your friend.

Maybe Johannes has some opinions too.

Is it possible to add this driver as part of the existing KMS DRM driver?
Jan 8 2020, 2:00 PM

Jan 6 2020

mmel requested changes to D23007: regulator: Set correct uvolt value in regnode_set_constraint.

I think that this is wrong way to fix you issue. We should not rely on preset values from loader. Voltages should be adjusted by drivers, and if this is not possible, the PMIC driver itself should set right values within its initialization - in exactly same way as we do within clocks initialization.

Jan 6 2020, 3:40 PM
mmel accepted D23003: regulator_fixed: Add a get_voltage method.

This is slightly controversial. "regulator-min-microvolt" nor"regulator-max-microvolt" are not required properties for fixed regulators so we can't do this so simply. inmo,, we should monitor the presence of these properties and use this info for generate of the result.

Jan 6 2020, 3:32 PM
mmel accepted D23005: rk805: Add regnode_status method.

lgtm

Jan 6 2020, 3:17 PM
mmel accepted D23006: regulator: fix regnode_method_get_voltage.

oups, my bug. Sorry for trouble.
lgtm

Jan 6 2020, 3:15 PM
mmel accepted D23004: rk808: Add min/max for the switch regulators.

lgtm

Jan 6 2020, 3:13 PM

Jan 2 2020

mmel accepted D22891: Add support for i2c bus mux hardware..

lgtm

Jan 2 2020, 7:35 AM

Dec 31 2019

mmel added inline comments to D22891: Add support for i2c bus mux hardware..
Dec 31 2019, 4:44 PM

Dec 28 2019

mmel accepted D22922: Eliminate generated ldscript for arm and arm64, and strip $a/$d marker symbols from linked kernel..

tested on arm64
lgtm

Dec 28 2019, 4:46 PM

Dec 19 2019

mmel added a comment to D22849: arm64: rockchip: Add interface for rk_pinctrl.

imho, some bits of this should be implemented as part of generic fdt_pinctr interface.
We should have at least
FDT_PINCTRL_IS_GPIO()
FDT_PINCTRL_SWITCH_TO__GPIO()
FDT_PINCTRL_SET_GPIO_FLAGS()
FDT_PINCTRL_GET_GPIO_FLAGS()
Major issue is how to get right reference to appropriate pinctrl instance(within gpoio driver) and how to convert pin numbers from gipo nomenclature to pinctrl nomenclature. This should be covered by "gpio-range = <>" property, but world is not ideal :(

Dec 19 2019, 1:55 PM
mmel accepted D22854: arm64: rockchip: Add driver for the io domain.

Tested on AIO-3288.
lgtm

Dec 19 2019, 12:41 PM
mmel accepted D22852: arm64: rockchip: rk808: Add remaining regulators.

lgtm

Dec 19 2019, 12:24 PM

Dec 7 2019

mmel updated the summary of D22724: Add driver for Rockchip PCIe root complex found in RK3399 SOC..
Dec 7 2019, 5:03 PM
mmel created D22724: Add driver for Rockchip PCIe root complex found in RK3399 SOC..
Dec 7 2019, 5:02 PM

Dec 2 2019

mmel accepted D22622: Handle the possibility of preemption after an "ic" or "tlbi" instruction.
Dec 2 2019, 6:10 PM

Dec 1 2019

mmel added a comment to D22606: Switch to an empty ttbr0 pagetable when the MMU is enabled.

i just realized that this breaks EARLY_UART because SOCDEV_PA mapping is not passed to initarm().
So I think that we should postpone change of kernel ttbt0 until cninit() is processed.

@@ -1164,6 +1164,7 @@ initarm(struct arm64_bootparams *abp)
        valid = bus_probe();
Dec 1 2019, 10:55 AM

Nov 30 2019

mmel accepted D22606: Switch to an empty ttbr0 pagetable when the MMU is enabled.

Tested on RockPro64 an Tegra TX1 without problems. Unfortunately, it doesn't affect RK3399 issues in either way...

Nov 30 2019, 11:03 AM

Nov 26 2019

mmel updated the diff for D22441: Finish implementation of RK3299 clocks. .

Move common macros to rk_cru.h

Nov 26 2019, 5:10 PM
mmel added a comment to D22499: Changes to support booti u-boot command.

With full respect, I have no idea why you want/need these changes to original D13861.
Adding initrd support to top of D13861 is simple (we can use fragments from this patch).
For me most clean way how to solve this situation is:

  1. revert original commit.
  2. commit D13861 (without putting LINUX_BOOT_ABI to GENERIC)
  3. convert this patch to adding initrd support on top of D13861 ( I offering full help for this)
  4. fix generation of booti image (by utility program or by some hex editing, having booti header in locore.s is not a right way)
Nov 26 2019, 11:34 AM · arm64

Nov 19 2019

mmel updated the diff for D22441: Finish implementation of RK3299 clocks. .

Add own version of clock ID's header without single copyright

Nov 19 2019, 9:12 AM
mmel created D22442: Add driver for temperature sensors found in RK3288, RK3328 and RK3399 SoC's..
Nov 19 2019, 8:31 AM
mmel updated the diff for D13863: Simplify and cleanup startup code for secondary cores..

Revert previous diff update, committed to wrong review.

Nov 19 2019, 7:34 AM
mmel updated the diff for D13863: Simplify and cleanup startup code for secondary cores..

I pushed outdated diff, update it to final version

Nov 19 2019, 7:22 AM
mmel created D22441: Finish implementation of RK3299 clocks. .
Nov 19 2019, 6:47 AM

Nov 16 2019

mmel added a comment to D22255: Boot arm64 kernel using booti command from U-boot. .

Hi Mmel,

In D22255#489923, @mmel wrote:

Hi Mmel,

Please find my comments inline.

After more detailed analysis, I think that there are more problems.
Let me explain situation. Givens are:

• Actual locore.S mappings of kernel expects that physical memory is aligned to 1GB boundary. This implies that we don’t support boards with lower that 1 GB memory (I don’t see other real limitation caused by this fact).

In locore.S L1 block page table entry is built on 1GiB aligned physical load addr of kernel. However this is irrespective of using loader or U-Boot to boot the FreeBSD kernel.

• U-Boot booti command expect that kernel, fdt, and initrd blobs are loaded at ${kernel_addr_r}, ${fdt_addr_r} and ${initrd_addr_r} offsets.

Yes.
As part of this patch linux_load_initrd() will do build_l1_block_pagetable() to map initrd start address aligned to 1GiB PA=VA.
(By default, initrd_addr_r will be relocated to highmem by booti in U-Boot code (do_bootm_linux->boot_prep_linux->boot_reloc_ramdisk->boot_ramdisk_high)).

locore.S maps 1GiB algined kernel_addr_r PA=VA. I assumed that fdt_addr_r ( a couple of KiB’s in size) can also be within this 1GiB aligned addr. However, fdt_addr_r can be mapped similar to initrd start addr (in linux_load_initrd()).

Real value of these variables is driven by u-boot and we cannot expect nothing about this value. (order, gaps, etc..)

Sure.

It’s possible that kernel want to load kernel at begining of memory and initrd blob at end. We must support this, it's generic part of ‘distro_boot’ u-booot protocol/framework. And support of distro_boot is one of major goals for having booti supported, imo.

Sure. My understanding is that patch handles this. Physical load address of,
kernel is mapped into KVA starting at KERNBASE in locore.S
dtb blob is mapped into KVA starting at [ KERNBASE+(kernel size) ] in machdep_boot.c
initrd is mapped into KVA starting at [ KERNBASE+(kernel size) + (dtb size) ] in machdep_boot.c

This give me some conclusions:
Because of 1) optimal mapping granularity is 1GB, more fine grained granularity is nothing than waste of TLB entries and build_l2_block_pagetable() is useless. (at least I don’t see single advantage of using fine grained mappings, while disadvantage is clear - more TLB pressure ).

[1]
locore.S does maps kernel physical load addr into KVA starting at [ KERNBASE ] to [ KERNBASE + (kernel size)] using build_l2_block_pagetable. KVA is in L2 table which has 512, 2MiB entries. 1GiB L1 table entry is linked to this L2 table.

The following comments from create_pagetables: in locore.S,

  • It relys on:
  • We were loaded to an address that is on a 2MiB boundary
  • All the memory must not cross a 1GiB boundaty
  • x28 contains the physical address we were loaded from *

I am mapping dtb and initrd image into L2 table following the end of kernel. Therefore I created build_l2_block_pagetable() in machdep_boot.c
In fact if this not done dtb or initrd cannot be added into KVA. Due to above comments, I added a print in machdep_boot.c if kernel+dtb+initrd will exceed 1GiB.

This is not exact description. You allocates and maps new memory (by using lastaddr) for fdt and initrd blobs. Then you *copy* these blobs to new location. See lines 122 and 127 for fdt, and lines 270, 273 and 275 for initrd.

Basically, I am creating 2MiB KVA L2 table entries to move the fdt and initrd blobs from PA to KVA.

As you can see, you have mapped both source and destination address for initrd blob memmove(), but only destination address was mapped for fdt blob memmove() (point me to right place if I’m wrong, please).

Sorry I did not understand this clearly. inirtd size (in counts of 2MiB) is calculated using initrd-end - inird-start. For dtb the size is available in its header.

Problem is not about initrd but fdt blob
at line 127 we do
memmove((void *)lastaddr, dtb_ptr, dtb_size);
destination memory is mapped at line 122 by
build_l2_block_pagetable(lastaddr, dtb_size, abp
but where is mapped source memory (pointed by dtb_ptr in memmove())????

Nov 16 2019, 1:57 PM · arm64
mmel added a comment to D22255: Boot arm64 kernel using booti command from U-boot. .

Hi Mmel,

Please find my comments inline.

After more detailed analysis, I think that there are more problems.
Let me explain situation. Givens are:

• Actual locore.S mappings of kernel expects that physical memory is aligned to 1GB boundary. This implies that we don’t support boards with lower that 1 GB memory (I don’t see other real limitation caused by this fact).

In locore.S L1 block page table entry is built on 1GiB aligned physical load addr of kernel. However this is irrespective of using loader or U-Boot to boot the FreeBSD kernel.

• U-Boot booti command expect that kernel, fdt, and initrd blobs are loaded at ${kernel_addr_r}, ${fdt_addr_r} and ${initrd_addr_r} offsets.

Yes.
As part of this patch linux_load_initrd() will do build_l1_block_pagetable() to map initrd start address aligned to 1GiB PA=VA.
(By default, initrd_addr_r will be relocated to highmem by booti in U-Boot code (do_bootm_linux->boot_prep_linux->boot_reloc_ramdisk->boot_ramdisk_high)).

locore.S maps 1GiB algined kernel_addr_r PA=VA. I assumed that fdt_addr_r ( a couple of KiB’s in size) can also be within this 1GiB aligned addr. However, fdt_addr_r can be mapped similar to initrd start addr (in linux_load_initrd()).

Real value of these variables is driven by u-boot and we cannot expect nothing about this value. (order, gaps, etc..)

Sure.

It’s possible that kernel want to load kernel at begining of memory and initrd blob at end. We must support this, it's generic part of ‘distro_boot’ u-booot protocol/framework. And support of distro_boot is one of major goals for having booti supported, imo.

Sure. My understanding is that patch handles this. Physical load address of,
kernel is mapped into KVA starting at KERNBASE in locore.S
dtb blob is mapped into KVA starting at [ KERNBASE+(kernel size) ] in machdep_boot.c
initrd is mapped into KVA starting at [ KERNBASE+(kernel size) + (dtb size) ] in machdep_boot.c

This give me some conclusions:
Because of 1) optimal mapping granularity is 1GB, more fine grained granularity is nothing than waste of TLB entries and build_l2_block_pagetable() is useless. (at least I don’t see single advantage of using fine grained mappings, while disadvantage is clear - more TLB pressure ).

[1]
locore.S does maps kernel physical load addr into KVA starting at [ KERNBASE ] to [ KERNBASE + (kernel size)] using build_l2_block_pagetable. KVA is in L2 table which has 512, 2MiB entries. 1GiB L1 table entry is linked to this L2 table.

The following comments from create_pagetables: in locore.S,

  • It relys on:
  • We were loaded to an address that is on a 2MiB boundary
  • All the memory must not cross a 1GiB boundaty
  • x28 contains the physical address we were loaded from *

I am mapping dtb and initrd image into L2 table following the end of kernel. Therefore I created build_l2_block_pagetable() in machdep_boot.c
In fact if this not done dtb or initrd cannot be added into KVA. Due to above comments, I added a print in machdep_boot.c if kernel+dtb+initrd will exceed 1GiB.

This is not exact description. You allocates and maps new memory (by using lastaddr) for fdt and initrd blobs. Then you *copy* these blobs to new location. See lines 122 and 127 for fdt, and lines 270, 273 and 275 for initrd. As you can see, you have mapped both source and destination address for initrd blob memmove(), but only destination address was mapped for fdt blob memmove() (point me to right place if I’m wrong, please).

Nov 16 2019, 10:22 AM · arm64
mmel added a comment to D22255: Boot arm64 kernel using booti command from U-boot. .

After more detailed analysis, I think that there are more problems.
Let me explain situation. Givens are:

  1. Actual locore.S mappings of kernel expects that physical memory is aligned to 1GB boundary. This implies that we don’t support boards with lower that 1 GB memory (I don’t see other real limitation caused by this fact).
  2. U-Boot booti command expect that kernel, fdt, and initrd blobs are loaded at ${kernel_addr_r}, ${fdt_addr_r} and ${initrd_addr_r} offsets. Real value of these variables is driven by u-boot and we cannot expect nothing about this value. (order, gaps, etc..) It’s possible that kernel want to load kernel at begining of memory and initrd blob at end. We must support this, it's generic part of ‘distro_boot’ u-booot protocol/framework. And support of distro_boot is one of major goals for having booti supported, imo.

This give me some conclusions:
Because of 1) optimal mapping granularity is 1GB, more fine grained granularity is nothing than waste of TLB entries and build_l2_block_pagetable() is useless. (at least I don’t see single advantage of using fine grained mappings, while disadvantage is clear - more TLB pressure ).
Because of 2) – all 3 booti blobs must be taken separately. I don’t see single reason for postponing mapping of FDT to C code. Original locoer.S works and build_l2_block_pagetable() is unusable. Using lastaddr for reservation of memory used by initrd is clearly nonsense. Initrd blob should be reserved by using (probably) arm_physmem_exclude_regions() and map it later , when pmap is fully bootstrapped.

Nov 16 2019, 3:52 AM · arm64

Nov 15 2019

mmel added a comment to D22255: Boot arm64 kernel using booti command from U-boot. .

please, use original locore.S from D13861 I'ts tested on many boards and it works :).

Nov 15 2019, 3:18 PM · arm64
mmel added inline comments to D22255: Boot arm64 kernel using booti command from U-boot. .
Nov 15 2019, 12:13 PM · arm64
mmel added a comment to D22255: Boot arm64 kernel using booti command from U-boot. .

Moreover this doesn't boot on RockPro64, where original code from D13861 works without problems. jhibbits, please revert this, this code needs definitely more love. (Please, be sure that I'm first who wants booti support in kernel, but broken support is worse that no support)

Nov 15 2019, 12:05 PM · arm64
mmel added a comment to D22255: Boot arm64 kernel using booti command from U-boot. .

I'm sorry for delayed review, but I am overloaded with my current work on Rockchip ports.
But in any case, if you want to reuse someone else's patch, it would be better to include the original author directly as the reviewer.

Nov 15 2019, 9:17 AM · arm64

Nov 8 2019

mmel added inline comments to D22281: Cleanup Rockchip clocks implementation..
Nov 8 2019, 6:11 PM
mmel created D22283: Tidy up Rockchip composite clock..
Nov 8 2019, 5:18 PM
mmel created D22282: Enhance Rockchip clocks implementation..
Nov 8 2019, 5:17 PM
mmel created D22281: Cleanup Rockchip clocks implementation..
Nov 8 2019, 5:14 PM

Nov 6 2019

mmel accepted D22260: regulator: Add regulator_check_voltage function.

LGTM

Nov 6 2019, 2:49 PM

Oct 23 2019

mmel accepted D22106: regulator: Add a regnode_set_constraint function.

LGTM

Oct 23 2019, 9:51 AM
mmel accepted D22106: regulator: Add a regnode_set_constraint function.

rest is OK for me.

Oct 23 2019, 9:24 AM
mmel added a comment to D22106: regulator: Add a regnode_set_constraint function.

The code itself looks OK for me. But I have problem with using its usage as default regulator init method, because:

  • it cannot be used by regulators with its own init
  • it expect that regulator is accessible early, at registration time. I'm not sure if this is possible in all cases (like I2C and interrupts ..)
Oct 23 2019, 8:14 AM

Oct 4 2019

mmel added a comment to D21703: o Unify all <machine>/resource.h, unhide PCI_RES_BUS, add CLK and PWR..

Can you, please, give me your motivation for adding new resource types when it’s clear that these resources cannot be handled by resman/newbus without extreme API breakage?
For OFW/FDT world, major issues are:

    • given resource (request, allocated) cannot be described by single integer, and infrastructure must take it fully opaque (there is nothing like ‘resource start’, ‘resource end’ and interval enumerator)
  • hierarchy for other resources(clk, regulator, reset, phy, ...) is not bus related and can have circular dependencies – so it cannot be represented by tree, but by graph. This result to fact that bus enumerator cannot prepare resource list for its child devices. This is something which break basic design expectation of newbus.
  • circular resource dependencies (between types – frequent, within single resource type – no that frequent but exist mainly for clocks) also means, that we relay need staggered device_attach(), there is no way to do this by automatic ordering of devices attach, driven by resource availability.

Another current newbus or bus_space limitation is that we should have (general, globalized) memory attributes and be should pass it do all memory mapping function. On arm or arm64, PCI config space should be mapped with different attribute (strongly ordered) that pci (or other devices) mmio register space (posted writes are allowed). Actual behavior (all devices are mapped as strongly ordered) have measurable performance impact.
Don’t take me badly, I’m still newbus fan, I only don’t see reliable way how we can extend it without fatal/significant API breakage.

Oct 4 2019, 8:14 AM

Mar 19 2019

mmel committed rS345299: PSCI: Don't take missing implementation of psci get_version() as fatal..
PSCI: Don't take missing implementation of psci get_version() as fatal.
Mar 19 2019, 3:42 PM
mmel committed rS345297: Improve cpufreq_dt..
Improve cpufreq_dt.
Mar 19 2019, 2:35 PM
mmel committed rS345296: Use named field's initializer when constructing <foo>_platform structure..
Use named field's initializer when constructing <foo>_platform structure.
Mar 19 2019, 2:33 PM
mmel committed rS345295: extres: Unify error codes for <foo>_get_by_ofw_property() methods..
extres: Unify error codes for <foo>_get_by_ofw_property() methods.
Mar 19 2019, 2:31 PM

Feb 15 2019

mmel accepted D19206: stand: dev_net: correct net_open's interpretation of params.

Yep, thanks.

Feb 15 2019, 3:40 PM
mmel accepted D19196: Per discussions on arch@ and elsewhere, retire drm module / drives..
Feb 15 2019, 6:46 AM